Thanks for the article
Not saying you’re wrong, just my 2 cents:
What is Meteor
I can see how Meteor’s “magic” can be troubling, when someone wants to fully understand the ins and outs of their project. Still, at the end of the day, to me Meteor is just a build tool and a bunch of packages that work well together. It makes a developer’s life a bit easier. (Also, gives you reactivity and other goodies out-of-the-box).
Not having to implement reactivity and accounts is like a zero-interest loan from the bank that you don’t have to pay back, unless you want to. If I switch from Meteor to something else and I cannot use it’s accounts system anymore, I have to pay back the loan and actually write that stuff myself. I never lost anything by using Meteor’s offerings.
Disclaimer: I did write my own templates, validations and some custom logic for sign up, login, password reset and other pages but that stuff is easily re-used elsewhere
With my styles written using
nathantreid:css-modules, I could reuse them in any project. There is no Meteor specific magic in those definitions, since CSS Modules is “just an idea”. Same goes for plain CSS of course.
My templates are written in Blaze sugared with ViewModel, which could very easily be converted to React using ViewModel for React. Some people are converting their components to use Vue, since they can easily co-exist with Blaze templates. Even rewriting Blaze components with Vue seems very doable.
Routing is so simple that any library will do and there is many to choose from.
I’m using Astronomy to define my models and replacing that would be harder, because I think it’s using Meteor in such a nice way to make validating and updating documents a breeze. I’d have to write a custom abstraction layer and it wouldn’t be as flexbile. There is Sequelize that I know of, but it isn’t nearly as nice. Astronomy is on it’s way to NPM though, from what I read somewhere…
If I wanted to get rid of Meteor, the hardest part would be to replace reactivity and the Accounts-system, but then again, I never spent any time on those with Meteor.
This made me think why I chose Meteor few years back…
At the end of the day I choose the tools that fit best for the job in my naïve and subjective opinion. The two most important things for me is
1) I get stuff done that needs to be done
2) I’m happy getting stuff done.
I chose Meteor because I wanted to concentrate on my actual problem as much as possible. I had zero interest in developing the perfect
accounts-package or re-invent reactivity
I chose Meteor because I definitely needed reactivity and I got it for free. Also, reactivity is hard!
I chose anything that made my life easier, getting features done faster or made me write less boilerplate or jump through hoops. On the road this included packages like ViewModel, Astronomy and CSS-Modules, which all made a big difference. Two of those were, at the time, Meteor-only.
What’s the point of this
The hardest part of this field for me has always been the core ideas of how I’m going to solve the problem and how to make it nice and intuitive for the end user. It doesn’t really matter what framework or boilerplate generator I’m running under the hood when I’m actually building something. That’s just the crap you have to take care of before you can get stuff done.
I’ve seen a lot of polarized “I’m with Meteor” / “I’m breaking up with Meteor” posts here. I don’t have such strong feelings. I try to choose my tools wisely, then work with them and avoid changing them unless the benefits are real.
When my current project evolves to the next logical step and I need to build a separate complimentary web app, I already had a plan for the tech stack and it didn’t include Meteor. Today, I’m not so sure anymore. Meteor is turning out to be pretty awesome and very capable outside of it’s previous applications.