I have looked at @ccorcos’ very well written piece on the subject. My question is this, does this serve as a better replacement to the package only approach and should I pair it with universe:modules?
Lately it feels like someone has to learn a new tech every week just to stay on top of things in the JS World. Quite unsettling but I guess this is what it means to experience evolution of a language.
Does the ‘quick reload’ in 1.2 serve the same purpose of this is a far much focused solution. I am in the dark when it comes to this. Any leads will be highly appreciated.
Webpack is a bundler with tons of options that will facilitate your life in frontend development, specially if you are using React. It has nice features like traversing your imports/requires and bundling only what you are using, sourcemap generation, code splitting (if you want to load only necessary code per page, for example), powerful loaders (they are like plugins) that process your code (for example processing less/sass files).
Much of those things are bundled with Meteor already. But some people do not want to use Meteor’s packages for frontend development, simply because you stay attached to them and sometimes you can’t use the full npm/bower ecosystem. Like, try to get a React package and use it with Meteor React’s package. It is a pain sometimes, because Meteor does not have a solution for commonjs/amd and everything is in global scope.
Hope it was clear enough, it’s such a hard topic to introduce.
It is objectively far superior to using the package only approach. Here are my opinions:
Industry standard
It’s the defacto way to build React apps, and in general is the most popular build tool currently.
Uses standard JavaScript modules
The JS community has ES6 modules and is the way forward for writing modular javascript. Meteor packages will only work in Meteor which is an issue.
Scalable
As your project grows and gets new requirements you can augment it to keep up. The most exciting is code splitting so that you only the JS you need on page load and then incrementally load the rest. This is made easier with React Router.
Lately it feels like someone has to learn a new tech every week just to stay on top of things in the JS World. Quite unsettling but I guess this is what it means to experience evolution of a language.
That’s the downside of learning any young language. While JS has been around for years it’s recently started becoming useable for complex apps. We build apps much different than 5 years ago (more similar to iOS apps) so things are in flux in general.
The only alternatives is to write serverside apps in PHP/Ruby/NET/etc… or to work on iOS/Android apps.
Does the ‘quick reload’ in 1.2 serve the same purpose of this is a far much focused solution. I am in the dark when it comes to this. Any leads will be highly appreciated.
Hot code patching
Unlike the hot reload or ‘live reload’ that Meteor does, webpack can hot patch a module or function when it’s changes… that means all your variables are still set, CSS intact, and no page refresh. This is seriously productive.
Fast
It can reload a change in large projects in 1.5 seconds vs 16 seconds. Huge improvement.
So beyond the learning curve, what, if any are the downsides? and/or why wouldn’t MDG transition to adding a thin layer to Webpack to create their build system rather then maintained a custom one… much like they now plan to do for Blaze on top of React?
JSPM might be ready now but when I tried it, it really didn’t work very well. I think this will eventually overtake webpack because of the simplicity… although it still doesn’t take care of things that Grunt/Gulp/Webpack does like CSS, image processing, etc…
[quote="funkyeah, post:5, topic:13973, full:true"]
So beyond the learning curve, what, if any are the downsides? and/or why wouldn't MDG transition to adding a thin layer to Webpack to create their build system rather then maintained a custom one.... much like they now plan to do for Blaze on top of React?
[/quote]
Webpack can be as simple as a 5 line config file but it can quickly become complex. It can handle almost any situation with more configs but that makes things hard to learn and figure out. The other con is that it doesn’t compile CSS separately… they have their own method of requiring CSS at the JS module level, so you may need to compile CSS separately if that doesn’t align with your project.
If you read the writing on the wall, MDG is going to be using webpack for their new build system for ES6 modules. They really don’t have time to re-invent the wheel and make their own webpack. They could also claim that Meteor is ‘the easiest way to use webpack’ and would be a huge selling point.
This would give them a ton of hooks for their build tool, hot code patching, ES6 modules, hot patching on the react component level (via babel transforms) if React was used.
Oh no! I didn’t see that thread. I know they were looking into a while ago. Very disappointing actually. 17 second build times are untenable.
I wouldn’t mind them re-inventing the wheel if it was better… or at least on par.
1.4 second load times vs 17 seconds is a disaster. If they can’t fix this i’m moving to another framework and only using Meteor for throw away prototypes. I’m so tired of working around all of these issues that can be addressed by using JS community solutions.
I agree with @SkinnyGeek1010. Why shouldn’t you use a very nice OSS already?! For me, it’s like rewriting jQuery and Underscore before trying to put it in!
The only thing your comic is missing is another “sometime later” panel where the Meteor community has all adopted carts with square wheels, built roads that work best with square wheels, and then MDG decides wheels would be good after all.
