I wrote a post about my interpretation of the current state of Meteor:
https://www.discovermeteor.com/blog/the-state-of-meteor-part-1-what-went-wrong/
I know the title might seem a bit pessimistic but don’t worry, this is only part 1. Part 2 will come out soon, and it’ll be a lot more upbeat ; )
And purely from a financial standpoint, it’s hard to build a
sustainable business on the back of new developers hacking on smaller
apps.
This explains everything.
A very interesting read, but considering the amount of negativity floating around at the moment I do wonder if you might have been better holding off releasing Part 1 until Part 2 was also ready to go?
To me this article seems so not negative at all. @sacha provides some perspective and has an open mind to the future and Meteor’s potential. I think these kind of efforts bring maturity and can bridge gaps. Afterall, we all like to go somewhere positive and build great apps 
Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching & management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up.
That’s the same sh*t I’m facing! Makes me now wonder should i continue or run back to Rails.
There is just one but…I still love Meteor. Routing should have been implemented in the core since 2012.
Can we get a sticky on the https://guide.meteor.com already so we don’t have to keep telling every new person about it…
@sacha thank you very much for that article! I am new to Meteor and I do agree with everything you have said. The main point for me is your “hitting the wall” part when beginner wants to go beyond the simple todo app tutorial.
I honestly don’t understand why:
Then - Meteor would be true Rapid Application Development framework that I believe would be used by many.
Please do not take this the wrong way, I am loving Meteor so far, but the problem is as stated by @sacha that while we newbs go beyond simple todo tutorial, we hit the wall hard (aka should I use this or that&if I do, how I should use it with this or that - is there some guide/tut for this or that etc …). I do not believe it is necessary.
Thank you for reading this little “rant” and my thanks to all community devs that made great tutorials and even better packages!
Personally, I think you should rename the article. I am a newbie. I did allot of research before discovering and choosing meteor. My point, your audience is much larger than the current community, A title inferring constructive growing pains. I have seen to many newbie come in to this forum complaining about Meteor problems. The truth is Meteor with Blaze still works and it works as well as it did before recent initiatives to expand the view layer, embrass npm, update to ES2015. It still works as a full-stack web-app framework. Just my 2 cent
And if it had of been, we’d likely be stuck with iron router with much more resistance to change.
I think whatever the benefits are of having a “default router in the core”, they are being overstated. It’s a one line command to add flow router for instance and once the meteor guide reaches maturity I imagine it will contain guides on how to use it since it’s now the “official” router apparently (it may well already but I haven’t looked at it lately).
I think that this is actually the nub of the problem. There are people who are looking to develop applications and there are people who are interested in “which router is best”. Now I am not saying that these groups are completely mutually exclusive but the fact is that if your focus is on developing applications then you need to focus on just that. Meteor is ‘sold’ as the easiest way to create reactive applications. In Sacha’s blog post he says:
[quote]On the other hand, many community members (myself included) have asked all along for a real framework. One that would make choices for you, and give you easy blueprints to quickly build apps. In other words, not just a few two-by-fours, but an actual IKEA kit.
In this alternate universe, Meteor comes with its own router, models, forms, server-side rendering, and all the other building blocks required by modern web apps.[/quote]
What would have happened in that alternative universe is that MDG would have had to make IronRouter and Blaze better
I look forward to seeing what Part 2 brings but it is pretty clear what MDG have to do if Meteor is to transition from cool buzzword tech into mainstream dev environment.
I disagree with this and think the fact that this misconception (in my view) seems to be a fairly prominent one is going to become a big issue when it comes to getting new developers to adopt Meteor.
I’m currently replacing a legacy UI with Meteor at my company and it’s going very well. Development has been super fast and frankly enjoyable and we’re pretty close to releasing an alpha version completely built with Meteor. 99% of the new codebase is client side code with the 1% of the server side code simply using node as a proxy to the existing APIs. There has even been talk of eventually replacing out legacy server side code using Meteor!
Granted, there were some issues when it came to deployment (running behind a context was something that required some hacking around in packages) but in the long run the advantages that Meteor provides far outweigh the few issues we have had.
yep, and this would mean, that IronRouter would have been developed all this time and might evolve into something FlowRouter is by now.
sure, but one line that makes all the difference for beginner - having default router in the core would mean majority of packages would use it + majority of tuts/guides would use it. So it is not just about “one line”. And experinced devs would do: meteor remove defaults and use whatever they want.
Exactly my thinking, having default router in the core have loads of pros and few cons. No matter which router is chosen. Same goes for view layer - React vs Blaze vs Angular - why? who will support it all - MDG ? Do they have man power & resources ? I guess they don’t. Will community support all three front ends with packages/tuts/guides ? Certainly not. Who loses in this scenario ? The newbs like me, lost in all these options.
I would suggest just select one router/frontend/dir structure and go with it. If advanced dev wants to use his custom parts, then he would do meteor remove defaults and that would be it for him.
I think the most important thing in front of MDG is to choose if they want to be RAD framework or wide platform for developing real time apps in js. (Imho, I would love to see Meteor evolving into first option)
Cool article @sacha but to my mind it’s missing one thing : why developpers like it at the beginning ?
That’s what we all could think. And it’s certainly the first thing that every developpers keep in mind but if you look deeper into Meteor concepts, i think that what make Meteor cool is all new concepts they bring with the platform :
Yes, indeed part of these are what you call Isomorphism, but actually, even React doesn’t bring the isomorphism to that level.
When i read all the future change in Meteor platform, i fear the future. There is hope, but there is also a lot of fear.
You write that MiniMongo is in danger. MiniMongo was an implementation of the client datacache concept. What will happen to that concept ? Will all the new concepts brought by Meteor Platform be simply trashed ?
What went wrong with the Meteor Platform ?
The main error is to keep Mongo to the only official DATASTORE solution. It prevents most of companies to use it, because mongo is maybe cool at first, but not so cool by the end. And Oracle, SQLServer or Postgresql / Mysql will still be prefered. So one solution would be to provide an implementation of how an application should communicate with the DataStore. And this should be isomorphic.
Not sure that React or Angular will still be used in 2 years, so providing a common entry point to all Meteor Concepts would be better than keeping Blaze up to date (even if i like Blaze).
Maybe the Meteor Platform should provide all interface to their concepts and don’t loose time on keeping up to date implementation of some bicks like the frontend framework, the realtime observer of Mongo… Because there is already solutions on the markets (React, Angular, VuJS, Ember… Postgresql, OrientDb, Rethink…) that are already used by companies and developers.
@sasha, why would you post your blog link here? Either publish your summary of things in a forum posting or keep your blog separate. We now need to reply in two places to the same topic.
This forum really needs moderation.
Our (fair and negative) evaluation of your blog post is here:
https://www.discovermeteor.com/blog/the-state-of-meteor-part-1-what-went-wrong/#comment-2468149190
We do moderate, there just isn’t any rule against posting your own blog post.
Blaze is being threatened by React. Meteor’s homegrown package system might be replaced by NPM. And there’s even rumors that Tracker and Minimongo might eventually disappears as well.
After that what is Meteor? A platform? A framework? None.
It is not the problem of new developers vs experience developers. It is the problem that MDG set the goals of Meteor but executed in the opposite direction toward the goals.
The most danger action is to destroy Meteor’s package system and melt it into NPM. After that do not say anything about Meteor platform It is better to say Node/NPM platform. After dissolve Tracker and Minimongo Meteor is nothing but several packages of npm. These are work toward to Meteor’s goals?
I can already imagine all the “I won’t use Meteor because it’s Bootstrap” or “Meteor is for Semantic UI so it’s not for me”.
CSS Framework should definitely be out of the core. It shouldn’t be needed to get rid of default CSS framework to use another.
Default boilerplate should definitely be out of the core, because it would work only for some applications. It shouldn’t be needed to get rid of default boilerplate just to start working with Meteor. There already is small boilerplate that I have to remove, why should it be any bigger.
I think we should make the distinction between the goal and how that goal is reached technically.
The large goal of Meteor is to make javascript development as smooth and easy as possible. The subgoals to achieve this might be: Reactive templating (Blaze), Reactive variables (Tracker), Client-side cache (minimongo), Build system
Now I don’t think these goals are changed. It’s just that there’s the reality that MDG probably doesn’t have enough resources to realize each of these in the best possible way and there are other JS projects that do a better job at some of these individual goals.
RXjs might be better than Tracker, Angular 2/React might be better than Blaze, Webpack might be faster for builds and hot reloads and there might be client-side caches with support for indexing etc. If Meteor manages to bring these together they are still building a unique platform with the same large goal as in the beginning.
Before Meteor HAD to build these because there were no alternatives available. Now there are, but bringing them together in a consistent platform is still a very valuable proposition IMO.
This is 100% correct. The goal is the same.