+1 for parceljs
+1 for parceljs
I am still thinking: why do a PHP framework like Yii need something like that??
It already features a more than capable asset manager, with asset bundles and whatever we need; unless we are managing the assets ourselves.
I am so happy that I am not on the JS train
My point is: is it really a concern of Yii if you choose to build your frontend wholly with JS? Because that’s the only reason why you’d need a JS bundler.
I’ll take a look, thanks
Neither Rollup nor Parcel have downloads anywhere near what Webpack has.
The difference with Parcel is that it uses an HTML file as the entry point. The Parcel command is
So in terms of support Webpack is the more stable bundler to use.
Also @jacmoe the point isn’t about building the whole front end in JS. It’s about building whatever amount of JS that includes only the JS from Yii that the developer needs.
If I want to do my own validation and use Yii’s validators I shouldn’t have to load the entire Yii JS file for a few things to validate a field on the page. That adds unnecessary overhead. The options as I see it is to either structure the JS they have in a maintainable way that allows the developers using it to only use what they need, or remove all of the JS that isn’t part of the debugging/file generation process (even then it should be well structured and easily maintainable, i.e. not big source files).
For now — certainly. A few years ago bower, gulp and grunt were a thing. Previously it was jQuery. I won’t be that sure what we’ll see next year.
Yii scripts are clearly divided. Validation is in its own file. When we’ve implemented Stay project we’ve used gulp to build our assets and for package sources we’ve referenced files from
vendor. I don’t see a reason why it cannot be done with webpack or any other bundler without specifically supporting/preferring that workflow.
yii.validation.js is 15.4 Kb.
That’s not a lot
I do understand the rationale between webpack and friends. And people are free to use them.
I just don’t think they are relevant to Yii. In my humble opinion.
Keep in mind those are all apples and oranges. Bower is a package manager, Gulp and Grunt are task managers, and jQuery is a library. I believe it would be a misrepresentation to compare them to each other or to Webpack. The difference between Webpack and Gulp is quite different.
Bower is built on top of Node and npm, like Yarn. It makes sense that they would eventually die off. Node and npm can now do most or all of what they do/did and keeps getting better.
Task managers were and still are used to make chaining things together in Node, but with the right set up Webpack + npm scripts can chain things together. Say for example in Webpack you import a Sass file, you can have Webpack use the
file-loader to export a processed CSS file. There’s nothing saying that these tools can’t be used in the same project, though. Like I said above, they serve different purposes.
Gulp just concatenates files, Bundlers rely on import and export statements either through CommonJS or ESM. Gulp doesn’t resolve the dependency files that another file might use. Which means obviously you’d have to have the file be in the array of files to concatenate.
Like I said above, with a task you can achieve “some” of what a bundler can do, but you have to patch it together yourself and you don’t get the full benefit/functionality a bundler.
The decline of jQuery is natural progression as well. jQuery made it easier to work across different browsers. As the browsers adopt more standards (unfortunately by just jumping on the Chromium train) jQuery’s purpose declines. It also started to decline with the rise of Node and frameworks and libraries such as Angular, Vue, and React. I’ll note that those also have a different purpose than jQuery.
Using Webpack, Browserify, Rollup, or any of the bundlers allows for better structure. Since you can import dependencies in the file that needs them, then package all of that together for the browser.
One could argue that bundlers will be moot in 5-10yrs when all browsers have an implementation for the
export statements. However, the browser would have to resolve and load all of the dependencies at run time and if you have a big application that load time for each individual file would be costly.
The two languages I work with the most PHP, and JS (a lot of JS). So I’m definitely a proponent of better structure.
It was noted that the validation file is only ~15k bytes, that’s great. That’s quite small. For Yii alone it possibly would be considered overkill. However, Yii is used in larger projects. I don’t see why developers shouldn’t be able to leverage importing Yii into their own files.
Ultimately it’s up to you guys, the contributors and collaborators, about what you want to do. I can simply offer my suggestions.
Seriously, we know what Gulp, Webpack, Bower, Yarn and the other things are and what they do
What prevents you from using Webpack right now?
That’s great that you know already, but they were being compared. So… I explained the apples and oranges to point out that they can’t be compared.
Nothing is stopping me from using Webpack, I do use Webpack. My point is being able to use Yii’s JS assets in a project’s JS assets instead of loading a separate file which has it’s own load time and includes more than may be needed for that page, even if the file is ~15kb.
I did that before, with Gulp and Gulp plugins, but now I just tend to let Yii load what it needs via the AssetManager (which only loads whatever when it needs to be loaded), because I’ve learned that having many requests is now better for performance than concatenating/combining resources. In fact, splitting up is now a recommended practice.
Could you explain to me how Yii should incorporate Webpack? It is very unclear to me what benefits it presents, or how it could be done?
This idea seems to go well with the concept of Yii 3 which is split into core pieces with minimum dependency.