This is not a flame-bait post. I’m wondering how everyone feels about this topic.
While it’s great that MDG are offering more choices within the Meteor stack, at a certain point does it make sense to use Meteor at all if all you’re getting is a glorified build-tool?
I feel like the JS community’s moving too fast for MDG to keep up, hence why they’re downsizing the components that they are directly responsible for.
I personally am getting everything I need with Meteor, and couldn’t imagine most people would actually need all the extra stuff Meteor can’t keep up with so far. wouldn’t you agree?
Not necessarily, a lot of people are now moving to React, GraphQL, Webpack etc. Some are even foregoing realtime capabilities when it comes to scaling. It’s not long before you realise that you’re not as locked into Meteor as you may have been before, and maybe other technologies start to become more attractive as you can easily swap out Meteor for something like Phoenix for example.
I don’t see Phoenix giving me the developer experience, nor the pace of development/prototyping that I get here, especially when I don’t even need the kind of scaling Erlang offers in terms of sockets.
btw, what’s giving you the impression that a lot of people are moving to these other tech? beyond the forum (which is a small subset of the entire Meteor community), I don’t really see a lot of indications on users leaving the platform…?
Depends on your app I’d say. I really need the livequery capabilities a lot, so Meteor is the only way to go.
Even without livequery, speed of development is still unparallelled IMO (only the speed of hot reload is what really bothers me in Meteor).
However, in general it is true that the javascript ecosystem has evolved a lot, making it harder for Meteor to stand out. Some of the problems Meteor solves aren’t so much problems anymore today, but others still are.
I do think however, that MDG acknowledges this and it will embrace what’s good in the wider JS ecosystem and fill the gaps where necessary. For me that’s what Meteor is all about: a platform that fills the gaps. Where the gaps are will change over time.
For me and my own requirements I’m pretty much in limbo and it is frustrating me.
Meteor/MDG is pretty dedicated with their opinion to not offer first-class support for Polymer anytime soon since it’s not ready, which is just not true. Many large scale sites are using it and I’ve been using it in production for the past 2 months without major issues. So I’m kind of considering porting my meteor codebase over to something like Firebase knowing that it would live in an ecosystem/combination that’ll be supported or even encouraged for a long time by Google.
I really hope once 1.3 is out and the React stack has been fine-tuned that we’ll get more love for other libraries/frameworks, whether that’s best practices on how to implement library x into Meteor or for my personal needs of course, first-class Polymer support.
Personally, I think Polymer is just too heavy atm - it requires too many polyfills. Vue.js tries hard to stay close to the web component spec for example.
If you really want to use Polymer, why did you choose Meteor in the first place, knowing it doesn’t support it?
It’s a bit weird to pick a technology that doesn’t work with the rest of your stack and then complain that it doesn’t work with the rest of your stack.
The speed of development with Meteor can be attributed to Blaze only. Using React, Angular or anything else is certainly much slower in comparison.
I don’t know what gaps Meteor will be filling other than being an off-the-shelf build tool/generator comparable to Yeoman, if others are migrating to other solutions - eg. Phoenix, fullstack React, Firebase (with a node.js task queue for server-side requirements). Meteor’s scaling issues & overall operational cost become more of a problem at this point with other solutions being very viable.
Have you seen backand.com?
Agreed. Meteor makes more sense to me as a fullstack, off-the-shelf solution as opposed to the fragmented solutions we’re starting to see. At that point, using Express & NPM and having full control of the stack (while staying with Javascript) starts to make more sense imo.
The fact that React had to be shimmied in there isn’t the best of indications. SPA apps/frameworks are generally built without a hard dependency on the backend. I don’t like how we’re being forced down the React route. I mean, React is still quite young and some of us aren’t so quick to jump on the latest hotness at the drop of a hat (remember Polymer, Famous etc.)
I actually spend little time here as I find the forum to be very negative. But I do spend a lot of time in the Meteor Slack channel that Josh Owens runs and there’s some heavy hitters in there echoing the same sentiments.
Actually… there was an interesting quite extensive framework comparison a month ago or so, React has a larger footprint than Polymer and performance is equal, in fact Polymer even performed slightly better in most cases.
Polymer with shady DOM and React are essentially doing very similar things how they render components to the screen. Both have to generate complex DOM constructs. The difference is simply in how they’re processing/generating the DOM structure.
I want to use Polymer for the same reason I picked Meteor. It was bleeding edge and promised to build apps with state-of-the-art technology. I’m not complaining, I’m being disappointed and showing my frustration.
Polymer promises a more future-proven and safer way to write apps. In four years from now we’ll have another discussion and frustration in the community when everyone no longer uses React and people moved on to the next framework or a webcomponent focused approach - I’m not saying React is bad, it’s obviously great piece of technology. But it could even be replaced by new FB technology in the future.
Now I’m not saying this won’t be similar with Polymer, Polymer itself is somewhat an opinionated library or framework and we will definitely see code-rewrites along the way especially once more features get baked in right into the official webcomponents spec but at least it won’t be as much of a disaster as going from React to any other framework and these code migrations are already a carefully considered plan based on the philosophy behind webcomponents.
I want bleeding edge tech. React is bleeding edge no doubt but essentially both React and Polymer do a lot of the same things (actually Polymer can do a lot more than React can do. Again, not saying it’s better, you could argue for pure view layer React is better but it actually has a lot more extensibility in terms of what you can achieve with it). So I’m just a bit disappointed to see Polymer completely ignored and React completely embraced. In my opinion the first-class support in order according to priortity should be:
React
Polymer
Angular
Blaze
It’s ok that first-class support is somewhat based on popularity and that’s a valid reason for Meteor to do but it’s also somewhat short-sighted in my opinion.
Btw in regards to your Polymer/Famous comparison. I would say your comparison is not quite fair. Polymer was never hyped, webcomponents were but it didn’t make progress not because of the library itself but because of the disagreement of webcomponents. Which arguably is a good thing, since theyre a fundamental new technology that’ll shape web development for a while.
Polymer does get continously improved and the community while not as big as React of course is very active, whereas famo.us is simply one serious failure of a product launched and never improved or at least communicated well with the community.
P.S.: I’ve just visited their new website famous.co and had a serious WTF moment LOL
I agree, but I think of this as the trade-off that comes with less fragmentation… The decoupling in putting everything together yourself comes with the cost of complexity, and it’s not always worth it, especially not for smaller projects. But I totally agree, but I guess there’s a downside to every upside 
Negative indeed 
I have never used Slack, and dunno about it really. But yeah, I do understand why the more advanced developers would jump ship at this point. They want the cutting edge
I’m personally thinking about abandoning development all together and becoming a farmer.
Go with goats, I love goat cheese and would buy it from you!
Sorry Josh, will probably only have regular cheese in favor of cows (they, imo, are tastier than goats). Hope you and the community visit me at the ranch sometime.
Guys, FFS - can we stay on topic please? Thanks.
hopefully google buys mdg soon
BTW, when Googlers (maybe except for the Angular team) are asked “Angular2 or Polymer?” (Google is behind both of them AFAIK), they always answer:
“Only Polymer. BUT START WITH WEBCOMPONENTS! And only after your app is working, use Polymer for browsers that STILL don’t support WebComponents.”
This is the answer that I always get from them.
That’s because webcomponents is mainly being pushed by Google, it doesn’t necessarily mean webcomponents is the way to go.