I fully agree with @Spyridon and @iDoMeteor. I’ve been working with Meteor for the past year and as a company we have committed to it for the foreseeable future. Yes, it has some issues but what framework doesn’t? For me, the positives far outweigh the negatives.
It’s gotten to a point where I’m not visiting the forums and news sites as much to avoid the negativity. I will say this feels like it may be that a more vocal minority is causing this perceived negativity, my colleagues and I really enjoy developing with Meteor and will definitely continue to.
You’re right, I apologize for that. My goal with that title was to try and capture the sentiment of part of the community, especially people who tried Meteor once but gave up on it for whatever reason. And it was also a catchy title. But I should’ve given it more thought, taken at face value by people outside the community it implies that something major did go wrong with Meteor, which isn’t really true. “Growing pains” is more accurate.
Hopefully part 2 will be able to make up for it.
P.S. That being said, Hacker News is Hacker News… don’t pay too much attention to it!
P.P.S. Also, MDG (or someone else) can always piggy-back on this to defend Meteor and introduce all the new stuff coming out in 1.3. ; )
yeah this has probably already turned away a handful of new developers (or old too).
There are people who won’t even read the article, they’ll just cache the title and write meteor off next time they are considering a new stack…
It’s posts like this that will have a negative impact over time… I understand sacha was just trying for a click-bait title for the meteor community-- but it may have unintended consequences.
Meteor isn’t going to fall apart, as long as ditches the ‘all or nothing’ approach. You’re either using Meteor or you’re not. It is currently far too highly coupled. It needs to be more modular. And with the developments in 1.2 and 1.3, it’s obvious that MDG is making investments in making Meteor more modular, and these changes will have a solid payoff long term. That’s Part 2.
Blaze or React
Webpacks and other cutting edge stuff!
Just make it awesome and cutting edge!
People fear the change that’s all!
MDG is the most active Team I know and they keep going forward and letting the community choose whatever router, template engine or anything you want.
The only things they had to make from the start is the guide which is the real docs not the docs.meteor.com which is an API doc.
We need some good/advanced Tutorials from the MDG showing us (as they did with meteor React tutorial I liked it) how to use the best new technologies
People can keep using blaze and add react in the same time until they fully migrate to react (there should be a guide on this I think)
Just when you want to make a move a BIG one like the blaze to react explain why and give all the info we need to know not just some few words… or stressful things like this will happen within the community) Don’t let the rumors ruin it!
Just copying my reaction from the blog post, since it’s gotten no likes there, while I think it sounds pretty smart
Isn’t having a platform in a state of flux better than having a stale platform? Software that doesn’t evolve with its time, that’s something that would really scare me.
Meteor made me move from a Front-End Developer, to actually understanding databases, models, controllers… and even choosing a view layer. No matter what, you can still build a basic Meteor app very rapidly, you don’t have to choose React or Angular as a view… or wait for whatever database, router, etc… I think the fact Meteor is incorporating new tech a huge selling point for them.
I think the main problem is businesses picking up Meteor… and jobs being offered. I’m seeing more React and Angular jobs than any Meteor jobs. And that’s probably because they’re all set in their business stack ways, and just changing out the view layer in their apps. I wish there was more companies switching out their Rails stack to Meteor, or whatever “java” stacks. I would love to just work on Meteor… but unfortunately unless you develop a business from scratch, not many companies outside of California are even aware of it, it seems.
I’m spending most of my time just learning React and build tools, but I wishhhh i could just work in Meteor ugh
That’s a good way to sum up the situation. I think MDG is smart enough to do that in a way that doesn’t increase Meteor’s difficulty curve too much though. In fact I think this will smooth out the difficulty curve, instead of things being super easy in the beginning, and then hitting that wall.
Meteor’s main problem for me is scalability of queryObserve, especially for poll-only queries like geoqueries.
Real-time is becoming less of a requirement for me. The backend only needs to make things “just work” for my user. Most potential users saw the guts of my app as guts, where I see them as diamonds. I implemented a huge real-time data display for no reason.
“If meteor offers it, I should use it” is a dangerous way to think, and is probably a huge source of negativity for this framework.
So I stopped going all-out on meteor’s wicked awesome features. No matter how cool these hammers are, I only need one hammer for a thousand nails, unless I hire a bunch of people. It’s easy to use too many hammers with Meteor. Not only that, but sometimes a hammer isn’t even the right tool. It’s just that all you hear about is “Meteor has awesome hammers”
proceeds to apply the hammer to every nail, screw, and widget *
The most useful thing for me in Meteor is how the UI can simply update itself when the underlying data changes. I’m sure react is king here, but blaze has been good too. I’m happy to build my own data transport, just don’t make me handle the UI.
Consider me in the same boat. We’ve been working with Meteor for over a year and a half, and we couldn’t be happier with it. I honestly don’t believe we could have built such a great product with any other framework (or platform or whatever the hell you want to call it - I just call it awesome dammit). We launched our app a few weeks back and were immediately featured on Product Hunt. If anyone would like an example of an app and a company that is all in on Meteor and plans to be for the foreseeable future, feel free to check out our Meteor app, NimbleNotes. (Seriously not trying to plug our app here, especially with all the bad mojo, just want to show an example of what two junior developers and a designer were able to do with Meteor and Blaze)
It’s the first product any of us have ever launched, and our experience with meteor and the community has been extremely positive for the most part. I don’t know what the heck is happening on the meteor forums recently, but it’s started to turn me off of visiting this place. Maybe it’s time to spawn a happier place to talk about Meteor. I was a part of a LittleBigPlanet community a while back, and I can tell you from experience, with the right community managers, there can be some really awesome corners of the internet where people can go to have constructive conversation about the things they love. Maybe it’s about time for MDG to hire a community manager. Folks like Sashko are busy building great stuff and can only do so much. This place is starting to come off a bit whiny to me. If I see one more of these “the sky is falling” posts I think I’m gonna lose my mind. This is what the suggested topics are for me right now (the 3rd and 5th don’t look all that bad, but trust me when I say those threads have taken a major turn for the worse):
I think the problem is that all of us that are enjoying Meteor are off being productive with it, so we don’t have the time to come here and defend it, because we’re too busy building awesome stuff with it and ignoring the noise. Maybe I’m naive, but I just don’t see what all the fuss is about. You can build simple or complex apps with Meteor, and there are examples of multiple companies using Meteor in production with great success. We’re certainly hoping to join those ranks soon. Yeah, there have been bumps in the road, but Meteor hasn’t let us down yet.
That being said, thank you for everything you’ve done for the community Sacha, and for fixing that click-baity title. I’ve really enjoyed your articles, and you were very helpful when I was just getting into Meteor. Thanks!
@thomasmitchell Not to get off topic, but I have a similar project on my plate. In my company, we bought an enterprise web app that has hundreds of API HTTP endpoints supporting a horrendous UI. I was planning to build a new Meteor app that used those endpoints. I’d love to hear any suggestions you have about bridging the gap between Meteor and those endpoints.
@GeoffreyBooth The legacy APIs that I’m working with are thankfully not too bad so all our server side Meteor code does is provide a proxy between the new Meteor code and the legacy data structures.
We decided to write the Meteor side as if it were a brand new app which meant that the ideal data models we came up with differed somewhat from those on the legacy side. Instead of changing the front end to work with these sub par models we took the decision to reformat the data coming out of the APIs into our lovely new models (no compromise when it came to writing the Meteor code then). Same principal on the way back. Let the server side Meteor munge the data back into the old format. As far as Meteor is concerned, until we are actually sending the data to APIs, the models are perfect.
As for talking to the APIs we’re just using the HTTP package to send requests. Super simple, we didn’t have to do anything complex at all to get this up and running.
Yes, but not because we needed to make a super fancy, reactive app. More because running through the tutorials we found that it just made everything so much easier and quicker to implement than any other approach to front end dev we had come across.
I’ve starting build my own lighter version of meatier (available here). I still believe in the Meteor cause, but it no longer meets my needs. It’s a great prototyping tool, and it’s heading in the right direction, but I need the ability to go in and performance tweak things (e.g., 10x faster initial page renders) without limitation of framework code. The tradeoff is accepting the build-my-own toolkit approach to Node apps, but there comes a point where this is more desirable. I understand that many teams may not share my needs, but I hope Meteor folks find the feedback valuable. If I could npm install meteor in the future, I may consider re-incorporating it. I wish the best to the Meteor team.
Yeah one thing I’m really excited about, opened up by the 1.3 build tool, is the opportunity to publish all of the parts of Meteor as separate NPM packages so that you can mix and match as needed.
Of course that isn’t trivial because of some hidden dependencies between the parts, but I think it will be huge. Also, this kind of concern is exactly why the new data/GraphQL project will be totally decoupled from previous Meteor components.
