
The State of JavaScript – Survey results - ekianjo
http://stateofjs.com/
======
OhSoHumble
It's really unfortunate that so many people aren't interested in learning
Ember. I just started an internal IT tool in Rails and Ember and I'm _really_
enjoying the simplicity of it. I want something that is easy to understand,
easy to setup, and won't change for a while. I became more interested in Ember
when I read something online about how they are focusing on stability in the
long term instead of a bunch of features. There are also a couple of tools for
"just get it hooked up to rails, stupid" that helped me move quickly. As a
simple, simple guy - I really prize the "hey stupid I set it up for you"
command line tools that give me a starting point. Then I can figure things out
as I go along by making small, simple, controlled changes.

This is in strong contrast to something like Elm. I have played around with
Elm a bit but it's hard to wrap my head around some of the concepts and
setting it up with the back-end frameworks that I'm familiar with has been
meh. It's also changing rapidly so trying to figure out the concepts by
looking at real world examples doesn't help because of a changing language
specification. Going from changing the state of a counter to building out a
larger application has been somewhat difficult for me and I feel overwhelmed
every time I try to start a small project with it. I'm chipping away at that
with an Elixir/Elm project, however. But the overall point is that progress is
slow because it's such a different way of doing things and I get this gut
feeling that I'm drifting away from KISS principles.

I'm not a front end developer at all. I'm a systems engineer who dabbles in
web application development because it's fun and allows me to build some nice
internal tooling for other teams. However, because I don't have that deep web
experience I tend to gravitate towards the "old but still good" concepts and
frameworks. I'm much more likely to reach for jQuery and server side rendered
templates than I am for React or whatever amalgamation of libraries that
require an overcomplicated build tool.

~~~
joshowens
I suspect that we didn't get enough Ember responders, because I do think they
have a reasonable sized community. 9k responses is likely not enough to draw a
reasonable conclusion that it isn't popular. I wish we could have paired up
npm downloads or some other stat besides some of this data...

~~~
sotojuan
Ember has a pretty large community—the framework has a few conferences every
year that are filled up. Most Ember devs don't seem to participate in a lot of
JS community things and are very quiet compared to say, the React community.

------
morgante
It's nice to see some love for Apollo here. It's leagues better than Relay and
has definitely been the biggest boon to my development stack in a while. That
being said, the article should make it clearer that Apollo is perfectly usable
just as a frontend client—you don't have to adopt the backend at all.

The Meteor team really deserves commendations for learning from some of the
mistakes in building Meteor. Apollo specifically emphasizes incremental
adoptability: you can drop it into an existing project and see benefits almost
immediately, without having to refactor/rewrite any of your existing code.

I'd also like to provide a counterpoint to the inevitable complaints about the
complexity and low-productivity of a JavaScript. In my experience, once you've
paid the initial cost of learning these tools you can become extremely
productive. As a freelance developer who is paid a flat rate for projects, I'm
directly incentivized to find an efficient stack and the modern JavaScript
stack is definitely it.

Specifically, my stack these days is Django + Graphene + React + Redux +
Apollo. It's insanely high productivity: I can usually have the basics of an
app built within a few hours of starting.

~~~
djmashko2
(Disclaimer: I work on Apollo)

Yes, it was a bit surprising to see "Apollo" separate from "GraphQL" here,
since our primary focus is to enable people to take advantage of GraphQL no
matter their frontend and backend architecture.

It makes the most sense to make a direct comparison between "Apollo" and
"Relay", but they should both be considered a subset of "GraphQL", which is
really the core technology that everyone is building on.

However, excited that people like it, and we're excited to collaborate with
everyone to make it the best way to use GraphQL in an application!

~~~
k__
Do you guys know something loke Apollo but on top of RxJS?

I'm not a big fan of Redux anymore since I discovered observable streams.

~~~
djmashko2
Apollo returns the data in observable form. You never have to deal with Redux
directly if you don't want to. Check out the Angular docs for more details.

~~~
k__
It's also written in TypeScript, nice!

A few days ago I was thinking about using GraphQL in future projects and
didn't even find out about Apollo.

So it combines data retrieval via GraphQL with client side state management
via Redux?

~~~
djmashko2
That's exactly right. We're working on refactoring it as well so that it can
be used outside of Redux, here is one of the resulting projects:
[https://github.com/apollostack/graphql-
anywhere](https://github.com/apollostack/graphql-anywhere)

~~~
k__
you just stole my heart :)

------
inputcoffee
I appreciate that for the next year when there is a framework war I will have
a link to shut it down.

Typically a newbie will ask about which framework they should learn. There
will be a bunch of "it depends" and "try them out" responses, and then someone
will take pity and pick a clear direction based on their experience.

Well and good.

But this way the newbie can learn from the actual experience of lots of other
people. Data, for short.

~~~
at-fates-hands
>> Typically a newbie will ask about which framework they should learn..

Honestly the easiest way to learn this is to contact your local recruiters and
ask them to send you some openings for FED positions.

In nearly every one, you will see which JS framework is the main one they use.
In my recent experiences (the last two or three years) most corporate
environments are using AngularJS, while the smaller startups are using React
and some mix of various other libraries for their apps and sites.

There are still a few agencies I know using BackboneJS, since it was in that
first wave of JS frameworks and there's apps and sites out there which still
need supporting.

~~~
inputcoffee
Interesting approach, but I will note that even you have recommended three
(Angular, React and Backbone).

People generally put forward one of the following: Knockout (easy to learn),
Ember, Backbone, Angular, React.

Someone will invariably say no, use nothing but plain Javascript at first.
This will lead to a little subthread about whether it is fair to include
jquery.

Every now and then someone will come up with meteor or vue as an alternative.

------
aidos
I'd love to hear more from people that expressed certain viewpoints -
specifically those who used a library but wouldn't use it again...
Specifically mobx :)

I've played with most popular js libs now and I've found that for my use case
I wasn't totally happy for one reason or another. I've been dabbling in mobx
for that last few weeks and the ease with which it has allowed me resolve
issues in my codebase is really promising.

If anyone here is in the 58 people who wouldn't use it again, care to share
what you ran in to?

~~~
saosebastiao
After using Mobx for a few weeks, I've come to question why anybody would use
anything else. It is the _only_ software I've ever used that was created for a
dynamic language that has me trying to re-implement in my favored
strong/static typed languages. Now I just point and laugh at anybody trying to
make sense of their Redux global state atom with a bajillion reducers.

So far, I've only found one common objection to it: that it embraces mutable
state. Well duh... _UIs are state machines_. They need mutable state because
their entire existence depends on it. Sure, you might be able to model the
mutable state of UIs using immutable data _structures_ , but you can't get rid
of the mutable state. And because of this, my opinion of this objection is
that it is of a religious nature. You can ignore this particular objection
with no risk at all.

~~~
arxpoetica
I'm really interested in what you're saying about UIs as state machines. Do
you have any articles/references to back this up? Genuine curiousity here.

~~~
rifung
The person you're replying to didn't specify whether UIs are represented as
state machines which are finite or infinite, but I'll assume finite since
infinite automata are more powerful than Turing machines so they presumably
can represent something which is made by a computer.

UIs in general can not be represented by finite state machines. An example is
a page with a button which when pressed adds something to the page. Since
there are an infinite number of things that could potentially be added, this
can't be represented by a finite number of states.

On the other hand, I think many UIs could be represented by finite state
machines, although perhaps sometimes only roughly. You can start by trying to
specify that each instance of a specific page a user can see is presented by a
state, and any interaction with the user that leads to a different rendering
of the same or a new page is a transition. However, this fails to account for
things where a user can do something which doesn't change the current page but
might change a later page. You can account for this by having multiple states
which show the same exact UI but have different transitions to future pages.
Of course, it isn't just the user who can interact with your system to produce
a different UI for other people, so you'd have to model those transitions and
states too..

I'm not a front end developer so I don't know how many UIs can actually be
modeled this way, but I can see how it might be a useful way to think about
things, even if it isn't necessarily always correct.

~~~
saosebastiao
I didn't specify finite or infinite, and you're right that FSMs alone aren't
sufficient to describe all UIs. But they are sufficient to describe nearly all
interactive UIs.

Your infinite button example still has a finite state, but it's not modeled
explicitly, and would probably be a good idea, for very practical reasons, to
do so. If it really goes on forever, you'll eventually run out of memory,
whether that memory is managed by the rendering engine (appending dom
elements?) or by the language runtime.

> However, this fails to account for things where a user can do something
> which doesn't change the current page but might change a later page.

A Hierarchical State Machine model covers this scenario quite nicely...which
is exactly what React is.

~~~
rifung
Interesting. I hadn't heard of hierarchical state machines. Thanks for the
reply.

If you don't consider the infinite button example, then what other kind of UI
can not be described by a FSM?

~~~
saosebastiao
I've certainly never found a common UI pattern that isn't describable with
FSMs, but you could probably think of a few toy examples of non-terminating
state. Anything involving recursion, exponential, or asymptotic behavior for
example could theoretically involve infinite states. Again, likely of no
practical use.

~~~
DonHopkins
Read any real-world user interface specification like Apple's classic
Macintosh Human Interface Guidelines [1]. It specifies all kinds of complex
behaviors, like how pull-down submenus don't pop up immediately as you move
the cursor over them, and how dragging and dropping text handles the white
space at the beginning and end of the selection, or how adjusting the end of
the selection in mixed right-to-left and left-to-right text works, which is
much too complex and nuanced and ad-hoc hacky to describe with finite state
machines, and require a Turing complete machine to implement.

Even if it were technically possible to restrict yourself to a FSM, you would
end up going insane and producing exponentially explosive unmaintainable
finite state spaghetti machines.

There's a huge uncanny gap between what you can elegantly describe with a
clean mathematical abstraction like finite state machines, and what real human
beings expect and perceive to be easy to use in a real world user interface.

The polish of a good user interface is the result of millions of tiny little
scratches, and in practice that requires the power and flexibility of a Turing
machine (and not one stuck in the Turing tarpit like Brainfuck) to make all of
those tiny little scratches and cover all the edge cases and special
circumstances, because finite state machines are just too clumsy and not
powerful enough to conveniently cover that much ad-hoc messy fractal detail.

[1]
[http://interface.free.fr/Archives/Apple_HIGuidelines.pdf](http://interface.free.fr/Archives/Apple_HIGuidelines.pdf)

------
adjkant
As someone who doesn't work incredibly often with Javascript but has dabbled
with MEAN and extensions of MEAN, I found one of the last questions a bit
biased in its results:

"I would like JavaScript to be my main programming language" (Rate 1 to 5)

49% (5) 35% (4-3) 16% - (2-1)

If you've taken this survey, it means that you have done at least a decent
amount of work with Javascript. Chances are, you have at least enjoyed
something about it so far, or are absolutely required to use it for some
reason.

Of course many current Javascript users want it to be their main programming
language.

I love this survey for so many reasons, and this is an incredibly small point.
Personally, I think that a good Javascript tool, framework, flavor, whatever,
should be able to easily integrate with other technologies. I really enjoyed
Angular for that reason (yet to dive into React). I think the idea of
"JAVASCRIPT EVERYWHERE" is just really unneeded. Yes, we are stuck with
Javascript as a language. Yes, it should be more than a simple afterthought on
top of other tech. Making Javascript better and safer doesn't mean you have to
do it everywhere, because ubiquitous Javascript doesn't matter if the
different dependencies are completely different anyways.

The last part is only my opinion, but I wanted to add it because I think the
survey's nature is going to exclude many people with it.

~~~
DonHopkins
It would be interesting if they'd also asked "How many other programming
languages do you know besides JavaScript?"

And compared how many people want JavaScript to be their main programming
language because they only know one programming language and don't want to
learn another, with how many people know multiple programming languages and
would rather program in JavaScript as their main language because they like
JavaScript better.

------
pauljaworski
>Overall, developers are not happy about JavaScript testing.

This is because of the low percentage of devs in the survey who have used
Jest. I can't begin to describe the joy of finally finding a JS test utility
that just works and doesn't require a giant configuration file.

If you aren't using Jest, make the switch now! It's likely a lot of your
existing tests will work with Jest.

~~~
solidr53
I used Jest early on, it was nice, but I quickly started to encounter problems
related to how new it was. It's way better now, so maybe I will switch back to
Jest from enzyme.

~~~
cpojer
You can use Jest together with enzyme! We posted a big community update
together with Jest 16 which should highlight a bunch of ways that you can test
with Jest.

[https://facebook.github.io/jest/blog/2016/10/03/jest-16.html](https://facebook.github.io/jest/blog/2016/10/03/jest-16.html)

------
triangleman
I wish to register my complaint with the term "ES6" which has always been
unofficial and refers to the official standard "EMCAScript2015".

~~~
BinaryIdiot
Same. ECMA changed to using dates a while ago and people are still saying
"ES6" and "ES7". I've also seen people refer to _all new syntax and features_
as "ES6" including things that in ECMAScript2017.

Honestly though I think ECMA has some of the blame for this. I don't think
they do a very good job communicating changes and versioning.

~~~
DarkTree
Yeah I think there is just a lot of friction when moving from the concise
"ES6" to the lengthy, and somewhat awkward "ECMAScript2015". The fact that so
many people still use the terms ES6 and ES7 gives others even less incentive
to use the official naming scheme. Hopefully, it will iron itself out in the
future.

~~~
cloverich
I think its not just the length but the concept: Every other language has a
normal looking version (Rust 1.12 announced! Java 8, etc). They had that with
ES3, ES5, ES6, then decided (perhaps for very good reasons) to change to a
unique (?) version scheme.

~~~
slavik81
C and C++ also use years. For example, C99 was standardized in 1999. C++11 was
standardized in 2011.

------
epmatsw
Super interesting. Lots of data there.

Two things that stood out from a quick once-over:

Vue is doing better than I expected.

PostCSS is less adopted than I expected.

~~~
irrational
I just tried Vue 2.0 for the first time last week and I really really liked
it.

~~~
clivestaples
I had a similar experience with Vue about six months ago. I read the
documentation and then gave myself an hour with it. By the end of the same
day, I had re-factored a very complex dashboard and enjoyed every minute of
it.

My biggest complaint is that I love React/MobX and Vue which makes choosing
one over the other really painful. What a great problem to have!

------
vlunkr
For the life of me I can't understand why webpack has become the de facto
build tool. It's so much more complex than anything else I've tried. I
understand it's supposed to be faster, but still, I wouldn't bother with it
until your build times actually start to become a nuisance.

~~~
badthingfactory
What else have you tried? All of the alternatives have left me compromising on
the way I build my front ends. The docs for Webpack aren't great, and
configuring it might be a bit painful, but if there's a better option I would
love to know what it is so I can start using it.

Things I want:

* es2015 transpiling * jsx support * css/less/sass support * module loading * uglification for production builds * hot module replacement * source maps * multiple bundles/entry points * hashed file names

Brunch fulfills a lot of these requirements, and I use it when I need to spin
up an application really quick. But it misses on just enough items to make me
reach for Webpack when I build anything serious.

~~~
mikewhy
parched-tasks-webapp has all but one of those things (hashed file names), and
it's just built on browserify. And you don't have to do weird things to get
your CSS out of your JS on the server.

~~~
davidjnelson
Why not just use css modules with the extract text plugin to put everything in
a single stylesheet to solve that problem? For Dev it supports hot reload, and
other environments get an extracted stylesheet that works with sever rendering
and avoids fouc's. Plus you can autoprefix the output, and because of the css
modules design you get encapsulated component css for free. The annoyance is
working with a css framework or its js library, i.e.: bootstrap or material as
each one seems to have a different approach to css dependencies. But I think
those frameworks are becoming less relevant or can have their limitations
worked around usually depending on which one you choose.

~~~
mikewhy
When using browser-sync, which parched-tasks-webapps does, CSS is already hot-
reloaded, and there's no worry of configuring different "loaders" for the case
of a javascript file on the server trying to require a CSS file.

In both cases, the page is loading an external stylesheet, so both are as
susceptible to FOUCs as the other.

This is only my opinion, but using CSS loaders backs you into a corner where
your javascript file is suddenly less portable, since the environment it will
be running on needs to be aware of it.

------
bcheung
One thing I have noticed over the years is that the front end community is
becoming more and more a "let me google how to do it" kind of community. The
tooling ecosystem is so burdensome. Just to get a hello world app with React,
Redux, Webpack, esLint, and ES6 takes forever. Sure there are starter boiler
plates but they all don't seem to do quite what you need. Before it felt more
like a solidly engineered app, now it feels a lot more like glueing various
snippets from StackOverflow together.

I'm also finding the overhead from React / Redux very noisy. I have to do so
much typing and define the same thing over and over across a bunch of
different files just to do something simple.

I really like how Elm basically implements all of this with much cleaner
syntax and works out of the box. It's too bad it doesn't have as much
community behind it. I'd like to use it more but find it doesn't have enough
community for me to consider using it for anything outside of home projects.

~~~
ng12
I would only use React/Redux for a complex app that's going to be touched by a
lot of people. That's where it really shines. Elm is a non-starter in these
situations -- I can't seriously propose it for a project because the learning
curve is astronomical.

Also, I think simple Hello Worlds are a dangerous thing. They convince you
that a tool solves all your problems until three months later when you notice
your foot's been blown off.

~~~
gjolund
The learning curve is a weekend of reading.

Elm is much SIMPLER than js, but not as EASY for you because it is new.

If you are at all familiar with compilers, types, and functional programming
it should all be review anyways.

If not then you are missing a big part of your education and I would question
your capabilities as a programmer.

------
leshow
Gives me hope for Elm, there are a lot of potential converts out there.

------
anamoulous
I apologize if the predictability of this comment, but I just want to say, I
recently started a new gig at a company that has undergone a full on embrace
of Javascript for tooling and server side projects and it boggles my mind how
much productivity is wasted on this ecosystem. There is an interesting amount
of energy put into making asynchronous code read synchronously in situations
where asynchronous code provides no benefit. The dependency tree of any one
project tends to be incomprehensibly sprawling. Runtime version numbering
is... weird. Don't even get me started on the interplay of Gulp, Grunt,
Webpack and NPM. ES6 is bizarrely noisy. ESLint fascism is a necessity given
the history of legal anti-patterns the language must shoulder. Scoping can
occasionally lead to absurdist solutions [1].

I know this is the future and I'm trying to embrace it, but boy does it feel
icky doing it.

[http://stackoverflow.com/questions/33629343/what-is-the-
best...](http://stackoverflow.com/questions/33629343/what-is-the-best-way-in-
es6-to-assign-a-constant-conditionally)

~~~
Klathmon
Could it be that you are still just new to it (in the grand scheme of things)?

Because all of those things sound very similar to the complaints I hear from
web developers on their first foray into desktop development.

There are so many tools it's impossible to know them all (or to even know
which one is best to use in which situation), so much legacy code out there
it's tough to learn what the "right" way to do things is, it often feels like
you are fighting the OS or the language to get what you want how you want it,
and dependencies are hard.

Application development is hard, and is still far from "solved". And while the
"web stack" is far from perfect, I'm personally significantly more productive
in it than I ever was in anything else. And in my experience that extra
productivity makes better applications because I spend less time just trying
to get it working, and more time getting it working well.

~~~
matthewmacleod
See, I'm not sure that's the case.

When I started writing apps using Cocoa, for example, I had a pretty good
experience. Yeah, I fought some of the tooling that I wasn't really used to,
but given that it was quite different from my backgrounds in web and embedded
development, I was overall quite pleased with how easy and more importantly
how _obvious_ everything was. I found this to be the same when I wrote
applications in Qt, and also when starting to work with newer languages (like
Go).

This contrasts very much with the Javascript ecosystem. Despite having been a
nominal web developer for approaching a decade, I am still consistently
baffled by how difficult it is to get to grips with how everything is put
together. There seem to be dozens of different workflows, none of which are
entirely compatible with one another. There are bad configuration formats all
over. Every tool seems to be broken into 200 different parts that subsequently
have to be reassembled in order to implement a working pipeline. Documentation
is erratic at best, and so on.

I used to feel pretty productive with Javascript, back when the web was a bit
more 'Wild West'. But as it has developed as an application platform, it feels
more and more like I am _fighting the tools_ , rather than having them help
me. That's not a nice feeling.

~~~
dntrkv
My experience is the opposite. I've been working on the web for over a decade
now and only until a couple years ago have I really been happy with my stack.

My usual stack looks something like: Express / React / Redux / Webpack /
Enzyme / CSS Modules

I do SSR / Universal JS whenever possible and it works great. The only problem
on my stack nowadays is the CSS. Still haven't figured out a good flow. I
currently use CSS Modules, but without dead code elimination, it just doesn't
do exactly what I would like to (feed in the whole CSS library I use and let
it pick and choose the classes that are used in my components, throwing the
rest away)

Getting up to speed on all these tools hasn't been easy, but at this point,
most of my projects are a breeze. No worrying about browser JS support. No
worrying about CSS support. No more choosing between server side and client
side rendering. Linting that works great and keeps the projects looking clean.
Testing that doesn't make me wanna blow my brains out. Combining and minifying
projects is a piece of cake. HMR + Autorefresh is like magic.

I'm really enjoying working on the web now.

------
xirdstl
This year's "Used it before, would use again" is next year's "Used it before,
would not use again".

------
inputcoffee
So interesting I am still looking at it.

Suggestion: Add an optional section on _how the developer learned the
technology_

I think you could do a really interesting meta-analysis where you could see a
relationship between the way things were learned and the popularity of the
tool.

It would also be a great resource for people looking to learn a technology and
want pointers on where to start.

------
savanaly
Great job on the interactive presentation.

~~~
sgdesign
Author here, thanks!

~~~
thisisblurry
I agree; it looks really nice!

Minor nit: would you be open to using colorblind friendly color choices in the
future? The current colors are pretty hard for me to differentiate between.

~~~
sgdesign
Really sorry about that! I'll keep it in mind next time.

------
Roboprog
Some interesting things on the "Front End Frameworks" page:

* 53% of the respondents used React, and would do so again.

* 47% use "No framework", and would do so again.

(hmm. that doesn't leave much room, unless you can use more than one tool
depending on the situation)

* 43% had "no interest" in Angular 2.

One other thing to consider, of the "had used X, would/would-not use again"
responses: there is of course a lot of selection bias of whether or not to
even try X in the first place.

...

My only experience with these so far is Angular 1. It's easy to get started
with, but does get messy when you have a very large form (think "government
work"). I don't have a "React" axe to grind, I'm just looking at the numbers.

However, by the time I have to haul in Typescript transpiling, much of the
appeal of Angular 1 is lost :-(

(it feels like GWT, all over again, at least to some extent)

~~~
morgante
The way I read it is that each question is independent.

So I can say I've used Angular and would never use it again while also saying
I've used React and _would_ use it again.

This is really a pretty decisively positive stat for React. Very few of its
users would never use it again, while a lot of people have tried Angular and
abandoned it. (This certainly matches my experience and anecdotes I've heard
in the community.)

~~~
cloverich
> The way I read it is that each question is independent.

Mine as well. I have two active work projects -- one is React, and one is
plain Javascript. The latter is to keep the project extremely lean (mobile
form single time use type thing) and I've enjoyed using no libraries in it
(yet). So I would have responded positively to both of those questions.

------
dandare
What is meant by "Real-Time
Operations"([http://stateofjs.com/2016/features/](http://stateofjs.com/2016/features/))?
The description could not be more vague and Google does not know either.

~~~
dvlsg
I assumed they meant something like websockets or server sent events when I
took the survey.

------
FajitaNachos
I like the stats on the home page. A 53% response rate seems really good.

~~~
Macsenour
Is it me, or is 89 questions a lot of questions? I wonder if the number of
questions cuts down on the response rate.

edit: I assume it does, but what is the tipping point?

~~~
tracker1
I would think that next year, maybe staging into 3-4 different surveys may be
a better idea... a month apart even... that way there isn't the drop off on a
single survey.

I really do appreciate the format though.

------
platz
213 people put "never heard of it" for plain javascript

~~~
soared
Thats a surveyor because it sounds like an actual javascript flavor.
CoffeScript, Plain Javascript, TypeScript are all flavors.

------
golergka
According to the survey, 213 people that took it have never head of plain
javascript.

~~~
Aldo_MX
To be fair, a side effect of JS Fatigue is the inability to tell whether
"Plain JavaScript" is the newest kid on the block or if it really means "good
old JavaScript (ES3)".

Especially when the headline is "JavaScript Flavors".

~~~
talmand
Exactly, I've seen discussions about vanilla-js.com suggesting that people
thought it was a real framework.

~~~
hood_syntax
Poe's Law, maybe?

------
cstrat
I love Meteor and hope that it continues to grow!

I've been using it since well before v1.0 and can understand peoples
frustration around it. A lot of patterns and core themes have come and gone.
Allow/deny, blaze, and now it is sounding more and more like mini-mongo might
go the way of Blaze in lieu of Apollo.

Like I said though, I really do hope that the core values of Meteor stick
around in the framework and it continues to grow. I love it :)

------
xtiansimon
"It would also be a great resource for people looking to learn a technology
and want pointers on where to start."

Second that comment.

It strikes me as a brilliant that open-source programming languages should
have these sorts of statistics. I wish I could see every OSS language reported
like this...hmmm. I would replace the stock market ticker in my phone with
that!

------
nkassis
Noticed that under build tools, JSPM wasn't mentioned. Is it no longer
popular? I've had a ok experience using it and systemjs been pretty good so
far to get es6 module support and typescript working. I guess JSPM wouldn't
fit quite in the build tool category but I see no dependency management
section.

~~~
shados
JSPM never picked up. Its call to fame was that it was more "future proof"
using standards that were not actually standard, and had a pretty bad take on
pre-building vs building in the browser and stuff. It was slow (and the ways
to make it fast were very clunky) and generally, tools focusing on node/NPM
entirely ended up winning out.

------
arxpoetica
Anyone feel like piping in why Aurelia? It pops out in the data, but unknown
is satisfaction, etc.

~~~
nxtrafalgar
I also wrote my first SPA in Aurelia this year. As an introduction to the
Javascript world, it has been pretty good (though I would never use JSPM
again). Bugs are fixed in a timely fashion, the developers are responsive, and
overall my developer experience has been positive.

~~~
stephenhuey
I hear you, but now they're starting to make it possible to get away from
JSPM. I recently ported my "old" Aurelia app to the new Aurelia CLI version
and it's great!

------
increment_i
For me, the beauty of JS was in its simplicity - there were wacky edge cases
for sure, but here was a C-like language that you could use to build a project
that almost anyone could understand. When Node first came out I was over the
moon - wow, I can run processes on the machine from JavaScript?! Unreal.

It seems like I'm constantly keeping up with the complexity of the ecosystem,
which is taking a toll on my productivity. This is probably my problem more
than any specific failing of the evolution of the language, but, I like to
ship.

Just my 2 cents to the discussion.

~~~
nine_k
A "C-like language" is a very dubious compliment. Fortunately, JS is built
around a different core. Unfortunately, it's built as haphazardly as C has
been.

~~~
increment_i
What I mean is that its syntax is classical. Its constructs will be very
familiar to those who have taken basic education in modern programming.

As far as your 'different core' argument I'm not too sure what you mean. If
you're a Node dev, then JS is just your means of calling OS routines and
giving work to threads (in C under the hood, to be sure). If you're a front
end person, then JS is a very high level layer again, making calls various OS
services, probably in C++ or C.

~~~
Roboprog
I'm pretty sure the "core" reference refers to the "FP with OOP" core based on
Scheme and Self, which is one of the best things about the (JS) language.

Alas, "The Management" demanded that it be dressed up to look like Java (and
thus like C++). This led to a bunch of people that were unhappy that
Javascript was in fact _NOT_ like Java when they tried to use it like Java.

It's a very nice dynamic FP language, but people keep wanting to do static OOP
with it :-(

------
jaequery
After trying out Vue.js, I am pretty sure I will never go back to React.

~~~
pacomerh
Never say never. Thats what I thought when I first used Backbone

------
tiglionabbit
This makes Firebase look wildly popular. But can you even use Firebase for an
app where you don't trust every user to maintain your denormalized indexes
properly?

I asked this question on Stack Overflow to not much response:
[http://stackoverflow.com/questions/39800531/collaborating-
wi...](http://stackoverflow.com/questions/39800531/collaborating-with-
malicious-users-in-firebase-is-denormalization-up-to-the-cl/39805623)

------
zzguy
I really liked the "features" section. I've seen some weird things done in the
wild to obtain some of these features. Like building a multi-SPA to obtain
code-splitting where a site is split up into multiple pages each acting as
their own SPA. But it does seem like things are settling down. Envious of all
the people starting now. As someone who started web dev in 2010, anything I
learned that was framework-specific then, is almost completely obsolete now
lol.

------
zkhalique
I am going to mention our framework, since I think it's relevant, but it's not
just a JS framework. It's a fully integrated platform:

[http://qbix.com/platform](http://qbix.com/platform)

[http://qbix.com/platform/features](http://qbix.com/platform/features)

Would like to get some feedback on it, from anyone who looks through the
features.

------
aws_ls
Its a great and useful survey. But would have liked to see a question(if not a
complete section) on search engine optimization(SEO). Most important thing for
internet apps.

For enterprise apps it doesn't matter and for that you can safely use a
framework like React. But its very crucial for Internet apps. Surprisingly,
Google neglected building tools in that area, apart from guidelines via its
webmaster blogs.

------
ahunt09
"the thing that stands out right away is how the React row just lights up
compared to the other front-end frameworks. In other words, React users are
more likely than average to have experimented with multiple other
technologies."

I believe the data wrongly indicates this because React, Redux and Webpack are
used together to achieve things that both Angular 2 and Ember solve similarly
internally.

~~~
rajington
true, but i think even a lot of the other non-coupled technologies have higher
numbers, but it's hard to say if that's higher percentages

------
ufmace
Nice article. I started a new hobby Rails project a couple of months ago and
was a little surprised to see that even Rails 5 still defaults to
Coffeescript. Googled around a bit and decided to drop it, as it seems to be
more or less abandoned these days, which this survey seems to confirm. I
wonder if/when Rails will switch to ES6 or something?

~~~
inimino
CoffeeScript was designed by and for Rubyists, so it makes sense that they'd
be the last to drop it.

------
brlewis
I don't have time to go into details at the moment, but I'm using, loving and
recommending Mithril.

------
foo101
Why are ES6 and JavaScript treated separately in this survey?

I thought ES6 is just a new version of JavaScript (the ECMAScript standard)? I
thought both are written using the same HTML <script> tag. Why is it necessary
to consider ES6 different from JavaScript in this survey?

Could you please throw some light on this?

~~~
Aldo_MX
Why shouldn't it? You still need to transpile ES6 to ES5

~~~
foo101
Thanks for the answer. I was not doubting the survey methodology or results.
My question was simply out of curiosity.

I would like to request more details on your answer.

1\. What kind of ES6 requires transpiling to ES5. I mean, I once tried using
Promise and something like Promise.resolve("foo") works just fine. Are there
any ES6 constructs that would require transpiling, to work fine on, say,
Chrome or Firefox?

2\. Is ES6 not completely backward compatible with ES5? If yes, I would
consider ES6 as the same (although upgraded version of) language as ES5. If no
(e.g. Python 2 vs. Python 3), then it would be justified to consider ES6 to be
different from ES5. What's your opinion?

Disclaimer: I am not a JavaScript developer. I am a system programmer. But I
do a little bit of web-designing once in a while, for example, to maintain my
blog etc. That's why I would like to understand why ES6 is considered a
different language than ES5.

~~~
SiVal
Here's a little bit for you. Most people prefer the semantics of `let` to
`var` for variable declarations in JavaScript. It's how JavaScript should have
been designed from the start. It has been officially standard for a year or
two and became available in some browsers even earlier.

I want to use `let` (and `const`) for everything and never use `var` again,
but I couldn't even do that on my own PRIVATE website (for me alone) until
today, because I didn't upgrade my iPhone to iOS 10 until last night, and iOS
Safari never supported `let` (or arrow functions or so many other things)
before v10 (and Apple won't allow anyone to break their browser monopoly on
their platform).

I could just use Android, but I can't switch everyone else to Android, and
LOTS of Android and Windows (and even Mac) users are stuck with even older
browsers, because they don't know how to (or can't) upgrade.

 _Are there any ES6 constructs that would require transpiling, to work fine
on, say, Chrome or Firefox?_

Not on the latest Chrome or Firefox, but that hardly matters in a world where
so many people aren't using the latest Chrome or Firefox. The question for a
developer is not whether some in their market can run their software but
whether some CAN'T.

 _Is ES6 not completely backward compatible with ES5?_

It is (in practice) completely backward compatible, but I suspect you are a
little confused about what that means. It doesn't mean "forward compatible".
Backward compatible means that a new ES6 browser is still compatible with old
ES5 code, which it is. Old ES5 code will keep working. It does NOT mean that
my new ES6 code, full of `let` and arrow functions will run in an old ES5-only
browser, and there are still plenty of them out there.

As long as you choose to target a market that includes ES5-only browsers (and
you may or may not, but if you do), the things that are new in ES6 (Google
"what's new in ES6") have to be transpiled to ES5 to run in ES5-only browsers.

~~~
Roboprog
I get "const", but is "let" really that big a deal? Are your functions so
deeply nested that you need block scope inside of if statements and for loops?
(vs forEach callbacks or IIFE blocks or simply splitting complicated stuff
into smaller functions)

There is some cool stuff in ES6, but "let" is kind of a yawn, and "class" most
definitely is _NOT_ something I really needed.

But I'm still running ES5 on IE11 at work, so it's academic :-(

~~~
Aldo_MX
Sometimes you just need to do something the old way:

    
    
      let element = document.getElementById('some-element');
      while (element) {
        // do something
        element = element.parentElement;
      }
    

let doesn't get in the way with behavior such as hoisting, and the code will
break if you redeclare a variable.

~~~
Roboprog
How does var/hoisting get in the way of that, or at least, that particular,
construct?

FWIW, that would also be a nice "for" loop :-)

    
    
        var el
        for (
            el = document.getElement... ;
            el ;
            el = el.parentElement
        ) {
            // do something
        }

------
novaleaf
Why no section on server-side frameworks? I for one picked Hapi over Express a
couple years ago and have been very happy with the switch. I'd love to know
what has changed since then!

------
labrador
I would respect the JavaScript so much more if there wasn't so much
faddishness - somehow JS devs have decided switch statements are bad,
indenting with 2 spaces is the only way to go, semi-colons should be banished
and "boilerplate" code should be hidden in libraries the magically wipe it
away so your code looks "clean," if barely understandable without reading
through a bunch of libs.

Edit: forgot to add that these are my initial impressions after diving into
front end development with node and browserify. I ended up avoiding a lot of
pain by just using TypeScript and a make file. Who has time to wade through
umpteen million build systems?

~~~
BinaryIdiot
> somehow JS devs have decided switch statements are bad

Nonsense. Though sometimes using an object can look cleaner depending on your
use case.

> indenting with 2 spaces is the only way to go

I love 4 spaces and I use 4 in my JavaScript projects. Just because you've
seen some subset of people use 2 doesn't mean it's the majority, what you have
to use, etc.

> semi-colons should be banished

Absolutely, positively NO. Semi-colons are a requirement of the language. Some
people elide them, incorrectly, because the JavaScript engines are good enough
to still handle it. In my experience being playing a limited part in open
source JavaScript eliding the semi colon seems to be a rarely done practice.

Regardless it's incorrect no matter how you slice it.

> "boilerplate" code should be hidden in libraries the magically wipe it away
> so your code looks "clean,"

This sounds more like a rails-ism than a JavaScript-ism. Though you'd be hard
pressed to find libraries without implicit behaviors in every language. Some
people take DRY way too far.

This point just seems more anecdotal than anything else.

> a make file. Who has time to wade through umpteen million build systems?

A lot of JavaScript devs use make. Nothing wrong with that.

~~~
Roboprog
I think the semicolon requirement is more for broken minifiers than actually
making the unpacked code clear/correct. But that's just me, I guess, as I have
worked with many line oriented languages, and have no reverence for C syntax.

------
VOYD
Nice design.

------
jack9
When I finally ended on the IDE page, I realized how the vast majority of
these "5-10"\+ year veterans were very primitive developers. If you're using
Sublime or Atom for Javascript development, I would say that you've spent too
long working in and around these ever-changing tools without a useful IDE.

~~~
erikpukinskis
I'm happy coding in WordPad, GEdit, etc, and use Sublime today.

My view is that if you need an IDE to maintain your code effectively; if your
volume of edits is such that macros and navigation tricks make a meaningful
impact on your pace of development, then your code probably has serious
architectural problems¹.

You see all impediments to action as debilitating, but I think impediments,
carefully curated, can provide useful constraints on my development process.
Friction helps me see where my interfaces are getting strained.

¹ I feel bad writing this because I know, if I step back from my own
preferences, that your approach to development probably works great too. But
your claim was so insulting, I'll leave this as is to match your tenor.

------
z3t4
More info about the participants would be nice. How where they chosen ?

------
wiremine
Side note: The web design reminds me of the late 1990s... funny how it comes
around.

------
FrancoDiaz
_ES6, CoffeeScript, and TypeScript all have near-perfect awareness, which
surprised me since TypeScript isn’t quite as popular as the other two yet._

I take issue with that statement. Just anecdotal, but I think these days
Typescript is much more "popular" than CoffeeScript

~~~
tomatsu
Anecdotally, CS appears to have lost quite a bit of popularity while TS gained
some.

RedMonk seems to confirm these trends. TS grows while CS stagnates:

Q1 2016: [http://sogrady-
media.redmonk.com/sogrady/files/2016/02/lang-...](http://sogrady-
media.redmonk.com/sogrady/files/2016/02/lang-rank-944px-wm.png)

Q3 2016: [http://sogrady-
media.redmonk.com/sogrady/files/2016/07/lang....](http://sogrady-
media.redmonk.com/sogrady/files/2016/07/lang.rank_.Q316.plot-WM.png)

~~~
davidjnelson
Ts seems awesome but it looked like kind of a pain with separate ts and js
files, mandatory type definitions not being present for lots of dependencies,
and back when I looked at it seeming pretty all or nothing. I like flow. The
people that built ts are brilliant too though. Curious if anyone has a good
comparison between flow and ts. I've heard ts has improved a lot lately.

~~~
bostonvaulter2
> mandatory type definitions not being present for lots of dependencies

That is the biggest detriment to typescript in my book. I played around with
it for a bit but finding accurate (and up to date!) type definitions for
external dependencies was a huge pain.

------
grabcocque
This seems to suggest the rate of framework churn has rather settled down. Are
JS devs finally starting to be satisfied with their current tools and not
needing to restart every 18 months?

~~~
ng12
I see this same, tired old meme in every thread about web technologies.

It's funny to me that certain people are so disdainful of the churn in web
development on a forum dedicated to "hackers". Web application development is
hard, and the reason why there's so much churn is because smart, inventive
people are constantly finding better ways to do things. Things aren't just
resetting from scratch every 18 months. The web apps I'm working on today are
way more modular, composable, testable, and maintainable than the ones I was
writing as little as two or three years ago. Just because Java systems
development hasn't changed significantly in the last 5 years doesn't mean Java
devs are any more or less reasonable developers than web folks.

~~~
SeanDav
> _"... the reason why there's so much churn is because smart, inventive
> people are constantly finding better ways to do things."_

It also follows that at some point, these smart, inventive people will come up
with fairly stable frameworks that are sufficiently flexible and powerful to
accommodate most of the problem space out there. It is reasonable to ask if
such a point has been reached...

~~~
fail2fail2ban
JavaScript has been around since the 90's; a quick scan of this page reveals
around 2 dozen JavaScript technologies. The only solution is to remove
JavaScript from all browsers and replace it with Java.

~~~
davidjnelson
Try GWT ;-)

------
meira
Great report.

I'm very satisfied with Clojurescript.

~~~
bpicolo
Bit weird that the "Web Framework" section didn't have any Clojurescript libs
at all considering it was on the list, heh. Re-frame, Om... Mobx looks pretty
based on reagent, heh

------
SadWebDeveloper
Never heard of the survey maybe the data is biased to only approach people on
the silicon valley where technologies are used as if they were current season
premium fashion cloths.

~~~
joshowens
9k responses certainly weren't from SV alone. I know alot of the Spacedojo
Slack channel took the survey and I think like 2 out of 300 live in SV.

Would be fun to maybe turn ip addresses into lat/long and map out where the
responses came from...

~~~
SadWebDeveloper
exactly this is my point, maybe the data is biased to US developers mostly

------
carapace
(Thin sans-serif grey body text means you hate your readers.)

\-----

edit: I've tried to read it now and this site is crappy as hell. Does anyone
have a link to a coherent write-up of these results?

\-----

Furthermore, I know it's bad form to mention your own downvotes but I dare you
I DARE YOU to make a case for that horrible font choice. You can't because
it's pure vanity. Style over substance. Thhhpppppt!

