The guys at stateofjs have published their latest results here
Not particularly favourable results for our favourite framework 
2 Likes
Meteor is in a league of its own 
6 Likes
Itâs better than I expected, given the all the doomsday threads here the last year+
Intrstng that Meteor seems the most polarising of these options and the only one enjoying wide awareness a la express.
Marketing problem - 11k of the survey have heard but are not interested &
Buyer remorse issue - more would not use it again than would.
- Edit - 6k have used CSS before, but wouldnât use it again: full-stack fatigue ?
Definitive round up of the field anywayâŚthanks to whoever did it all.
3 Likes
I found that people with a negative experience were mostly expert beginners not aware of reactivity in general. Another common things they had was that they didnt understand the ability of working synchronously in Fibers on the server
1 Like
I know youâre being tongue in cheek here @msavin, but it really is. Meteor is much more than a framework, and canât be easily fit into any of the survey categories. Letâs look at each category from Meteorâs point of view:
- Flavours: Meteor works with the top 4 (ES6, ES5, TypeScript, Flow) and probably the others as well.
- Front-end: Meteor works with all of them.
- State Management: Meteor works with all of them.
- Back-end: I donât think you can really compare Meteor and the winner Express in the same category. Meteor uses and depends on Connect, which is essentially a scaled down version of Express (actually, connect was a hard dependency of Express until version 4). So while Meteor does well in this category, it essentially includes a large subset of the winnerâs functionality as well.
- Testing: Meteor works with all of them.
- CSS: Meteor works will all of them.
- Build Tools: The winner here (npm) is an integral piece of Meteor, and the others can be integrated with Meteor.
- Mobile: Meteor works with all of them
I think itâs safe to say that no other piece of JS based technology discussed in the survey results even comes close to matching Meteorâs capabilities when viewed as a whole. Meteor is much more than a framework, a library, a helper ⌠itâs a platform whose capabilities not only allow us to build apps more efficiently, effectively and happily, but also allows us to integrate with all other key pieces of the JS world.
Meteor
27 Likes
Haha no, Iâm serious. Why else would I be here?
13 Likes
In terms of branding and publicity, itâs doing better then I expected given all the FUD it had last year or so.
I do see marketing issue though, I agree fully with @hwillson assessment of the uniqueness of Meteor as a platform and I think many of us here recognized that as well but it seems that the rest of the JS ecosystem are either holding an outdated or misinformed understanding of the platform. From my experience, when you tell people about Meteor, they go home and do Google search and they run through some old articles questioning Meteor security (early days with autopublish) or scaling, and a lot of people back then wrote that itâs only good for prototyping or it wonât scale.
Itâs like someone who was initially perceived cool, yet young or amateur, went through phases of maturity and wisdom privately, and despite being transformed in that journey, many still perceive him in the old image as young and amateur. That image need to be changed, and Iâm guessing that many successful companies built on top of meteor donât announce it widely out of the fear of being associated with a tech that is falsely perceived as itâs just for prototypes or it doesnât scale.
Itâs a marketing issue and MDG canât run Facebook like marketing campaigns, so people need evaluate objectively, which requires effort and proper research. But the majority of people donât think objectively, itâs not hard to see why a framework like Meteor is superior especially for startups relative to whatâs out there, yet majority perception and valuation are usually formed by word of mouth (or old articles online, the state of JS, etc), what the authoritative figures in the community are saying, and their emotions. Just look at the Bitcoin hysteria, all of the sudden everyone is swearing about the tech and vision that changed very little since 2009 
12 Likes
Fibers are seriously a problem for newbies on the platform. They just arenât isomorphic.
3 Likes
What do you mean by isomorphic? I thought fibers were what allowed Meteor code to be isomorphic. e.g.
var post = Posts.findOne();
var comments = Comments.find({post_id: post._id}).fetch();
has the same result on the client, using minimongo, as it does on the server, using mongo, because fibers allow you to write syncronous code on the server.
A nice big version release - Meteor 2.0 - with some breaking changes might help?
To me, Meteor is mostly a zero config build tool, with a built in data system. I recently did a presentation (walk through app development). It was difficult to explain exactly why I use Meteor, other than vague statements like âI didnât have to spend a week hacking webpack,â and I donât have to maintain my build scripts, or keep up with breaking changes in whatever new webpack version came out this week. That doesnât really cover it though.
A question came up - what would you have to do to get similar functionality - I rattled off a few pieces of the stack - youâd have to set up (in no particular order):
- A build system with reasonable defaults - babel, react, and polyfill
- A database, and data delivery
- A user account system
- A dev server
- An always available socket connection
- Then thereâs Meteor specific stuff like perfect code splitting with dynamic-import - HUGE!
So to me itâs really the zero-config, and constantly updating (we are about to get babel-7!) development environment that I love. I get to focus on my own business logic, instead of constantly meddling with the build scripts. This has a lot of value to me.
I am curious what will happen with some of that - the easy data through Mongo/MiniMongo - what changes when that is replaced with the more open ended Apollo?
That said there is some room for improvement - particularly when it comes to offline support and web/service workers (really, if we had a server router exposed through connect or something, and the ability to add new build/bundle end points - thatâd make it all easier to figure out) - but thatâs coming too! Very exciting!
It might also be nice to have a CSS package similar to ecmascript which gives us some forward compatible CSS. I recently set this up in one project with PostCSS - itâs pretty sweet. I can use all the modern CSS features (including vars and nesting), and it compiles it back to contemporary CSS.
6 Likes
Itâs the Meteor API which provides isomorphism here, not Fibers. All Fibers do is act as an enabler for isomorphism on the server - there are no Fibers on the client.
IMO, async/await is (currently) the answer to true isomorphism on the client and server.
9 Likes
In that specific use its isomorphic - but outside of pub/sub, if you want to do any kind of thing with a callback API (like an HTTP request), itâs anything but. You can use async/await now, which is an improvement (the old way is you have to use some esoteric API - some wrapper - I canât even remember what it is, Iâd have to look it up). But even that has subtle side effects (if you use async/await - itâs like calling this.unblock() at each await statement).
Iâve run into a bunch of cases where I have to be very aware of Fibers and how itâs working differently on the server than the client. And itâs a very common topic of confusion on the Meteor Chef Slack for example. Itâs definitely not something that stays out of the way.
2 Likes
The perils of this.unblock() (with and without async/await) is something I discuss in Fun with Meteor Methods.
1 Like
I totally agree with @msavin - Meteor is in a league of its own. The comparison is not really fair (as already detailed by @hwillson) because Meteor is actually much more than a JS library, or even framework. Itâs a record-breaking, mind-blowing, super-cool zero-config JavaScript R&D lab and production line in one!
Itâs the most productive profit-making machine a JS dev can get their mitts on.
It boggles the mind that the proportion of those with âbuyerâs remorseâ is so high.
The reality is that some developers still donât understand that they are not paid to write code, but for delivering a product. So you can see why they might prefer to hack away at a Frankensteinâs monster of their own, instead of just curl https://install.meteor.com/ | sh and then meteor add <whatever-front-end>.
Could also be that the concept of reactivity scares the s**t out of children.
14 Likes
Thereâs an industry-wide ânot invented hereâ syndrome. Itâs an epidemic.
10 Likes
Weâve always been niche. Nothing wrong with that.
If you look closely, you can see âniceâ in ânicheâ 
6 Likes
This also goes to show that the majority of people prefer to just build the entire app themselves and choose exactly what they want to put in it and how it works. A primary benefit of React, for example, is that you can adopt it incrementally, if you want, even in a Meteor app.
I agree with their choice to categorize Meteor as a âback-end frameworkâ because thatâs mostly what it is. You can choose to completely ignore the frontend stuff if you wanted to. The fact that the most popular backend and state manager by far are still Express and REST just means that people prefer to build their stuff basically from scratch.
I will say that Meteor is an awesome tool for building apps fast, but itâs important for all of us to learn how it all works, too. For that reason, I wouldnât really call Meteor a beginnerâs tool either. Past the initial magic of âwow, I have a reactive full-stack app with zero effortâ comes plenty of hard work and a steep learning curve.
The âbuyerâs remorseâ @pal is talking about could come from the issues they run into after that magic wears off. Another possibility is that most of the people not interested in using Meteor arenât aware that weâre finally up to date on Node LTS.
1 Like
Iâm building websites for over 19 years now and I still donât understand the details of what my browser is doing or how NodeJS exactly works, but I still use them and rely on them, because both are critical for me and my goals. I would come even near where I am now if I would focus on these two things simply because of time constraints⌠That is besides the fact that I do like to read about those subjects.
Professionals as we are and should be, we should âtry to stand on the shoulders of giantsâ determine if the tool does the job and if that answer is yes, then go for it so we can focus on our own goals. Invest in your core business and leave the parts that is not your core to others.
Newbies in this landscape will figure out themselves if they need the knowledge to dive deeper. I learned it like that, many others do it like that.
Thatâs why I love Meteor. Meteor is my giant and it helps me reach my goals. That makes it my first choice by default.
15 Likes
I think you nailed it. I think MDG needs to give Meteor a fresh image, either by releasing a Meteor 2.0, or with an even more radical move like calling it âApollo Back-endâ or something.
8 Likes