Yeah, that's right, I said Meteor!
Meteor is often overlooked. It is highly underrated for reasons I can not explain. In fact, this is only the 10th post tagged meteor on dev.to!
Meteor is a fantastic piece of software.
Ben Newman -- one of the people who currently maintain Meteor -- worked at Facebook before Meteor Development Group. At Facebook, he wrote Regenerator. Regenerator is a tool that Babel uses under the hood for transpiled async functions.
The chances are that you wrote async functions at some point, and they were handled under the hood by Ben Newman's Regenerator!. Some of you may still transpile async functions for older browsers and are thus still using Regenerator today.
This guy Ben works on Meteor now, and his code is f***ing clean; something to be inspired by.
Meteor vs Webpack? Meteor vs Parcel? What?
You may think of Meteor as an Application Framework.
Well, you would be sort of right.
Meteor is a collection of libraries and tools, that when used together (for example in the default application that the CLI tool scaffolds for you) can be considered an application framework.
But you don't have to use all the pieces all at once.
For some odd reason, people think using Meteor is all or nothing. Maybe this is why it is underrated, and causing people to waste their time re-implementing all the awesome things Meteor can already do for you.
This article could be called "Meteor vs Ember vs Angular", or "Meteor vs MEAN", or "Meteor Blaze vs React vs Vue", or "Meteor vs Express vs Koa.js", or "Meteor vs Passport.js vs Permit", or "Meteor vs Ionic Framework".
Did you know, that in Meteor's core there is an amazing build system and bundler capable of building your JavaScript/TypeScript/CoffeeScript/Vue/JSX/Angular/Sass/Less/Whatever not just for web (old targets and new targets), but also for iOS and for Android as mobile applications?
You could use Meteor just for the purpose of bundling and shipping your code with possibly the most sophisticated web-based build system and bundler in existence, and save yourself a lot of time.
This fact alone is something you should consider!
Okay, so what are the differences?
Meteor's Build System is, out of the box, similar to Parcel in the sense that you hit the ground running with default settings and no fuss.
Meteor's build system is also highly pluggable like Webpack. It is easy to make Meteor "build plugins" to handle any files types (equivalent to "loaders" in Webpack).
Let me tell you what Meteor has that no other bundler has:
Meteor has a space-age system for building your code for old and new targets, and automatically serving specific bundles to the runtime environment based on what it detects the environment to be, with zero config required!
Meteor allows you to publish your web-based app to iOS or Android. You only need a few simple commands to add build targets:
meteor add-platform android
meteor add-platform ios
After installing prerequisites for building mobile apps in your OS (XCode on macOS, or Android Studio on any OS), then you can simply run your app in a mobile emulator or actual device with simple commands:
meteor run ios # runs in an iOS emulator
meteor run ios-device # runs on your connected iOS device
meteor run android # runs in an Android emulator
meteor run android-device # runs in your connected Android device
meteor run ios android-device # run on multiple targets
You do not get this from any other bundler! đ
Honestly, I encourage you to take a look. All aspects of Meteor (the not-framework collection of tools), including the Build System, are documented.
That's all I'll write here. If you have any questions, I'm happy to try and answer them! :)
To learn more about "Meteor vs Webpack vs Parcel", I recommend reading an article on Webpack vs Parcel (and for that matter looking up "Webpack vs Browserify" and "Webpack vs Rollup" if you don't already know), and checking out Meteor's Build System.
Come to Meteor Night on Tuesday July 9th to hear Ben Newman and others discuss Meteor.
Top comments (17)
Meteor is the bomb, totally underrated
Absolutely love Meteor and what it can do right out of the box plus it plays nicely with Apollo / graphQL. We should write about it and promote it over MERN/MEAN on projects we join.
I would love to see a tutorial on how to use graphql instead of the default mongo queries in meteor. I think graphql is a much better way to query data instead. How would it work with the real time that meteor offers and stuff like that.
Hi Johhan, there are some guides here: docs.meteor.com/packages/apollo.html
I gave up on meteor when they did the version upgrade from 1.2 to 1.3 they changed everything with no easy way of upgrading a big project which made me think future upgrades would be this difficult as well.
And if Iâm not mistaken, it can only be run with mongodb.
Other than that, it is a good framework.
It seems you misread the stuff around "For some odd reason, people think using Meteor is all or nothing". You don't have to use MongoDB. But you can, and Meteor makes it very easy.
Your claim on upgrading from
1.2to1.3is simply not true. It's actually the other way round. I do not know of another project with as much commitment to backwards compatibility, as Meteor.There's nothing preventing you from running a Meteor
1.0project on the latest1.8.2 betarelease. And1.0was many years ago.I guess but then again, you wouldn't be taking advantage of that version upgrade which if I'm not mistaken was when they added code splitting. Before 1.3 I think you loaded the whole SPA in the first payload which wouldn't make sense to upgrade without re-structuring the project to take advantage of this.
Please correct me if I'm wrong as this was some time ago.
If you want to take advantage of code splitting and dynamic importing, then yes, you will have to put some time into refactoring your application to do so. But that's not Meteor specific, it's just how life is.
I guess Meteor does so much out of the box, you might forget it can't (not yet, at least) write your app for you!
The main takeaway from this should be: your Meteor
1.0project from many moons ago will still run on Meteor1.8.1(the latest recommended release). There is no need to refactor anything. During the evolution from1.0to1.8.1Meteor has gained all kinds of great new features, fixes and improvements, but they are, at least to my knowledge, 99% non-breaking and/or optional. That's quite something.That sounds right. Sure, you obviously may need to update structure to use new features, but old features didn't break. The new structure follows the modern standards of the JS community (ES Modules). It was inevitable for this change to happen; it would be detrimental for Meteor to follow the non-standard and not adapt to the change.
Johhan, I'm not sure what you ran into but the update from 1.2 to 1.3 was surely backward compatible! I've updated projects from 1.1 all the way to 1.8.
Hi Johhan! The update from 1.2 to 1.3 is backwards compatible. Using non-module JS files still works just like before. Cheers. - Joe
I've been using Meteor since 0.8, from prototyping for startups to delivering high availability, resilient and easy to maintain industrial grade applications with docker and apollo.
There is not a single week of my life when I didn't used Meteor since January 2015 :)
It's been ages since I've used Meteor. I was a big fan of it for a while. Just haven't made use of it lately; haven't had a real need for an SPA yet personally (until recently for something tiny, and I'm use Nuxt for that currently).
I do still think it's a neat toolset though. Definitely worth trying out, especially if you work with a lot of SPAs.
Also, if you're familiar with Mongo, Meteor provides MiniMongo for client-side storage.
And Meteor methods were a neat feature I really liked too.
Only complaints I have now are that Vue was a pain to set up last time I tried, and the build process was a lot slower than Webpack's. Do you know if things have improved in these areas?
Vue support is mentioned on the landing page on meteor.com and there are "official" packages for integrating Vue in Meteor, that are created and maintained by one of Vue's core team members. I believe it's safe to say Vue is well supported.
We're using Svelte with Meteor. React is a first-class citizen as well.
You might find it interesting to note that the author of Vue worked at Meteor before leaving to make Vue. Things are definitely improving. The build process has gotten a lot faster too. Ben Newman has done a wonderful job with the build system (continuing the great work of David Glasser). This week's Meteor Night is going to be a nice one!
By the way! If you prefer Webpack, you can still go that route: just make your bundle with Webpack, and have Webpack output the file into the Meteor folder. Then Meteor merely has to load your single file, which can be fast. In this way, the build is outside of Meteor while still letting you use Meteor's great features.
Interesting. I may throw together a new Meteor project to see how things have improved then, especially since @arggh mentioned Vue having much better support in Meteor now.
Thanks! I totally agree: Meteor is awesome! I love it!