State of Javascript 2018 Results


#1

The results as always make for an interesting read.


#2

WOW, finally. I’ve waited for too long.


#3

Meteor isn’t doing that great in the results… clearly whoever runs that survey is biased against it!

(But seriously: I think it’s a shame that Meteor suffers from poor perception outside the community, and that MDG doesn’t seem to be doing much about it)


#4

I posted this somewhere:

State of Javascript in 2018

Summary:

  • male dominated
  • ES6 has been established with Typescript continuously growing
  • React and Vue have been growing while Angular plateaued with more JS devs leaving it
  • Redux is the established state management layer with high interest in GraphQL as the data layer
  • Express is the established node framework and Meteor getting less interests from developers
  • Mocha and Jasmine have been established (slight decrease) and Jest growing
  • React Native and Electron has a lot of interests while Cordova and Ionic are getting less

#5

Its a very painfull fact indeed. Unfortunatly most programmers are “do it yourself kiddies” that are more focussed on coding than on generating value.


#6

Really awesome work on the state of javascript, I really love the design and overall experience.

For Meteor and backend frameworks in general, it seems most JS developers don’t like frameworks at all, none of them are doing well, in fact some frameworks from walmart, uber, etc didn’t even trend. But what is interesting about the Meteor stats specifically is the high number of heard of it and not interested (50%!), I bet those folks encountered some of the FUD articles that where written in 2015 dismissed it and have no idea what changed in Meteor since then.

Here is a quote from one of my favourite authors pointing out the importance of fiction, stories and marketing:

Homo sapiens conquered this planet thanks above all to the unique human ability to create and spread fictions. We are the only mammals that can cooperate with numerous strangers because only we can invent fictional stories, spread them around, and convince millions of others to believe in them. As long as everybody believes in the same fictions, we all obey the same laws, and can thereby cooperate effectively. By yuval harari

And the fiction around Meteor out there is not doing it much favour so it seems.


#7

Hi Alawi.
I use Meteor for 95% of my work. I think its advantage is the simplicity of learning. But once you get past the basics, it does have a few gotchas which are annoying for me, primarily in Blaze.

  • what is ‘this’: in an onCreated(), onRendered(), onDestroyed(), helpers, and events.
  • where is my live context data? this data or Template.currentData()?
  • where should i be dealing with security? front-end, methods?
  • what the best way of merging reactive joined data.
  • how do I subclass templates?
    I have my head around these issues, and they are not a problem for me, as that’s part of the 2nd level of learning Meteor, but I think it may have thrown a lot of beginners off.

#8

I understand, but two points in respond to that:

  1. Meteor is not Blaze, we use Meteor without Blaze
  2. I used both Blaze and React and I can assure you that React has was way more gotcha then Blaze ever did

The stats says the 50% heard but didn’t even try so they don’t even count as beginners.


#9

Things I like the most of MeteorJS are:

  • Easy to start
  • Builtin build tool.
  • MongoDB
  • Works with React
  • Minimongo (easily sort, filter, cache)
  • Methods with DDP rate limit
  • Subscribe, for real time data (must be careful)
  • Server render for SEO

I only build some small/medium websites, those are enough.


#10

In the comparison

Years of experience breakdown for developers who picked “used it, would use again” for a given option.

Has Meteor the highest rank among devs > 20 years experience (even if the absolute value is low with 9%) and the second highest ranking for devs with experience between 10 and 20 years.

This is something that stands more important to me, than seeing it in the “avoid - low usage, low satisfaction” corner.

Considering this fact, I wonder how a tech gets this label / summary if well experienced devs used it and would use it again!? This raises concerns about the way they evaluated the poll.

As already mention (and reflected in the poll) the biggest issue is IMO the low public relations / marketing of the framework.

Edit: Most interesting fact:

Most disliked aspects of Meteor among developers who picked “used it and would not use again”.

Diminishing momentum/popularity

compared to

Most disliked aspects of Express among developers who picked “used it and would not use again”.

Clumsy programming style

:thinking::thinking::thinking:


#11

That’s an interesting catch as well, indeed it seems to have the highest ratio of experienced developers relative to beginners.

Exactly.


#12

The sad part is that this is a relatively low-hanging fruit compared to the amazing technical work that has already been put into Meteor over the years.

For example you could rename Meteor something like “Apollo Build” or “Apollo Kit” and brand it as an all-in-one back-end for GraphQL apps (basically what I’m trying to do with Vulcan). I can understand MDG not wanting to split their focus, but it’s still a little bit sad to think about what could’ve been…


#13

Exactly, I made similar suggestion to rebrand Meteor to Apollo Build in thinking about Meteor 2.0.

Technically, the closest thing that comes close to Meteor, at least in mind, is Uber’s fusionjs but even that doesn’t have Meteor’s maturity or the feature list.


#14

That’s interesting indeed. I’ve been thinking for a while that Meteor’s main problem is not the tech, but the marketing. There’s no clearly definable value/prop. It just has well thought out answers to problems experienced developers know they’ll run into. It’s an interesting problem to try and solve.

(Also, Meteor needs a better story on Windows!)


#15

I for myself understand Meteor as a framework for apps, where realtime multi user interaction plays a crucial role. I don’t see other solutions that come close to helping me realize projects / apps with this role in focus.

Of course it offers way more but this is some kind of value proposition of the framework that is the reason why it fits my use cases perfectly.


#16

I know it’s been almost 2 weeks, since your post @sacha , but I feel we are at an inflection point.

And if not handled well, Meteor will slowly fade away – likely following Galaxy revenues. Is MDG’s marketing budget the problem? If so, the community needs to step in (there are many ways to do that collaboratively) – combined with stubalio being gone (and he had left the forums a while back to focus on Apollo) I am getting antsy about all of this.

I also feel that people are getting afraid of JS frameworks (hence express is #1 – which is awkward)


#17

Well, my personal solution with Vulcan.js is to develop a new framework on top of Meteor that aims for the same goals at the “original” Meteor but using a more modern stack. The idea being that everything Meteor-specific is then abstracted away, so you only get the benefits of the technology without being weighed down by Meteor’s current bad image too much.

I can understand if that doesn’t work for everybody though, Vulcan is fairly opinionated and might not be suitable for all Meteor developers.


#18

Thanks @sacha

I applaud your effort in the loudest. My concern is that

  1. it’s hard for a small team to gather enough support in a crowded market, there is a lot of noise now
  2. this is especially true (as you have noted with different words in comments in state-of-js-2018) that nodejs server frameworks are being challenged
  3. we don’t all use React AND Apollo

In fact, while React has wind in its sail it seems to be slowing (VueJS is an example of competing framework) and I believe the community now realizes that VirtualDOM comes with problems (in this testbench redom is either similar or better – sometimes much better – in many tests: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html [filter by frameworks for an easier read])

Also, I am wondering if GraphQL is as hot as it used to be. In our case, we have custom pubs and man are we more efficient for reactive pubs.

If I look at the atmosphere packages we are using, they are very few (redis-oplog being the prominent one). So maybe the history of Meteor is hurting it, people are not realizing that the framework moved on to work with ES6, NPM packages, and dynamic loads (and almost all major UI frameworks)


#19

You hit the nail on the head there.


#20

I haven’t been around Meteor long enough to speak of the transition, I was really in when MDG was announcing that they were dropping support for Blaze (what a marketing fiasco!). Maybe we need to be active contributors? It would be in MDG’s best interest too. How about a MWG (Meteor Working Group)? We meet to discuss this and other issues, bring it up with MDG and have a concerted one-voice to the community. Right now … there is NO voice.