Important note: I am not using Meteor anymore, though I still follow it’s development because I might use it again in the future. I’m using Node now.
I think Meteor’s use-case and unique selling point has been the easy setup as a build tool (and also for oldschool DDP stuff everything works out of the box). So even without using the Meteor stack with accounts system, etc. Meteor would be a good deal, since you can easily run projects.
Now with Webpack 4 they’ve greatly improved getting started with it, so I wonder how you see Meteor’s USP at this point?
Given that Webpack 4 is a lot more out of the box than before but at the same time you can still configure the shit out of it, what you can’t really do with Meteor (which drove me away from it actually when I needed configurability) I think there has to be more, no? What does Meteor offer at this point compared to Webpack 4?
Meteor is also using Node thus I think what you mean that you’ve the time/resources to assemble a Node stack yourself.
DDP is a simple bi-directional protocol, you can find the specs here. By the same logic, we could also argue that HTTP, Rest and any other protocol are all “oldschool” stuff. I personally think it’s simple and works very well for many use cases with a pub/sub API and RPC methods.
If you want a lot configuration or you want assemble your own stack, then yeah I don’t recommend Meteor for you. But I personally want to focus on what the customers/users want and deliver results/features, thus I just need a good enough defaults all the way to production.
Since you’re using Webpack 4 now, I’ve few questions that will help us to evaluate better:
What do you get out of the box with the “zero config”? in Meteor as you know, you’ve the DB, Data layer and view layer, accounts/authentication etc. so what are we getting when we start with zero config Webpack (or Parcel/Fuse-box, etc.) projects?
Can you please point me to a production open source Webpack project with zero config? It’s one thing to start with zero-config, but it’s another to actually build and deploy a large app without writing as single line of configuration
Is it possible to create packages similar to what Meteor packages system allow? In other word, bundle assets, files, html, js files and add them to client, server or both? If you take a look at many large open source large Meteor projects such as rocketChat or Vulcan.js, they’re making heavy use of Meteor packaging system in their architecture, can you please share an open source Webpack based project with similar architecture, I’m curious how this pattern is implemented in Webpack
Using Meteor build system, if you wan to add a .less compiler you just add package, and you can still pass config files if needed but you always have a working default configurations. Do we’ve similar default out-of-box configurations with command line util for Webpack?
I think competition is healthy, however I think Meteor is far a head with it’s packaging system, zero-configuration all the way to deployment and it’s ecosystem, but I’d like to hear your experience/findings with respect to the points above.
I think you could look at “Meteor vs. webpack/parcel/fuse-box/…” from a slightly different angle. Meteor is not just a build tool, it’s a zero-configuration development tool. Unlike webpack, it covers almost every aspect of web application development. The most notable differences for me are:
The environment is set up automatically: You don’t have to install Node or a database yourself. Meteor guarantees that compatible and up-to-date versions are used.
Meteor has great build tool and runtime support for isomorphic development, and you don’t need two different configurations or setups to develop for both client and server. Just to mention one simple example: Finding out whether code runs on the client or the server requires configuration in most other build tools (like setting a process.browser property to true for client builds). With Meteor, things like that just work out-of-the-box.
Meteor has good Babel defaults (it supports React/JSX and some TC39 proposals). Meteor 1.7 will generate a separate bundle for older browsers to take advantage of ECMAScript support in modern browsers and to reduce bundle size. All of this works automatically. When a new Node version is released or browsers implement a new feature, you don’t have to adapt any configuration.
Great debugging experience: You can open an interactive shell on the server and debug code with Chrome DevTools or other tools that support the debugging protocol.
Built-in zero-configuration deployment (if you want to use Galaxy).
You can build mobile apps for Android and iOS (and maybe use React Native in the future).
I haven’t used webpack 4 yet but as far as I can tell, only a few options work without configuration (although more options will be supported in the future, according to the announcement blog post). If you want to compile your code with Babel, use a CSS preprocessor, or change code splitting tradeoffs, you still have to install and set up loaders, plugins, and other dependencies.
I did a bit more research on Webpack 4 configuration, and here is a “basic tutorial” of setting up up Webpack for Vue.js, the config file is more then 100 lines of specialized syntax, I mean I’m not sure how new comers would be able to start.
Today on HackerNews someone posted a link for a tool they’ve used to create a config files for Webpack 4, you can see it here. Again, I don’t think that’s very encouraging sign of developer friendliness.
And here is a tutorial to try using the zero-config with very basic react app and the author has to eventually execute the following command to get it working:
Again this is just to get started, who knows what what else you’ll need before production. I think Webpack is starting to adopt zero config due to the pressure from Parcel, yet Meteor had the convention over configuration philosophy more then 6 years ago! way ahead.
We have deployed in production (golive was at the start of the month) a React application with webpack 3.9.1.
40 lines of configuration (since it has 2 entries point it wouldn’t be significantly shorter with webpack 4)…
Also it never says it’s a basic tutorial for webpack usage with Vue, it’s a migration guide with a lot of advanced stuff most users won’t need early on.
Anyway, webpack complexity has nothing to do with convention over configuration, most of the hardships comes from the fact that vanilla webpack doesn’t include most functionalities that users would expect to get out of the box, so in the end you need to configure at least a couple of loaders (possibly more) to get all the nice things webpack lets you do.
It’s a completely different approach from Meteor and it’s nice that we have so many possibilities in the JS ecosystem.
I think Webpack is starting to adopt zero config due to the pressure from Parcel, yet Meteor had the convention over configuration 1 philosophy more then 6 years ago! way ahead.
I’ve always felt that Meteor was way ahead of it’s time in a lot of areas, and that the ecosystem changed around it before the potential could be fully realized. I’ve noticed that many of the early Meteor tenets are things that are now desired in the community and specialized solutions are being created for them.
Convention over configuration (also known as coding by convention) is a software design paradigm used by software frameworks that attempt to decrease the number of decisions that a developer using the framework is required to make without necessarily losing flexibility
You can in fact see Meteor listed in the wikipedia article as an example of a framework that adapts this paradigm. Webpack is the configuration, Meteor is the convention.
If you don’t see the difference of a “basic” file that replicated their setup (which includes testing code, css extract and many other things that are useless for starting a project) from a basic tutorial it’s pretty difficult to argue further.
It’s ok to admin you didn’t link a basic tutorial.
No, the difference is between an opinionated bundler and one that let you do whatever you want and has a modular approach to features.
HMR, css extract, code splitting, dynamic imports, png converted to data urls etc etc will probably never be 0 configuration option in webpack because it’s not that opinionated, by default it bundles your js and that’s it, if you want everything else you need to install a module.
It’s like comparing node + express to meteor, they try to do very different things and that’s alright.
My apology, I think there is misunderstanding here, since I posted links for two tutorials.
Here is the link to the tutorial I was referring to, the title of the tutorial is Starting with Webpack 4 and VueJs — A quick-start tutorial and the config being referenced is shared in step 2.
I do see the difference between the starting config and the production config, I actually made this point earlier above as point 2.
Again as I stated earlier, I’m not a fan of a bundler that has little defaults/opinion, I don’t want to copy/create config files, I came from a Java background and that is one of the main reasons why I shifted from Java to Node ecosystem, I prefer an opinionated reasonable tested convention with absolute minimum configuration that takes project all the way to production so the attention/decisions can be focused on the business and configuration best practices are defaulted and not re-invented.
Most web apps need css extract, code splitting, dynamic imports, png converted to data urls, etc. so why leaving web app developers to configure this stuff? why not starting with a reasonable default and give the flexibility to customize later if needed?
And I think I’m not the only one in the community who prefer this approach, there is a reason why Parcel, Fuse-box and the zero-config paradigms are gaining momentum. Meteor pioneered zero-config and developer friendliness (among many other things) few years back and I think we’re starting to see more appreciation of these paradigms.
It’s definitely not 100 lines, still verbose but not that much. (and I still think file-loader should be kept for advanced usage or added before going to production, it’s really not necessary).
I agree and I think most modules should be included by default (also not bundling .jsx by default is asinine when React is the most popular JS framework), but I guess the developers had their reasons to choose this approach.
It doesn’t really make much difference for seasoned developers since you can have everything working in a couple of minutes if you have it done before, but surely the simplicity of other bundlers would be very welcome.
It’s nice switching back to meteor from time to time and enjoy the simplicity of it and the painless upgrades.
But I want to add that the simplicity mindset extends way beyond the build/bundler which is, in my mind, what makes the Meteor ecosystem unique as far I can see.
You want to scale using Redis? sure just add a redis-oplog package, you want to create a reactive object relations? sure add another package, you want accounts with social networking integration and UI? here is a package, you want create real-time API? sure just use pub/sub, you want to deploy? sure, here is one line Galaxy command, and here is one of my favorite, do you want to use Webpack? sure, here is a Meteor package, thus the simplicity, re-use and DRY extends way beyond the build. Best practices were created over the years, tested in production, all available as Open Source packages thus saving tons of seasoned developers man-hours at every phase of the project and not just the build.
, thus the simplicity, re-use and