I have a few friends who swear by Meteor, but after reading over the website I’m still not sold on using it over Sails.js, CompoundJS, or any of the other node frameworks.
I’m not trying to knock Meteor down, but I do want to explain to my friends why it won’t be using it for the time being. I feel that Meteor wants to solve a lot of problems that I don’t care about.
Maybe that’s because instead of making a lot of web apps I’m maintaining a B2B marketing website every day. Maybe I’ll look back on this post a year from now and kick myself. But for now, let’s go over what baffles me about Meteor.
- “Writing software is too hard and it takes too long.”
- I like writing software. Taking all the hard away from something doesn’t automatically make it fun.
- This goes for any node framework.
- “Just write your templates. They automatically update when data in the database changes. No more boilerplate redraw code to write.”
- I don’t face this issue often because I don’t change my database schema often.
- “No more loading your data from REST endpoints.”
- I thought REST was cool because of standardization, simplicity, portability, etc. Is a separation of concerns not a concern?
- “Latency compensation. When a user makes a change, their screen updates immediately.”
- This is very neat and could be a killer feature.
- “Hot Code Pushes. Update your app while users are connected without disturbing them.”
- I’m not sure what the big bad alternative to this is. Wouldn’t users always get the latest the next time they load the site?
- “Sensitive code runs in a privileged environment.”
- Who’s writing sensitive code and then sending it to the client?
- “Fully self-contained application bundles.”
- Neat, but I don’t know how unique to meteor it is. Seems like node and npm make this pretty easy.
- “You can connect anything to Meteor… ” “Just implement the simple DDP protocol.”
- Meteor wrote an entirely new protocol to connect with other software? What’s wrong with HTTP?
- “Meteor’s Smart Packages are actually little programs that can inject code into the client or the server… ”
- Sounds interesting, but again it’s not solving a problem I typically have.
- “Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.”
- Sending HTML over the network is how the web was designed to work, and I haven’t figured out what Meteor gains by throwing this out.
See you next year for the inevitable retraction post.