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