
State of JavaScript 2019 - jashmenn
https://2019.stateofjs.com/
======
mouzogu
Wow, 39.9% of respondents mark themselves as "Expert" at CSS. I've been doing
front-end in various guises for 12 years and I would only rank myself maybe 5
or 6 out of 10.

As I've gotten more experienced in my career I've become more aware of what I
don't know as opposed to what I do know.

It's funny that "Advanced" is mastering animations and transitions whereas
"Expert" is being able to develop a full-front end consistently. I know many
people that can build a front end, myself included but are nowhere near
mastering anything, especially animations and css transitions.

I write this in jest of course. As we all know, self-assessment is about as
reliable as...

~~~
BiteCode_dev
Half of my income is from training people in JS and Python. I have 50% of
those missions that are requested to be "advanced" courses.

The vast majority of the participants are not up to the task. They are paid
professionnals, but they consistently overestimate they level, skills and
needs. They often are not very good, and of course, they don't know what they
don't know.

So I always check for that first, and rewrite my course on the fly to include
the untold pre-requisites I identify. I don't tell them I do this to avoid
making them feel bad. Nobody wants to hear "dude, you wanna learn react and
you never used an arrow function, wtf ?" even if being comfy with JS is a
listed requirement on the site.

Bottom line: most devs are not experts, and don't have the ability to assess
that. But more importantly, it's enough for them to be productive and most
industries don't need more.

~~~
OceanSunfish
> you wanna learn react and you never used an arrow function, wtf

At least in the early days, using React was the first time most people would
be exposed to webpack/babel, so it was also their first exposure to the newer
JS features.

~~~
BiteCode_dev
But you didn't need arrow functions at the time because createClass autobind
this and you used methods. Now with extends and hooks, it would be a pain.

Besides, it's alright to learn es6 and 7 with react if you have time, but if
your company pays a $10k react training in a 3 days session, you better have
the pre-requisites right.

And at the very least, don't pretend to be "an expert" in 2019 if you don't
know es6. Every tutorials for beginers include them now. Every docs of every
libs use them.

You don't have to be an expert. It's legitimate. I don't advertise myself as a
JS expert despite being pretty good at it.

But it looks better on the resume, and once you are hired on that assumption,
you can't go back. Next time the company asks, you say expert again.

------
lgessler
So sad to see Meteor solidly in the avoid quadrant, but it seems deserved.
Meteor is what I learned how to do web development with back in 2015, and it
was _fun_. It didn't take much to make stuff happen, and the baked-in live
sync was like magic. I'm still eager to whip Meteor out for proof of concept
prototyping because of how convenient it is to have a schemaless database and
a framework that abstracts away HTTP, but for one thing I feel Meteor's big
bet on Mongo hasn't paid off.

Also surprised to see ClojureScript's satisfaction rate at 60%. In the past
year or two it's become much easier to use NPM packages, which was IMO the
last remaining huge missing piece. It's now a great language for web
development, providing what JS couldn't: a rich standard library with, _ahem_
, _consistent_ API's, a strong FP flair with excellent immutable data
structures built in, and maybe most critically of all, a somewhat constrained
macro system that allows users to write and distribute third-party libraries
for syntax that in other languages would have required an extension of the
language standard.

All of that is (I think) desirable by anyone unless you're hardcore anti-FP
(with the one exception, I guess, that macros can be and are abused, though I
haven't seen it very often in the CLJS ecosystem). So why hasn't ClojureScript
seen more adoption? It's the age-old curse of Lisp, I guess: those dang old
parentheses which decades of CS curricula taught in ALGOL descendents have
rendered foreign and horrifying.

~~~
didibus
Where did you see a ClojureScript satisfaction rating? All I'm seeing is the
have you used it before/heard of it question.

~~~
fctorial
[https://2019.stateofjs.com/overview/](https://2019.stateofjs.com/overview/)

On the 60% line

~~~
didibus
I see it now, thanks!

------
idoubtit
The data visualization is often awful and misleading. For instance, consider
[https://2019.stateofjs.com/javascript-
flavors/](https://2019.stateofjs.com/javascript-flavors/)

1\. The first graph shows "Rankings". I strongly doubt rankings are more
importants than values. When Clojurescript goes from 67% to 72%, this increase
is shown as a ranking decrease because Reason was introduced at a higher
ranking.

2\. The meaning of the data is unclear, since the exact questions and proposed
answers are not shown.

3\. Some measures have varying populations, so ranking them is absurd.
Supposing that 2% of people use A and 80% use B, what does ranking
satisfaction with A above satisfaction with B mean? Since the uncertainty is
huge on the A measure, the "real" ranking is not known.

4\. Having to click in order to switch the measure shown is strange. The three
measures should be display on three consecutive graphs.

5\. The Categories graph is unreadable for a slightly color-blind like me.

6\. The Categories segments aggregate data over 2 levels which makes them
unreadable. First levels: Used, Heard, Unheard. Second levels should be
computed relatively to their containers. Who cares if 1.8 % of users would not
use Elm again? What is important is that ~28% (1.8/(4.7+1.8)) of those who
used Elm would prefer not to do so again.

~~~
emilecantin
I think the best visualization overall is the first one on
[https://2019.stateofjs.com/overview/](https://2019.stateofjs.com/overview/).

Seeing the trajectory of each piece of tech gives a lot of insight on overall
trends. For example, I was thinking of learning a bit of the more recent
Angular (last time I used it was Angular 1.x, before React was a thing), but
now I think I'll look more into Vue.js, as its trajectory looks much better.

------
thebradbain
Wow, just learned of Svelte from this. After reading their explanatory blog
post and coming upon this blurb:

    
    
      That all changed with the advent of hooks [React and Vue], 
      which handle state in a very different fashion. Many 
      frameworks started experimenting with their own 
      implementations of hooks, but we quickly concluded it 
      wasn't a direction we wanted to go in 
      ...
      We can just use the language. Updating some count value — and 
      all the things that depend on it — should be as simple as 
      this:
    
        count += 1;
    

That's _super_ exciting to me, as it puts the emphasis back on solving the
task at hand and instead of framework nuances around state management. Will
definitely be keeping my eyes on it.

[https://svelte.dev/blog/svelte-3-rethinking-
reactivity](https://svelte.dev/blog/svelte-3-rethinking-reactivity)

~~~
erokar
Svelte seems promising. I think it's a natural evolution from what I think is
an over focus on FP and purity in React, to a more natural and intuitive DX
without significant drawbacks.

Svelte does have an irritating wart IMO, citing their tutorial:

    
    
         Because Svelte's reactivity is triggered by assignments, using array 
         methods like push and splice won't automatically cause updates. 
    

So for reference types that are mutated in place you need to do something
like:

    
    
         numbers.push(numbers.length + 1);
         numbers = numbers;
    

Or:

    
    
         numbers = [...numbers, numbers.length + 1];
    

This looks like a leaky abstraction to me since it forces the developer to
work according to the implementation details. Don't know how easy it would be
to fix this.

~~~
mb7733
To be fair, React has the same "wart". React is not guaranteed to work
properly if you do:

    
    
      numbers = this.state.numbers;
      numbers.push(numbers.length + 1);
      this.setState({ numbers: numbers });
    

React docs here: [https://reactjs.org/tutorial/tutorial.html#why-
immutability-...](https://reactjs.org/tutorial/tutorial.html#why-immutability-
is-important)

Similar docs for redux: [https://redux.js.org/recipes/structuring-
reducers/immutable-...](https://redux.js.org/recipes/structuring-
reducers/immutable-update-patterns)

There's no good way around it without doing deep equality checks everywhere
which is not reasonable.

~~~
erokar
Since Svelte is a compiler I was thinking they could wrap the exported
variables in an observable of some sort and make any method call on the
reference variable trigger a value update behind the scenes. I have now idea
how costly/complex that would be though.

Also, maybe it's a conscious choice and they want to make any data update
explicit with reassignment.

------
samspenc
I'm surprised to see Angular drop in ratings and rank so poorly compared to
React. I personally prefer Angular myself because it's (a) opiniated and (b)
has everything included (HTTP REST calls, Material UI, etc). Just curious why
so many people prefer React and mark it so positively.

~~~
734129837261
Angular ng-is ng-very ng-opinionated and requires a ton of boilerplate
knowledge. It requires typescript knowledge, and I've noticed that (finally!)
a lot of developers are realising that typescript actually doesn't make life
easier at all.

React, on the other hand, is a very intuitive library instead of an all-
encompassing framework. You can easily setup a React application in a few
seconds and get started, adding whatever you want as you go.

The JSX syntax is infinitely more intuitive compared to the Angular way of
doing things. Which also gets me to the point of Angular having a specific way
of doing things, "the Angular way".

With React there's less thinking required to get things done. The learning
curve is steep (as in: you pick up the knowledge quicker) because the amount
of information to take in is relatively low.

Angular takes months to master. It's very opinionated. And it requires
typescript.

I for one hate typescript with the passion of a thousand suns. I know it very
well because I have to if I want to keep my job, but it's so freaking
unnecessary...

~~~
hacker_9
Typescript doesn't make things easier, and react is intuitive? You know April
fool's is still a few months away right?

~~~
734129837261
TypeScript slows down a project. Nobody seems to ever point out what benefits
it supposedly offers.

My claim: TypeScript offers no benefit. Ever. That's 2 years of fulltime TS
experience talking and 18 years of fulltime JavaScript experience, on top of a
whole bunch of full stack (Java and .Net with C#) experience.

I think the popularity of TS is going to decline. And I think it's only
popular because of the influx of backend developers coming into the frontend.
Additionally, because "everybody does it so it must be professional so I
should like it".

As for React, well, great argument, I guess?

~~~
hacker_9
Slows down what?

Compile times? By a small amount sure, but with the incremental compilation
we're talking maybe a few tens of seconds max. Any longer and you need to look
at improving your build dependencies for better parallelism, and upgrading
your hardware.

Development time? Types reduce mental overhead and abstraction for the
developer, speeding up development.

Run time? Variables with types that stay static execute faster in JS engines.

Types keep code maintainable, and protect against any accidentally implicit
conversions (rife in JS). Types still exist whether you define them or not, so
being explicit gives the maintainer of your code much less mental overhead
when working with your code. Knowing the contract that a function follows
allows them to skip over any assumptions and know exactly what the code is
meant to do. Break the contract, get a compile time error.

Anyone can write code, writing maintainable code is the real challenge. In my
own 20 years experience this is always what separates the wheat from the
chaff.

~~~
deckard1
> writing maintainable code is the real challenge

If you think these same developers can't do it without TS, then you really
haven't seen the sort of mess lesser developers make when they try with TS.

Unless the JavaScript developer has a strong background in C/C++/Java, they
are going to truly fuck up a code base with TypeScript. I'm not making a
static/dynamic typing argument here. I'm making an observation that thousands
of developers that haven't seen what the hell a type even _is_ are now somehow
expected to operate on the level of creating coherent abstractions throughout
the code. Good luck with that, once your team starts allowing "any" and "ts-
ignore" everywhere.

9 out of 10 JS developers I have worked with do not know how equality and
object memory references work in JavaScript. They do not understand deep vs.
shallow equality. They are barely aware of type coercion. When faced with a
TypeScript error, their primary concern is shutting up the compiler. By any
means necessary.

Getting typing correct is more nuanced than the pro-TypeScript group will ever
admit, and TypeScript provides so many ways to dodge actual typing
responsibility that it renders the whole exercise a colossal waste of time.

tl;dr: Good developers don't need TypeScript and bad developers pull good
developers down with TypeScript.

~~~
hacker_9
I think I'm going to have make this my last comment as this is going in
circles. I mean what is even your argument? Types exist whether you like it or
not, implicitly or explicitly. You cannot get around this, it is simply a
fact. When you have input parameters, or a return type, they follow a
structure. That structure is a type. This is not nuance, this is just how
things work.

'Good' developers is a subjective term, what is a good developer to you?
Someone who can work without types? Wtf?

Anyway, I'll keep being productive with typed languages. You do you I guess.

------
stupidcar
State of JS is always a fun and interesting survey, but I am wary about
drawing conclusions from its results because of the self-selecting nature of
the participants means they are probably not a representative sample of JS
developers in general. They're inevitably going to trend towards English-
speaking developers who read coding news sites, participate in social media.

~~~
fourthark
Every year I glance at it, thinking maybe I will learn something about the
state of JavaScript. Then I remember that it's a popularity contest and I get
bored pretty quick.

I'm not sure why I should care what everyone else wants to learn. I guess it's
worth finding out if there is a new popular framework this year. Sigh.

------
WA
Interesting. React is the thing. But some trends are weird:

People ditch Cordova heavily, but also React Native and native apps. Electron
rises to the top, although you can't build mobile apps with it that are
distributed through the various stores.

So, what's filling the void for app development, if everything just went down?

~~~
marton78
Maybe Ionic with Capacitor?

~~~
WA
Nah, Ionic goes down as well for whatever reason. I'm still all in on Stencil
+ Ionic/Core + Capacitor.

Maybe people use NativeScript, I don't know. Just found it interesting that
the trend seems to go down for ALL mobile development tools.

------
napsterbr
I dream of an alternate timeline in which today we would release "State of
ClojureScript 2019" with Javascript being listed as a ClojureScript flavor :)

~~~
tonyedgecombe
I expect we will still be talking about JavaScript in another twenty years.

------
Thorentis
Sad to see Ionic in the avoid category. Their latest release I thought was
quite polished, and I've enjoyed using Capacitor rather than Cordova. I think
the key to further success is breaking away from Cordova entirely, and
expanding the native features supported in Capacitor. Right now I find myself
having to use both due to some things not being implemented in Capacitor yet.

~~~
warent
At this point with React Native (or even Flutter if we're considering things
apart from JS) there really isn't a compelling reason to build anything in a
Webview as far as I know. Also in my personal experience their support team
members have been pretty impatient and passive aggressive in the Github issues
tickets so I'm not entirely surprised that they're building something that the
community has moved away from.

~~~
yesimahuman
There are a ton of compelling reasons to build apps targeting mobile web
views, and despite Ionic's poor showing on this survey, we are seeing a lot of
serious apps and brands doing so and picking it explicitly because of those
benefits.

Perhaps the biggest is the overlap with web dev tech, team skill makeup, and
the hiring market for web devs being incredibly vibrant. Vast majority of
teams have struggled to go native and build/hire those teams, and are instead
excited about using the web devs they already have or taking advantage of that
hiring market.

One trend that is really interesting is that many teams have decided they need
to be prepared for a PWA future and can't afford to have two separate efforts
to accomplish that (i.e. app store apps and PWA). They see Ionic as a way to
do both and be ready for the expansion of PWA adoption which is early but
happening fairly organically, and has some key enterprise benefits that make
it attractive for those teams.

Sorry you had a bad experience on our github issues. We're a small team
relative to the size of the community and have had to resort to automation and
tooling to figure out signal from noise. It's been a constant process of
iteration on that front.

------
deathtrader666
EmberJS should not be in the "avoid' section.. it is one of the most well
thought-out framework which just gets the job done.. and it is a bit contra-
indicatory that Ember guys are the highest paid.

~~~
734129837261
Just the fact it uses Handlebars templates disqualifies it as a viable option
for me. Handlebars is terrible to work with, especially once you're used to
JSX type of options.

HBS = restrictive for nonsense reasons. The separations of Model, View, and
Control really don't make sense anymore. It's outdated.

I've worked with it for years and I consider myself familiar with it up until
3 years ago, but I would never go back to EmberJS. And that's why the salaries
are higher for Ember developers: they're rare.

~~~
codegladiator
> The separations of Model, View, and Control really don't make sense anymore.
> It's outdated.

What ? why ? care to elaborate please ? and what do you use instead ? MVVM ?

~~~
someexgamedev
Ember uses MVVM

~~~
codegladiator
Fair enough, but I still think its a stretch to call MVC "outdated". And
"outdated" kind of has a hint of "bad" and "should not be used", hence the
question.

~~~
someexgamedev
Oh yeah I also don't agree with OP. Separation of concerns is good. JSX isn't
perfect either.

This yearly js poll always brings out the fanboys. The amount of "heard of it
but would never try it" responses demonstrates that it's just a popularity
contest

------
cstuder
The most interesting data in my opinion are the conflicting opinions on the
overall state of the ecosystem::
[https://2019.stateofjs.com/opinions/](https://2019.stateofjs.com/opinions/)

While there is a sharp downtick of people who think that JavaScript is moving
in the right directin, most agree that the overall situation in terms of
complexity and velocity is getting better.

I don't have any explanation for this, but would agree: Developing in
JavaScript feels easier to me than just a few years ago.

~~~
rhacker
Generally have to agree there, but I do feel like there is a reason. ES6
modules (or typescript modules) and the simple fact that the variability is
finally dropping:

It seems like there was one specific winner of all of the UI frameworks.
React.

There is now pretty much one specific winner to package managers. Yarn.

There is one specific winner for language front-end: Typescript.

There are basically two front-end build tools left: Webpack and CRA (of which
is basically a Webpack wrapper with babel and a million other things)

All of the latest npm packages are either coming with ES6 modules or, more
interestingly either are completely written in Typescript or at least have
@types now. And all that stuff helps people writing JS too.

~~~
yitianjian
Disagree on yarn - npm is still trying to keep up and the latest releases are
doing well

Seems like within React, Redux/Apollo/plain is splitting the data layer again
too

But the yarn/npm is a tiny difference and data layer is much more application
specific

~~~
rhacker
Redux is quickly being relegated to pile of don't use. I suspect 2020's survey
result will show hooks to have completely destroyed redux.

~~~
acemarke
Absolutely not the case. My own estimates are that around 50% of all React
apps still use Redux, and the overall download numbers are continuing to
increase consistently. I covered this in my Reactathon 2019 talk on "The State
of Redux" [0], and my post "Redux - Not Dead Yet!" [1].

In addition, our new Redux Toolkit package [2] and React-Redux hooks API [3]
are making it easier than ever to use Redux, and we've gotten a ton of very
positive feedback from users who have adopted those APIs.

[0] [https://blog.isquaredsoftware.com/2019/03/presentation-
state...](https://blog.isquaredsoftware.com/2019/03/presentation-state-of-
redux/)

[1] [https://blog.isquaredsoftware.com/2018/03/redux-not-dead-
yet...](https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

[2] [https://redux-toolkit.js.org](https://redux-toolkit.js.org)

[3] [https://react-redux.js.org/api/hooks](https://react-
redux.js.org/api/hooks)

------
shabbyrobe
I find it kinda strange that Flow has been relegated to the write-in "Other
Flavours" section so soon. I know that it has been trending downwards for a
while (as TypeScript trends upwards), but it feels like that story's not quite
over just yet even if the conclusion is foregone.

~~~
hellofunk
I think the name Facebook being attached to just about anything is a
disadvantage, if there are other alternatives.

~~~
HenriNext
3 out of 4 most liked technologies are actually from Facebook, so the name
certainly doesn't seem to prevent success here..

~~~
hellofunk
I said if there are no alternatives. There was no alternative to React for a
long time, and it gained much popularity and momentum.

But there are many alternatives to Flow.

~~~
HenriNext
> There was no alternative to React for a long time

Angular is 4 years older than React, and generally speaking front-end
frameworks have been probably the single most competed/overcrowded area...

~~~
hellofunk
There was absolutely nothing like react at the time it came out, angular had
none of its key features.

Today we have Vue and others are forming in other languages, but still today
angular takes a very different approach to the front end. But react’s
breakthrough in the virtual dom management was totally new and really changed
a lot of things in our industry.

------
HenriNext
Redux has the largest shift towards "negative opinion" out of all
technologies. Did people just get fed up with the boilerplate or is there
something else going on?

~~~
woah
I started to realize that it just doesn't make a lot of sense. It doesn't
actually have a real concept of how to deal with asynchronous things (like,
http requests). You have to use weird things like redux-thunk, or god forbid
redux-saga.

The event system is basically synchronous, and just changes data which will be
displayed in the UI. Why use the event abstraction and all the boilerplate
that entails for synchronous code which doesn't really benefit from events? It
feels like a cargo cult.

What it boils down to is any function which will at some point change the UI
needs to be written weird, so that it takes the "dispatch" function and calls
"dispatch(nextFunctionEvent)" instead of "nextFunction()".

Lots of developers always implemented their own half-ass systems to eliminate
some boilerplate by automatically defining events from handlers and state or
vice versa or some other combination of the above.

React hooks have basically eliminated it's niche, and none to soon!

~~~
734129837261
Oh, please. The projects I've recently worked on used only Hooks instead of
Redux. It was a nightmare to deal with. Files with endless amounts of
`useSomething`, you'd need to dive through 4 levels of files to get to
something useful.

Redux offers a ton of tooling and developer comfort if you get it right. And
getting it right means having proper pull request reviews.

There's a lot of developer tooling (debugging tools), too, and a lot of
middleware available to plug and play and GO.

If you're just using Hooks and the Reducer and Context APIs you're setting
yourself up for a lot of headaches down the road.

Redux already makes use of those technologies, but wraps it in something easy
to consume with a LARGE community for support.

Not using Redux is setting yourself up for failure, in my opinion. I've seen
it happen too many times in the past year...

------
leeman2016
Glad to see lots of satisfied developers of Svelte as I am one. TBH though
didn't expect to see it up there this quick.

------
geewee
All the content aside, I just want to say that the presentation in State of
JavaScript is magnificent. Some of these charts are superbly designed.

~~~
ing-norante
Do you know what charting library has been used? These charts are indeed
magnificent!

~~~
jashmenn
D3. Incidentally, the creator of the overview chart [1] is also the author of
an excellent book on D3 [2].

[1]
[https://2019.stateofjs.com/overview/](https://2019.stateofjs.com/overview/)

[2] [https://www.newline.co/fullstack-d3](https://www.newline.co/fullstack-d3)

------
toastal
It looks like more people need to learn about PureScript. I was happy to see
it included this year though.

~~~
734129837261
I really don't see the point of strong typed programming. JavaScript is fine
without it. I've been working with TypeScript for a while now and I never
think "this solves a problem I had!"

On the contrary, I constantly think "why..."

I feel strong typing JS is just a result of backend developers not questioning
their upbringings and failing to use proper naming conventions, progressive
enhancement in the form of JSDOC comments, proper unit tests, and proper peer
reviewing processes.

Honestly, I don't get it. In all my 20 years as a professional web developer
(full stack and specialising in the frontend for the past 12 years) I have
never needed it...

I really don't understand the charm of it.

~~~
jevgeni
Aren't you describing exactly the problems types help with? Must be a reason
why typed backend developers allegedly don't pay so much mind to:

\- "proper" naming conventions

\- JSDOC comments

\- unit tests

\- peer review

~~~
734129837261
So, I've worked with JavaScript since 2001. Up until two years ago I never
used a strong typed flavour on top of JS.

And I have never needed it. Not in big teams and not in small teams.

At work we recently did a timed programming problem solving competition. 20
Teams got 1 hour each to solve multiple levels of the same problems. Some
teams used TypeScript.

None of the TypeScript teams got past level 5. All of the rest got past level
15.

I've been taking job applications where applicants get a limited amount of
time to make their project. Let's say 20 hours, and it's a paid job. Everyone
gets the same instructions.

Those who use TS are NEVER feature complete.

Coincidentally, those who use TS are also the ones who deliver one big DIV-
soup and barely seem to understand CSS to begin with.

Strong typed JavaScript doesn't solve anything, in my opinion. And nobody has
been able to convince me otherwise. TypeScript seems to be a reason for many
developers to completely avoid documenting their code...

I mean, TSDOC or JSDOC allows you to write human-readable comments AND strong
type your code _where it matters_. But they don't.

In any case, this article was a fun one to read:

[https://medium.com/javascript-scene/the-typescript-
tax-132ff...](https://medium.com/javascript-scene/the-typescript-
tax-132ff4cb175b)

~~~
imiric
> At work we recently did a timed programming problem solving competition.

Thankfully, real world software development is not done under arbitrary time
constraints with teams competing on who can be first to complete a prototype.
High quality software is very difficult to produce, and taking the time to
adopt sane development practices that reduce cognitive load and detect bugs
early on in the process often leads to maintainable codebases far beyond their
prototype phase.

> In any case, this article was a fun one to read:

> [https://medium.com/javascript-scene/the-typescript-
> tax-132ff...](https://medium.com/javascript-scene/the-typescript-
> tax-132ff4cb175b)

It might be fun, but it reads like a movie review where the author gives
arbitrary scores and somehow determines TypeScript's ROI based on that(?). The
rest of the article mostly appeals to authority, as the author pushes his
books, expertise and vast experience as proof, something you seem to be doing
as well.

I feel like the mentioned "To Type or Not to Type" paper[1] is a more
realistic study of the benefits of static typing, despite TS detecting "only"
15% of possible bugs. That's still 15% of bugs detected _during development_
that the programmer doesn't have to think about, and doesn't have to write
thousands of very trivial tests to _maybe_ catch them locally or worse yet, in
CI. This in practice never actually happens, let alone in code reviews!

Yes, static typing is not a panacea. But it's a tool that has high chances of
producing higher quality software, something that is sorely needed in JS land.

[1]:
[http://earlbarr.com/publications/typestudy.pdf](http://earlbarr.com/publications/typestudy.pdf)

~~~
exdsq
Also, if you are using a statically typed language there are tools for
property based testing like QuickCheck which eliminates the need to write
those thousands of very trivial tests. I've seen one advertised for JavaScript
but you can't guarantee it'll find everything thanks to typecasting.

------
jermaustin1
How do 3.6% of respondents have more than 20 years of experience in
TypeScript? And 21.7% have more than 10 years?

EDIT - They don't. They have 10+ years using JavaScript

TypeScript was released in 2012, sure there are early adopters and beta users,
but I seriously doubt that nearly 22% of the people using TypeScript prior to
it being released.

~~~
mando75
I believe the question you are referring to is asking what general level of
experience TypeScript developers have. I too was a bit taken aback when I saw
that. I had to reread the question. They should have done a better job making
that clear in the chart for people just skimming the data.
[https://2019.stateofjs.com/javascript-
flavors/#javascript_fl...](https://2019.stateofjs.com/javascript-
flavors/#javascript_flavors_experience_heatmap)

~~~
jermaustin1
I completely missed that last sentence I guess.

~~~
sgdesign
Don't worry I added it later on to clarify.

------
tcbasche
Interesting that GraphQL is slowly gaining interest - I kind of thought the
hype would fizzle out.

Good to also see Typescript making a foothold - it's a great alternative to
pure JS.

~~~
cheapsteak
I've rarely seen a technology so eagerly embraced by both bleeding edge tech
enthusiasts and also enterprise behemoths (granted, tech behemoths, but still)

Having API documentation that is guaranteed not to go out of date with your
code. Having a shared standard for describing your endpoints in a machine-
consumable way. Being able to automatically generate typescript types from any
schema (correct me if I'm wrong but I don't think there's any tooling that
would do the same for arbitrary REST APIs). Being able to get autocompletion
when writing queries for free ^ Those were all things I didn't know I needed
until I started using them, and like Typescript, it feels painful to go back
to not having them

~~~
iCarrot
You can write Swagger definitions to serve as contracts for your REST API.
Swagger files are machine consumable and can be used to generate client SDK.

------
mijkal
Sad to see Atom take such a sharp decline. I've finally accepted the writing
on the wall and began migrating to VS Code last week.

Thanks for all the memories, Atom! <3

------
pkalinowski
Charts in this report are very misleading. In some cases 6% difference is 2
times bigger on chart than 5% difference.

I’m aware they have no scale, are simplified etc, but chart format has very
specific meaning and I believe that visualisations could be chosen in a better
way.

~~~
jccalhoun
I also noticed that on the Front End Frameworks awareness chart where react
and angular flipped places from second to first even though they are both at
100% and then I saw that the vuejs was in 3rd place although it was also at
100%

------
irrational
Some of the data visualizations seem... strange. For example, on this page:
[https://2019.stateofjs.com/front-end-
frameworks/](https://2019.stateofjs.com/front-end-frameworks/)

We see React go 93/93/91/89, but the 89 circle is higher than 91 and at the
same level as 93?

We see Vue go 87/91/91/87, but the second 91 is at a higher level than the
first and the 87 is way below the first 87.

It seems like the React line should be straight, then dip down a little bit,
then dip down a little bit more.

The vue line should go up a bit, then be straight, then dip back down to the
original position.

------
atroche
Something that jumps out to me in the demographics is how few respondents are
from Japan (0.6% vs e.g. 5.1% from Germany). Does anyone have a good
explanation?

~~~
woutr_be
I would be more interested as to why there is so little response from
different demographics in the first place, even in Europe there’s little
response, except for a few countries.

It seems to me they mostly targeted English speaking countries, which would
explain why Japan (and Asia in general) has such low response.

~~~
hellofunk
Except they excluded the country with the highest English language proficiency
on the continent of Europe, the Netherlands. I suspect there’s another reason.

~~~
sgdesign
(Survey author) The Netherlands doesn't have a large population, so it's never
going to show up as a large part of the results. For next time it would be
interesting to also let you toggle a relative view of participation vs
population though.

~~~
hellofunk
It’s a small country but with nearly half the population of Spain, and the
most densely populated country in the world outside of Taiwan. Not to mention
a massive development community (and one of the largest internet
infrastructures in the world). So, more relevant than you’d think :)

~~~
woutr_be
Taiwan and The Netherlands are not even close to being the most densely
populated countries in the world. Taiwan is 652/km² and Netherlands is
418/km². Compare that to Macau 20,286/km² or Singapore at 7,804/km².

But I agree that The Netherlands has a pretty big development community, and
generally their English is fairly close to being native.

~~~
hellofunk
That’s interesting, I’ve never done the math myself but I’ve seen it mentioned
in many places that those are the two most densely populated countries in the
world. Maybe they are only looking at the density in urban areas and excluding
agricultural areas?

~~~
hellofunk
Oh, I see now that the stats I frequently hear cited exclude small city-
states, and have a smallish threshold of somewhere in the 10 to 20,000,000
range for the country population.

~~~
woutr_be
That’s still kinda surprising, compared to Singapore or Hong Kong, I never
found Taipei or Amsterdam densely populated. But stats don’t lie.

~~~
hellofunk
Dutch homes are pretty small and packed tightly together.

------
durnygbur
What a holy mess is the landscape of the testing frameworks, even worse than
that of the front end frameworks itself.

~~~
spankalee
This is incredibly true. Testing libraries have not kept up with changes to
JavaScript and web dev in general.

I long for a test runner that does as little magic as possible, doesn't try to
be a build system and module loader, doesn't inject random libraries into the
environment, it just loads URLs and reports back test results.

Test runners and assert libraries can massively slim down too if they because
simple importable modules and don't modify the global environment or create
plug-in systems or complex test lifecycles. Tests are async functions that
resolve or reject, that's it.

~~~
gherkinnn
I’ve used TAP and nodeTAP and always ran in to some problems. Then I gave AVA
a try. Makes a pretty decent impression, though I have never used it in
production.

It’s simple enough, fast, and I have yet to run head-first in to some problem.

------
holler
Do other languages do these types of surveys? e.g. is there a "State of Python
2019"?

~~~
guessmyname
• Go 2019 —
[https://blog.golang.org/survey2019](https://blog.golang.org/survey2019)
_(survey only)_

• Go 2018 —
[https://blog.golang.org/survey2018-results](https://blog.golang.org/survey2018-results)

• Go 2017 —
[https://blog.golang.org/survey2017-results](https://blog.golang.org/survey2017-results)

• Go 2016 —
[https://blog.golang.org/survey2016-results](https://blog.golang.org/survey2016-results)

• Rust 2018 — [https://blog.rust-lang.org/2018/11/27/Rust-
survey-2018.html](https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html)

• Rust 2017 — [https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-
Resul...](https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html)

• C++ Global Insights 2019 —
[https://isocpp.org/files/papers/CppDevSurvey-2019-04-summary...](https://isocpp.org/files/papers/CppDevSurvey-2019-04-summary.pdf)

• C++ Global Insights 2018 —
[https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary...](https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary.pdf)

• StackOverflow Insights 2019 —
[https://insights.stackoverflow.com/survey/2019](https://insights.stackoverflow.com/survey/2019)

• StackOverflow Insights 2018 —
[https://insights.stackoverflow.com/survey/2018](https://insights.stackoverflow.com/survey/2018)

• StackOverflow Insights 2017 —
[https://insights.stackoverflow.com/survey/2017](https://insights.stackoverflow.com/survey/2017)

• StackOverflow Insights 2016 —
[https://insights.stackoverflow.com/survey/2016](https://insights.stackoverflow.com/survey/2016)

• StackOverflow Insights 2015 —
[https://insights.stackoverflow.com/survey/2015](https://insights.stackoverflow.com/survey/2015)

• IntelliJ, Dev Ecosystem (All) —
[https://www.jetbrains.com/lp/devecosystem-2019/](https://www.jetbrains.com/lp/devecosystem-2019/)

• IntelliJ, Dev Ecosystem (Java) —
[https://www.jetbrains.com/lp/devecosystem-2019/java/](https://www.jetbrains.com/lp/devecosystem-2019/java/)

• IntelliJ, Dev Ecosystem (C) —
[https://www.jetbrains.com/lp/devecosystem-2019/c/](https://www.jetbrains.com/lp/devecosystem-2019/c/)

• IntelliJ, Dev Ecosystem (C++) —
[https://www.jetbrains.com/lp/devecosystem-2019/cpp/](https://www.jetbrains.com/lp/devecosystem-2019/cpp/)

• IntelliJ, Dev Ecosystem (C#) —
[https://www.jetbrains.com/lp/devecosystem-2019/csharp/](https://www.jetbrains.com/lp/devecosystem-2019/csharp/)

• IntelliJ, Dev Ecosystem (Go) —
[https://www.jetbrains.com/lp/devecosystem-2019/go/](https://www.jetbrains.com/lp/devecosystem-2019/go/)

• IntelliJ, Dev Ecosystem (Javascript) —
[https://www.jetbrains.com/lp/devecosystem-2019/javascript/](https://www.jetbrains.com/lp/devecosystem-2019/javascript/)

• IntelliJ, Dev Ecosystem (Kotlin) —
[https://www.jetbrains.com/lp/devecosystem-2019/kotlin/](https://www.jetbrains.com/lp/devecosystem-2019/kotlin/)

• IntelliJ, Dev Ecosystem (PHP) —
[https://www.jetbrains.com/lp/devecosystem-2019/php/](https://www.jetbrains.com/lp/devecosystem-2019/php/)

• IntelliJ, Dev Ecosystem (Python) —
[https://www.jetbrains.com/lp/devecosystem-2019/python/](https://www.jetbrains.com/lp/devecosystem-2019/python/)

• IntelliJ, Dev Ecosystem (Ruby) —
[https://www.jetbrains.com/lp/devecosystem-2019/ruby/](https://www.jetbrains.com/lp/devecosystem-2019/ruby/)

• IntelliJ, Dev Ecosystem (Rust) —
[https://www.jetbrains.com/lp/devecosystem-2019/rust/](https://www.jetbrains.com/lp/devecosystem-2019/rust/)

• IntelliJ, Dev Ecosystem (Scala) —
[https://www.jetbrains.com/lp/devecosystem-2019/scala/](https://www.jetbrains.com/lp/devecosystem-2019/scala/)

• IntelliJ, Dev Ecosystem (Swift & Objective-C) —
[https://www.jetbrains.com/lp/devecosystem-2019/swift-
objc/](https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/)

~~~
ggregoire
> What do you use Python for? 37% programming web parsers / scrapers /
> crawlers

I had no idea that much people were scraping the web. What are the most common
applications? Users data collection, prices comparison, news aggregation...?

------
kbd
I wonder why [https://markojs.com/](https://markojs.com/) never gets any
traction. It wasn't listed in the front-end frameworks section, even in the
free-form part.

------
pastelsky
I didn't see a section on CSS-in-JS libraries (or did I miss it?). That seems
to be one of the more divided areas as far as opinion is concerned.

~~~
urban_alien
Check out the State of CSS survey.

------
machiaweliczny
Seems like these "usage by" charts are probably not properly normalised(or how
you call it?). Seems like these are showing for example how many users (earn
200k+ and use typescript) from all developers instead of percentage of TS
users from 200K+ subgroup (which is much more interesting IMO), similar with
experience and others.

------
mschuetz
The "Changes Over Time" graph is awesome. It does an excellent job of
conveying current status and change.

------
nablaoperator
They could have been more careful when designing the T-shirt: Both Elm and
Ember are depicted as 'Em'.

------
fuzzy2
The heatmaps somehow look all wrong to me...? Almost every percentage has the
40+% color.

------
keymone
i'm conflicted about this, but happy to see typescript overtaking the space.
looking forward to the day we can all forget javascript the language as a bad
dream and move on with javascript the vm.

------
yboris
To me it seems like the winners of 2019 are:

\- GraphQL

\- Jest

------
taurath
I wish “salary” wasn’t the way people were asked about pay. Everyone I know
who’s over 200k only has 1xxk salary and like 100% of that in stock
compensation. It’d give a different picture of what more people are making.

~~~
epmatsw
True. I wasn't sure how to interpret that section either. Compensation (or
Total Compensation) might be a more interesting measure

------
8bitsrule
"State of Javascript trends", yes.

Not much useful there for someone who just, you know, plods along with mere
vanilla javascript.

And when I flipped to 'inverse' (because of the blinding white) ... there went
the color scheme.

------
bbmario
Sad to see that CoffeeScript is not even listed.

------
tsukurimashou
Opinions: “JavaScript is over-used online”

Strongly agree: 7.3%

Agree: 16.9%

How?

~~~
woutr_be
I think that for a lot of people, SPA + API is just the default, even though
most of the time you can get away with a traditional MVC.

~~~
austincheney
Even then MVC is almost always far more than needed to get the job done
well... as are most frameworks.

I have noticed in the big corporate space many people writing this code are
formally educated to write code in a very specific way that isn't quite JS-
friendly and they need the extra boilerplate to make JS behave.

~~~
woutr_be
I see some of my colleagues (mostly front-end devs) don’t even know how to
write code that’s not SPA + API, it’s pretty sad. It over complicates every
project, and like you said, MVC in most cases is enough.

------
TomMarius
18.1% of respondents are working with TypeScript (released in 2013) for more
than 10 years... Eh, sure

------
LessDmesg
The state of Javascript in 2019 is that it should be deprecated. I have never
had more problems, undefined behavior, mysterious errors and malfunctions,
dependency hell and generally shitty syntax as when dealing with Javascript.
God, please, just destroy this language. The web needs something different,
something not broken and flawed.

~~~
arvinsim
Tell me about it. I have tried my darndest to use types and tests to make
things predictable. But there is always something that comes up.

It might be Javascript itself. It could also be the endless permutations of
environments(browsers, resolutions, devices, etc) that we have to cater to.

Front End Web Development is hard.

~~~
LessDmesg
It would be much easier without the moving target of new Javascript features
that browsers have to keep up with. With a real, mature, nonbroken language
there would be no need to add new features every year. Someone said that
Python is badly suited for the web because not event-oriented, whatever that
means. Well, JS didn't have async/await until recently, and there's still lots
of code that uses promises, yet even promises aren't supported by ancient
browsers. It would have been so much easier to use a language that had ironed
its sophomore mistakes somewhere on the desktop, before the web limelight.
Instead, they created an all-new "web language" to ensure decades of
volatility and reinventing the wheel for all the world wide web...

