The State of Meteor Part 1: What Went Wrong
discovermeteor.com
The State of Meteor Part 1: What Went Wrong
1–10 of 189 posts
Re: The State of Meteor Part 1: What Went Wrong
#2This is a little worrying; after much research I'm starting a new project for a startup using the meteor stack.
Re: The State of Meteor Part 1: What Went Wrong
#3The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I'm firmly in that camp, for instance. I've been a huge fan of Firebase for a while because it frees me from the tedium of having to create another REST application just to talk to a database. If Meteor had, from the beginning, focused on simply being a kick-ass open-source alternative to Firebase they would be killing it right now.
It was a monumental task to try to create something that would please both front-end and back-end web engineers. Another issue with Meteor is that it was envisioned, not extracted. [1] From Rail's creator, DHH: "First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do."
Meteor was the goal, not an actual, real-world application. Often when this is the case the software ends up solving a bunch of problems that seem logical to solve, but in practice are not actually practical (another framework like this that comes to mind is the notorious famo.us project). Compare this to Rails and React which were forged in the crucible of real, day-to-day development and problem solving.
[1] - http://david.heinemeierhansson.com/posts/6-why-theres-no-rai...
Re: The State of Meteor Part 1: What Went Wrong
#4This is a little worrying; after much research I'm starting a new project for a startup using the meteor stack.
Why worry? Does it solve your problem today? Don't fall into the same trap that so many people fall into who worry far too much about how popular the tools they use today will be 3 years from now. Focus on what makes you productive now. Your startup has a far greater chance of failing than Meteor.
Re: The State of Meteor Part 1: What Went Wrong
#5This is a little worrying; after much research I'm starting a new project for a startup using the meteor stack.
Author here. Hopefully part 2 will answer your worries a little bit. In the meantime, check out Mantra [1] and the Meteor Guide [2].
1. https://kadirahq.github.io/mantra/ 2. http://guide.meteor.com/
Re: The State of Meteor Part 1: What Went Wrong
#6Personally, the one thing I don't like about Meteor is that it insist on using MongoDb. That along makes me NOT want to use it, despite other cool features.
Re: The State of Meteor Part 1: What Went Wrong
#7As long as there is no direct PostgreSQL support, Meteor is no viable option anyways.
Re: The State of Meteor Part 1: What Went Wrong
#8The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I'm firmly in that camp, for instance. I've been a huge fan of Firebase for a while because it frees me from the tedium of having to create…
Let's avoid turning this into a "Meteor is doomed" or "Meteor failed" comment thread; Meteor is and has been growing consistently since it launched (see: https://twitter.com/Rahul/status/673992512768507905). The title of Sacha's post reads a bit inflammatory, suggesting something "went" wrong and that it's too late now. Rather, as his post explains, the community is currently in a bit of an identity crisis as two groups with disparate sets of opinions on where Meteor should go from here collide.
As someone who's been building with Meteor since 2012, I see all of this as a good thing. It's a sign more and more people are lending their voices and opinions to Meteor's direction. As NPM support arrives with 1.3, and as a more agnostic approach to view frameworks becomes part of core, we'll continue to see more people join, because the platform will be more open towards them.
Meteor was a new platform. It's now a mature, growing platform. And it will be a successful platform if we all keep contributing.
Re: The State of Meteor Part 1: What Went Wrong
#9The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside.
What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices with meteor are pretty fixed.
But maybe I'm wrong, that's just how it looks like from the outside.
Re: The State of Meteor Part 1: What Went Wrong
#10The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside. What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices wit…
Same.
Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.