Yeah, the biggest issue is there are no meteor jobs… or at least so few that they are only going to the very top 1% of meteor developers
as oppose to rails or another javascript stack-- where there are shortages
lool
Moroccan company here north Africa bro 
and I know many people in the Europe using meteor for their apps bro 
1 Like
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!
12 Likes
@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.
1 Like
Quick question… did you buy into Meteor for it’s reactivity?
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.
2 Likes
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.
1 Like
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.
2 Likes