
The State of JavaScript 2017 - beefman
http://stateofjs.com/2017/introduction/
======
jorblumesea
Personally found Webpack to be really heavy handed for what most developers
need it for. Gulp on the other hand seemed easier to just build exactly what
you need. Webpack felt like an overly complicated poorly documented black box
that seemed to work by sifting through github issues and comments. You spend 2
days getting it into some semblance of a working state, and never touch it for
fear of introducing a new issue. Gulp just...worked, and with very little
fuss. Sadly React seemed tightly tied to webpack so if you want React you're
tied to that toolchain.

In general I think tooling needs to improve, and neither Webpack nor Gulp are
painless. Neither is maven, I suppose...

~~~
thelarkinn
Hey thanks for the candid opinion!!! Sean from the webpack team here!!! Maybe
it's been awhile since you have taken a look at our documentation!
(webpack.js.org)!

I think something that individuals who try to make comparisons to their
backend tooling that "just works" is that none of these tool have ecosystem
constraints like the Web. I wanted to really talk about something that is
important to understand about tooling, and why webpack might have some of the
features it does.

In the web, you should only ship no more then ~<200kb of JavaScript
(uncompressed), for your initial download. From there, you should be
"dynamically" delivering JavaScript asynchronously in bundles/chunks. In
addition, there are multiple module types that exist in the JavaScript
ecosystem that libraries are published in. Sadly, some of the most popular
libraries are being published with AMD Modules, or CommonJS, or no module
system at all, and there is no consistency or way to know this about those
modules without looking at their source code. Therefore, webpack out of the
box supports the ability to load all of them. Not only that, but we employ a
set of plugins that help optimize code using complex topological sorting, (aka
things you'd probably never want to implement or hand optimize yourself) to
ensure that your delivered code is the smallest possible.

Compare this to C++, or any "build" static toolchains. There are really _no_
size limits for the amount of dependencies or code that needs to be linked
together. Therefore, there is no care in the world for application developers
if they are generating 600GB Video Games, 10MB-100MB Applications, etc. Think
if there was 5 ways to write C++ Modules/Java Modules, etc. and you had to
apply the same constraints as the Web. (You'd probably see a lot more
webpack's or a lot more convention tools that wrap things like webpack).

Anyways, as a maintainer of the project, we can't say this enough: "We are
owned by our community". This means that if there are things we aren't doing
right, that we owe you to make things easier to use, more conventional, when
needed, and progressive in a way that lets you layer features and need on top
of an awesome, and fast core product <3.

So if you have great ideas, please let me know. :-D

~~~
dorian-graph
> Compare this to C++, or any "build" static toolchains. There are really _no_
> size limits for the amount of dependencies or code that needs to be linked
> together. Therefore, there is no care in the world for application
> developers if they are generating 600GB Video Games, 10MB-100MB
> Applications, etc.

Huh? Seriouosly? Embedded devices can be any size people want? Some software I
develop uses C, Go, etc. and it would be nice to not have to worry about built
artifact sizes. Admittedly I find it kind of fitting and funny that someone
who maintains a popular JS library thinks that the web is the only (?)
platform with build size (and possibly other) constraints, haha.

Anyway, I do appreciate your work in helping maintain an open source project,
so keep that up.

~~~
kangoo1707
But on embedded devices, do they download the whole artifact again and again?
On the web this is a real issue

~~~
jononor
No in embedded if it is to big it can't fit, full stop. One byte too much
means corrupt firmware.

------
Xeoncross
Looks like vue.js is doing great marketing (even if just word-of-mouth).
Almost half the participants say: "I've HEARD of it, and WOULD like to learn
it".

Meanwhile, react.js has over half the participants saying: "I've USED it
before, and WOULD use it again".

~~~
baby
Recently chose Vue.js over React, and it's been great! React was a pain to
learn imo and Vuejs really made everything smooth and easy. Just my 2 cents.

~~~
ggregoire
How is React a pain to learn? It's the most simple framework I've ever
learned. I can count all the methods/concepts on my fingers: components,
state, props, setState, render and 5 or 6 lifecycle methods you occasionally
use (componentDidMount and so on). The rest is vanilla JS.

I coded with Angular 1 for 2 years and had to open the doc each time I wanted
to use ngRepeat…

~~~
maaaats
React is easy when you just do data -> rendering. But what about animations,
modals and other forms of interactivity that doesn't fit squarely into this?

And while React is simple, you quickly have to add a router, some state
management etc., so instead of a small simple library most React-projects I
have seen end up being a custom framework.

~~~
mlsarecmg
None of these things come with Vue out of the box. The only difference is,
React has often many solutions and massive community support to chip away at
something until the very best stand-out solution emerges: redux, react-router,
next, etc. React encourages this by staying out. Usually it then trickles down
into other eco systems (vuex, vue-router, nuxt, element, ...). If something is
very stable or close to perfect it's going to be made official, like modals:

Modals:
[https://reactjs.org/docs/portals.html](https://reactjs.org/docs/portals.html)

Or animations (in react-native at least, but if you click the link you'll see
it works for the web just as well):
[https://www.webpackbin.com/bins/-KfKys3S2mgEH9UsE8GL](https://www.webpackbin.com/bins/-KfKys3S2mgEH9UsE8GL)

In Vue you're pretty much in the rain. The community isn't encouraged to
explore due to half-baked-in solutions, and baked in stuff in general is
browser-complacent and thereby very limited. So you get css class animation
groups (=react-animation-group), state is a one trick pony tied to the lib,
theming isn't considered. There are so many open gaps and holes in the eco
system at large, i'm scratching my head over how this would possibly be a plus
or easier to the developer. It is often not.

------
vjeux
This is so exciting that prettier is being used by 15% of people that
responded to the survey, it hasn't even been a year since it was open sourced!

~~~
cpburns2009
Prettier could really use some example inputs and outputs for the supported
languages. Sure, all of the settings appear to be documented in the API, but
there's no concrete examples. I'd like know if its defaults look reasonable to
me. I've seen some weird JavaScript conventions which makes me leery (e.g.,
jQuery). And I don't even know what that JavaScript/HTML hybrid is in the
"Playground".

~~~
rattray
A PR with this would likely be very welcome!

------
natural219
Interesting to see that Webpack has continued to gain ground on Gulp as the
leading top-level build tool that people use, because from my experience it
seems slightly over-engineered for 99% of use cases.

Webpack uses the "configure a black box + add a bunch of plugins" approach to
the front-end build pipeline, whereas I recently used Gulp to create a
beautiful build workflow using Rollup, Babel ES6, JSX, Sass, and a basic
livereload webserver in less than 80 lines of very readable, plain javascript
code that would take roughly 5 minutes to explain to a new developer on my
team faced with build pipeline modifications.

I also don't think many people understand that using Webpack encourages non-
ES6 import semantics that will break your source code if you ever decide to
switch from Webpack. Encouraging things like "import app.css" seems like it
might confuse junior developers who don't understand what's going on under the
hood, or have to eventually work in non-Webpack systems.

Sorry for the rant here, haha, I'm a huge fan of these surveys and love taking
the opportunity to talk crap on build tools / frameworks :).

~~~
megaman22
The whole front-end build process ecosystem seems hopelessly complicated and
frustrating to me, but I'm a hoary, old, nearly thirty, backend developer.
I've yet to have anyone satisfactorily explain why grunt or gulp or webpack is
better than makefiles and shell scripts, other than "But its JavaScript!"
Every month or so, dependencies break, and everything changes; it seems like a
lot if work for very little result.

~~~
natural219
Bash and C absolutely suck to work with if you're not a systems developer.
There's so many caveats, gotchas, extra ways to do things, hidden things you
have to learn, and lack of clear explanations that touching any ordinary shell
file makes me want to scream.

If someone wrote a "makefiles for web dummies" tutorial that told me exactly
how to do things everything in bash I know how to do with javascript, I'd love
to read it.

~~~
megaman22
Make is it's own thing, and not really tied to C in any way.

I've written more makefiles for Java projects when I despised Eclipse than for
any other reason. I'm sure that's completely wrong and fucking awful, but it
worked really, really well.

~~~
h_r
While I can somewhat sympathize with wanting to use make, it's the dependency
management with Java that would be just horrible. Maven-based dependency
management saves you a world of misery most of the time. And when you have
conflicts to deal with it's 1000 times worse doing it by hand.

------
kenhwang
How did 18% never hear about "No Framework"? Isn't that the default option?

~~~
RobLach
4.3k people never hearing about using no framework for the frontend gave me a
good laugh particularly re: the state of javascript.

~~~
quickthrower2
Maybe they think it is a new framework with the name "no"

~~~
ChrisSD
It's a rival to [http://vanilla-js.com/](http://vanilla-js.com/)

~~~
intrasight
I built my commercial SaaS last year in vanilla-js as am very pleased with the
results.

------
jaylynch
I find the data from the "I've used this but wouldn't again" almost as
interesting as anything else here.

Also really looking forward to seeing how Reason shifts between this year and
next... :)

~~~
myth_drannon
Last year I was excited about Elm, this year about Reason. I follow a bunch of
Reason folks on Twitter and see lots interesting projects. I also keep seeing
React core devs keep dropping hints that React will be rewritten in Reason
which makes sense since originally it was written in SML.

~~~
spicyj
We don’t have any plans to rewrite React in Reason right now, sorry! Maybe one
day.

------
lmiller1990
I wonder how much correlated the pay/framework data is? A lot of orgs I know
using Vue.js moved to it from jquery -- so I suppose a lot of people using
Vue.js might use in the same way, for just a bit of dynamic functionality.
React seems to be more popular as a full front end solution, as opposed to
just adding a few dynamic effects.

~~~
bigtunacan
“The Progressive Framework” marketing of Vue is both appealing and accurate.
As a shop that has both applications that reside primarily server side and
have jQuery spaghetti where needed as well as full front end SPA applications
Vue fits the bill for both arenas.

------
johnhenry
I like to site, but please remove the blinking effect when hovering over
links.

Edit: I know i'm probably getting down-voted for this, but even though the
effect is brief, it's really jarring -- similar to the "<blink>" tag.

------
kevinsd
IIRC the survey was open in July/August. But it took the authors 3+ months to
produce this result, which IMO has very limited commentary. It would have been
much nicer for such a time-sensitive survey to come out sooner.

~~~
FLGMwt
FWIW, Sacha posted a "sorry for the delay" post a while back:
[https://medium.com/@sachagreif/the-state-of-
js-2017-results-...](https://medium.com/@sachagreif/the-state-of-
js-2017-results-preview-acbd2885da7f)

Agreed on wanting it earlier, but the results are still super valuable.

------
velodrome
Angular should be noted as AngularJS.

[https://angularjs.org/](https://angularjs.org/)

Angular 2 should be noted as Angular.

[https://angular.io/](https://angular.io/)

~~~
icedchai
Not confusing at all. How about just calling them Angular 1.x and 2.x?

~~~
Lazare
The problem with the numbers is "Angular 2.x" is actually "Angular 2+";
they're currently up to Angular 5.x.

~~~
madeofpalk
I don't understand. React and everything else doesn't suffer from this
'problem'.

------
aroman
I can't believe nobody's mentioned that apparently yarn is more popular than
npm?

Surely that can't be — see the "Other tools" page.

~~~
yen223
npm has its own entry under Build Tools, and that has significantly more users
than yarn.

~~~
scottmf
The reason for that is Yarn wasn’t an option. Those are write-ins.

~~~
nojvek
Good one. Gave me a good laugh!

~~~
scottmf
[https://stateofjs.com/2017/other-tools/](https://stateofjs.com/2017/other-
tools/)

------
HumanDrivenDev
Why would you design a website with grey text on a grey background? How could
anyone possibly think that's a good idea?

~~~
virtualized
I'm sure it looks "beautiful" on the designer's MacBook Pro.

------
swellep
Didn't expect so many people to be using Firebase

------
_pmf_
> The JavaScript ecosystem is richer than ever

In the way a pile of half decomposed meat by-products is "richer" than a
surgical instrument.

~~~
TheSleeprAwakns
Agreed

------
bascule
Kind of disappointed to see very little information about the evolution of the
language itself, especially in regard to ECMA TC39.

~~~
bastawhiz
What sort of information were you hoping to see?

~~~
bascule
Changes made to ECMAScript in TC39 and which proposals made it to e.g. stage
3, such as BigInt

------
DiThi
What about Coffee Script? Was it forgotten even though version 2 has been
released recently with all features I missed and more?

~~~
toomanybeersies
I think Coffeescript is basically dead at this point, for better or worse.

~~~
iends
Sadly CoffeeScript 2 recently came out, so not dead...but the ecosystem has
moved on.

~~~
Yaggo
Nothing prevents you from using CoffeeScript with the "ecosystem".
CoffeeScript is just alternative syntax. Version 2 outputs ES6 code with
compatible classes, etc. It also supports JSX out of the box (with the help of
babel), there are webpack/browserify/etc plugins.

------
marpstar
Why are "Electron" and "nw.js" listed on the mobile section?

~~~
laurent123456
I was wondering as well, but that's because the menu is titled "Mobile", while
the section is actually "Mobile & Desktop Frameworks"

------
qualitytime
If you view source and check the web console you'l see a link to a quiz:

    
    
                                                      /\                                       
                                        ----+----    /  \     ----+----                        
                      +----+  +-------      |       /    \        |      +-------  +----+      
                      |the |  |             |      /------\       |      |         | of |      
                      +----+  +------+      |     /        \      |      +-----    +----+      
                                     |      |                     |      |                     
             +-----+-+-----+  -------+      |      +----+         |      +-------              
             +-----+ +-----+                     +-+----+-+                  ( )          ++   
                   | |                           | |                          '           ||   
                   | |   +--+  +-+   +-+  +--+   | |         ++---+ +-+/--+ +++  +++--++  |+--+
                   | | +++--+++ \\   // +++--+++ +-+----+   +++---+ +-----+ ++|  ||+--+++ |+--+
                   | | ||    ||  \\ //  ||    ||   +----+-+ ||        ||     ||  ||    || ||   
                   | | +++--+||   \V/   +++--+||        | | +++---+ +-++-+  +++-+||+--+++ ++--+
                   | |   +--+++    V      +--+++        | |  ++---+ +----+  +---+||+--++   +--+
                   +-+                           +-+----+-+                      ||            
           +-+-----++                              +----+                        ||            
             +-----+            /\/\    -----+                +---+    /\/\      ++            
                               / /  /        |   +----+   |   |   |   \  \ \                   
                               \/\ /    +----+   |    |   |       |    \ /\/                   
                                  /     |        |    |   |       |     \                      
                                 /      |        |    |   |       |      \                     
                                        +-----   +----+   |       |                            
    
    
    
    

Will you be wise enough to escape the JavaScript Jungle? Take the challenge to
find out!

[http://bit.ly/2yVkZNc](http://bit.ly/2yVkZNc)

------
rcarmo
I'm becoming fonder and fonder of RiotJS
([http://riotjs.com](http://riotjs.com)), although I've tried to get into Elm
(and failed, largely because I'm not fond of "compilers" when I'm iterating
quickly). I'm cool with working with a niche thing that I can sit down and
read the entire codebase for in a single morning, though, and that doesn't
seem to be a survival trait in front-end development :)

~~~
pagnol
Ha, I use Elm because it allows me to iterate quickly, especially as I don't
need to run the app to find out if there are bugs, since the compiler catches
so much.

------
karimf
Other answers on backend section: 138 mentioned .NET, 129 mentioned Rails, 90
mentioned PHP.

~~~
mandazi
I feel like some underestimate the .NET framework. Microsoft has done a great
job of really opening up and building a better eco system for developers to
work with. Years ago there was a common stereotype that .NET was old and not
cool. I believe it still has a place and is a strong server side framework.

~~~
djeikyb
dotnet development targeting linux is painfully slow. on my macbook, with a
relatively small asp core project, there is a 10-20s overhead to run any
quantity of unit tests. i believe it will get better, but right now it's a bad
choice.

~~~
patates
I have a project with 36 different entities, 100s of endpoints, and way too
many abstractions (coming close to the enterprise-Java levels) and for me, it
takes 8 seconds for a cold start on a 7 year old mac mini with an ssd (around
the same when running tests). I find it not perfect but acceptable.

------
have_faith
Why does China skew towards the "alt" libraries? Koa, Vue, etc.

~~~
nie
because the "main" libs by Google, Facebook et.al. are blocked.

------
syphilis2
The menu is broken for me using Firefox mobile. I can't scroll down, it just
keeps snapping back to the beginning of the list. (That's my state of
JavaScript :)

I really like all this information and the way it's presented.

------
robinwassen
Some generalisations from this data:

\- Developers likes newer tools more than older tools

\- Developers who work with newer tools are paid less than developers working
with older tools

These points are not really surprising.

~~~
rattray
That's true in some places but not true in others. While Vue underperforms
React, Reason outperformed all other langs (for example).

------
Keyframe
I used to do web 'things', but have been out of the loop for quite some time
now. I'm intrigued by the idea of doing everything with one language /
ecosystem.

So, I'm asking you - as an ye olde php (and laravel) guy, where would one even
start? I guess node.js and expressjs is where I look first and then branch
out? Also, what's with the build systems? Isn't it js?

~~~
tpfour
I recently had to build a small web app. I mostly code for fun, and I've been
writing Python for years. I was able to learn how to use VueJS with single
file components in about a week, with Flask as a backend, plus Bulma as a CSS
framework. Nothing fancy but it works flawlessly. Also, the Vue team offers a
Webpack template so I didn't have to spend a minute learning about that.

Overall very pleasant experience.

Edit: woops, forgot to say what I actually wanted to say! You don't _need_ to
write everything in one language. I actually abhorred that idea, and glad I
found a stack that 1. doesn't need much maintenance 2. doesn't force me to
spend countless hours learning about why XYZ is better than ABC and how QRT
were wrong about this and that and learning 100 different new concepts and
terms. I put together the stack myself, and it worked without me having to
bend my programming knowledge to the particular task. There's value in this.

~~~
ldd
I just want to say that react/vue(javascript) on the frontend and
flask(python) on the backend is a combo made in heaven:

So I don't think you are the only one :D

------
md224
It looks like they're purposefully grouping together front-end and back-end
state management. Why do that when they often (if not always) serve different
purposes?

------
flatline
No Google Closure? I realize it’s not particularly hip but there is a very
large set of decent tools there.

~~~
growtofill
It’s there, see ClosureScript:
[https://stateofjs.com/2017/flavors/results](https://stateofjs.com/2017/flavors/results)

~~~
flatline
That’s Clo _j_ ureScript, not Closure. Yeah, they were both poor name choices.

------
jblg
No minifier category?

~~~
FLGMwt
Curious: I assumed it had converged around UglifyJS. Do you use something
different?

~~~
wildpeaks
Regular Uglify vs Uglify-es, Babili, Closure Compiler, and I'm probably
forgetting others.

------
flukus
The state is way overused, as this simple article that doesn't work without
javascript can attest.

~~~
sgdesign
I know this is just trolling, but it thought it was ironic to get this clichéd
criticism about complex dynamic data visualizations, which for once are
precisely the kind of thing that JS is required for…

~~~
flukus
As far as I can see there is only one dynamic visualization and the rest could
have been handled with static images, but they don't work with javascript
turned off. Even the dynamic one could be a static image and progressively
enhanced with javascript. So I stand by the overused comment.

------
shabbyrobe
I can't read the text on this site. Does anyone know a way to permanently
disable "font-weight: <=300" for all websites in firefox without resorting to
anything as heavy as Stylish, or will I need to write my own extension?
There's a minimum font size preference, but not a minimum weight.

~~~
sgdesign
Creator here. What browser/OS are you using? You can always add a `font-
weight: 500 !important` to the <body> tag.

~~~
shabbyrobe
Ubuntu 16.04 + Firefox 57, Ubuntu 16.04 + Chromium 62.0.3202.89, macOS Sierra
+ Firefox 57. Inaccessible to me on all - the font is too thin for me to read.
I can't scale the font size up high enough either as the layout breaks. I used
the `font-weight` hack initially, but after I clicked a couple of internal
links that reset the override, I gave up.

~~~
CoryG89
Something like this should work with the font-weight override.

[https://superuser.com/questions/318912/how-to-override-
the-c...](https://superuser.com/questions/318912/how-to-override-the-css-of-a-
site-in-firefox-with-usercontent-css)

------
pteredactyl
I will not use a library to ‘virtue signal’ JS abilities.

~~~
drblast
You shouldn't virtue signal anymore anyway. Have you heard about nosignal.js?
It does everything virtue signaling did but is way easier.

------
pteredactyl
I use the absolute least amount of packages and libraries necessary.

------
NanoWar
I was just wondering why this site doesn't use Comic Sans aswell...

------
sAbakumoff
Pretty soon angular 4+ will take over and become the only framework you want
to use.

------
ransom1538
Please lord, let JS die a horrible, horrible death.

~~~
stuffedBelly
Read Javascript the Good Parts by Crockford and you will feel slightly better
about the language.

~~~
acheron
“JavaScript: The Good Parts” always makes me think of the joke from _Airplane_
about “light reading”.

------
bolololo1
The 'connections' page contains an error - Angular should be
AngularJS([https://angularjs.org/](https://angularjs.org/)), And Angular 2
should be just Angular ([https://angular.io/](https://angular.io/)).

~~~
lucideer
I'm guessing this correction would make it more confusing for more people than
it would help.

Perhaps "AngularJS" and "Angular 2" would make an appropriate compromise
between being correct and being clear to people not as familiar with the
Angulars' release histories.

~~~
bolololo1
Perhaps we should name the technologies correctly instead of adding even more
confusion by mixing names.

~~~
LaGrange
Meh. I say call Angular 3 "Angular Legacy" to make it clear it has a long
heritage now.

