The State of JavaScript 2018 | Hacker News Reader

The State of JavaScript 2018

2018.stateofjs.com

360 pointsWA275 comments

People are generally happy with the development of JS the trends of always improving languages along with frameworks makes developing with JS makes developer increase in happiness for the third time in a row.

ES6 is good, TypeScript is gaining ground, people are moving away from Flow.

Angular is dead? Most don't even want to touch it again ( Great ). Ember hasn't moved a bit in three years with a declining of interest. I am also surprised no one is using preact. The Choice is now either React or Vue.js, I think Vue.js 3.0 will continue to move vue forward.

Given the amount of hype with GraphQL, I am surprised only 20% are actually using it. And nearly 50% are using Redux!

Backend is dominated by Express only, and Testing framework doesn't have a clear winner either.

And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

I really wish other languages communities do a similar survey, Python, PHP, Ruby, Java, Rust etc... It will be interesting to see the trend and big picture.

Loved? Well, it's a point of view. I personally hate it, due to the tooling and the dependency management (npm and yarn are catastrophic, an "hello world" example with React downloads on average more than 100 packages).

As much as I dislike Javascript OP is right. The latest stack overflow survey[1] puts #7 on most loved languages and it's not even in top 25 most dreaded ones.

[1] - https://insights.stackoverflow.com/survey/2018#most-loved-dr...

And #2 in most wanted, right after Python.

I do wonder how much of that love is from devs who basically only know JS, and have done nothing by web stuff.

Can't speak for anyone else... but will say I'm far more productive with full-stack JS. My second most familiar language is C#, followed by Ruby, VB, Java and several other languages. Most of the productivity outside the browser is because of Node + NPM though. Also the browser gives you a much more rich rendering target than pretty much any common UI platform out there. Including some very nice abstractions.

In the end, it isn't the best choice for many things, but it's good enough for most things. As such, it's what I tend to reach for first, since getting something working takes less time, and gets in my way so much less. Windows, Mac, Linux via Node, Electron, Carlo (node + installed chrome), not to mention Cordova (iOS/Android) and React Native. Best of all, I don't have to deal with a lot of issues seen in other platform specific tools.

It's so much closer to write once, run everywhere with less friction than anything else that has been done in computing. Aside from trivial projects.

I hear a lot of complaining like this from Java devs. Oddly, they are often okay only knowing one language (Java). The exact words from a Java dev were, "well, when all you have is a hammer, everything looks like a nail".

On the plus side, once you built it, the only dependency you have is the browser, and you can distribute it however you want since it's cross-platform compatible.

>> the only dependency you have is the browse

HA! maybe this is technically true, because in the end that's where it runs, but have you looked in your modules folder at any substantial project lately?

The dependencies run deep and they run wide...

Tell me about it.

https://news.ycombinator.com/item?id=12209300

Typescript and other transpilers especially, seem to be quite resouce hungry, slow and a pain to configure — always getting in my way :(

My "secret" weapon against tooling creep is https://parceljs.org it really lives up it its tagline.

I wish that was true.

It is :)

What's 'catastrophic' about Yarn?

Not exactly Yarn or NPM. The problem is that JS is suffering from extreme dependency hell, due to overly fragmentation of modules. It's appalling. It is not a good thing starting a project, doing a install and having hundreds and hundreds of modules on node_modules, some with less then 50 lines of code. Of course things must be modular, but unwraping everything in a folder like this is far from good.

Isn't the issue here basically that JS doesn't have a "standard" authorized library, like Java or C# and NPM has basically become the standard library?

Having someone like Google steward a "standard" library (and it could even be distributed using NPM), would pretty much bring JS dependency management at par and beyond Java or C#.

hmm maybe you're onto something here..

I'm curious: why is it bad? I very, very rarely have to delve into my node_modules folder to take a look at something.

The leftpad fiasco (which I believe NPM has now mitigated), and the recent security issue where a certain popular package was uploading any passwords it found showed the current dangers with NPM.

I'm not arguing about the security of NPM, rather the idea that multiple modules is a bad thing.

The lesson from left-pad should have been to vendor all your deps rather than bet your org on third parties with no SLA commitment to you.

You should take a proper look once, you'll be amazed at all the different modules implementing the same functionality over and over again (e.g. globbing, promisifying, or the myriad of `is-*` single-function packages).

Why is that bad? It's a huge waste of effort, increases the burden on anyone who's maintaining a package using those micro-libraries, and will guarantee more unpatched security vulnerabilities and unmaintained packages in the long run.

NPM and Yarn are both working on approaches that would replace having a separate unpacked `node_modules` folder for every project: "Yarn Plug 'n Play" and "NPM Tink".

Having just inherited a legacy python project where I couldn't use a library due to conflicting dependencies on ancient, incompatible versions of a dependency's dependencies... I'd kill for the npm way of dealing with it. To each his own I guess.

That's interesting, what happened? I've always loved the simplicity of a couple of inhereted requirements files in Python depending on the environment. Pin the version as necessary and call it a day. usually my requirements files for local, dev, QA and production are 30 lines total. Js land is a complete shit show of ever changing dependencies with an ungodly amount of sub dependcies that will break every thing

Regarding GraphQL, I think the reason is at least partially that there aren't too many applications that actually benefit from the all-dynamic approach of it. It's neat and useful in certain applications, but I wouldn't use it everywhere. The tooling isn't quite there yet also in my opinion, but the friction will probably go away with time.

I agree that the dynamic querying aspect of it isn’t useful in most apps but the way graphql simplifies your API (and maybe your state management) compared to REST is by itself, I think, worth it. Tooling seems to be ramping up quickly but I agree, isn’t there yet.

Yeah, I assume the low usage of GraphQL in this survey coordinates/correlates with the low usage/knowledge about Apollo in this survey. Apollo seems the most invested in ramping up strong tools for GraphQL, so of course developers aren't likely to be using GraphQL if they haven't yet heard about/explored Apollo's efforts.

For instance, apollo-link-rest would be a strong way to bootstrap into GraphQL for shops with heavy REST investments.

That said, Apollo aren't yet doing themselves favors with nearly every part of their tooling still showing a "Caution: Active Development" warning. That keeps them right on that cusp of "Should I use this in production?" worry for enterprise, and slows adoption probably more than they intend.

It's a data access language where data sources are a far secondary concern for the tooling, and it looks like the tooling does not care about access control at all.

The standard looks great, and with some time some useful tools will probably arrive. But not right now.

> Angular is dead? Most don't even want to touch it again ( Great ).

Yet what I see around me is enterprise customers on our projects adopting Angular as the official internal Framework, as React is seem as too advanced.

Most of HackerNews isn't enterprise hackers. At least the active commentators.

Is that the assumption or for fact? I see people with very diverse background here.

I don't have stats to back it up, talk to pg for that :)

But it's not that hard to figure out based on comments, upvotes, stories on the front page, etc.

Consider it an educated guess from a relatively active HN member who's been here for 5 years :)

as someone who tried Angular and was so relieved with the simplicity of React, I have no idea how they can come to that conclusion. But then again, I'm not very well know with the field of enterprise customers

React requires too much FP concepts for the typical average enterprise developer.

It feels like doing Haskell with JavaScript.

You can write haskell style in any language. but you don’t have to.

function MyComponent(props) { return <p>Hello {props.name}</p> }

    import React from 'react';

    export default ({name}) => <p>Hello {name}</p>;

So much nicer than Angular.

> You can write haskell style in any language.

It would be great if that was true. The fact is that you can not copy Haskell in any mainstream language (Lisp gets the closest), and that hurts.

I dunno--most of what I end up doing has state, if not context. Not super Haskell-ish.

I've got the same feeling but with bad connotation.

React is easy the same way jQuery is. Easy, unstructured, foggy, too much permissive tool.

Far too easy to end-up with spaghetti-code.

I prefer not using it, Angular is far more organized.

Like another reply.

    // MyHello.jsx
    import React from 'react';

    export default ({name}) => <p>Hello {name}</p>;

Now do the same in Angular.

I cannot speak for GP but for me the complexity comes from stitching dozens of libraries to get similar "base" to build the app on. Ember/Angular have way more stuff baked in or standardized, while in React you have to handle ball of ever changing dependencies ... For seniors it's ok(-ish) tradeoff (you get much more choice / control), for juniors it is hell on earth.

But that is more of an issue for projects maintained for a long time. If you want to crank out small apps fast, your "example" is relevant, and React definitely is the better option.

What do you need that isn't in the box with React? Aside from fetch, which is in all modern browsers? The new Context component interface pretty much flushes out the last of what you are likely to need. As much so as what you get in the box with Angular. Even then, with Angular you'll usually need at least a visual component library, and with React, disparate components tend to work together with less friction comparatively.

Well if you focus on components only in your app then sure, not much needed. But complex apps need much more, like testing infrastructure, routing, data layer, service layer, tons of utility functions (last time I toyed with React it did not even have debounce ... Library for UI w/o it seems weird for me) and likely something else.

But hey, most apps are simple, so no need for all the above. I would say Ng/Ember are more specialized / niche.

"Hello world!" programs or their slightly more sophisticated variation, the to-do list app, aren't a realistic measure when it comes to actual real-world software that has to solve real-world problems.

The survey results this year is misguided as it now mixes AngularJS with Angular. Was surprised they made such remarks in the conclusion knowing this change. Most AngularJS users will not use it again for sure.

Since I mostly work in the enterprise (in Europe) I see Angular all around me as the de facto framework. It's definitely not dead. With TypeScript it's a pleasure to work with.

I think a lot is due to the unfortunate naming, people still confuse AngularJS (v1) with Angular (v2-v7). I totally believe a lot of folks will say "Used AngularJS (v1) won't use it again".

Same. I don’t think this survey is representative of the enterprise at all. In fact, it seems like responses are down this year from last year from what I can tell. 20,000 is not a huge sample size in this market.

When having a few conversations a few years ago with enterprise devs, the React license was seen as a problem[0][1], and Angular wasn't, so the default path was from the top-down to go with Angular, for those I spoke to. This was also when Angular 2.0 was new and the comment was also "This is moving too fast".

Once enterprise chooses a tool, that tends to stay the tool for that project, then all of the team is competent in the tool after a couple of years working with it. There's a critical time-frame when new competing tools win a geographical majority [2].

[0] Link to facebook announcing Reach license changes: https://code.fb.com/web/relicensing-react-jest-flow-and-immu...

[1] Link to short article on MIT-Patents license in reack. Takeaway: This has never been litigated before https://hackernoon.com/4-lessons-from-the-react-patent-licen...

[2] Geographical majority http://www.businessdictionary.com/definition/geographic-mono... replace 'place' with 'technology tool'

While 2+ is definitely better, I would still prefer to never use it again. To me, React + JSX is the most natural abstraction for component development. Vue is probably second, but tends to introduce complexities that make things harder for mid-large apps imho.

Yes, it is quite a fact that enterprise businesses tend to adopt Angular as it has more sort of an enterprise appeal due to its popularity and being backed by Google.

I had a friend (F) interview for a FE developer position. He was more of a React adopter and he spoke with the architect (A) of the team. The company was heavily invested into MS technologies (think a lot of WCF Services)

F: So, what technology stack are you moving into? A: We wanted to retain as much of our backend WCF stuff, while we move our front-end into Angular. F: So has there been a project that was started? A: Yes, we have started to move 8 of our enterprise apps to Angular. F: Any challenges so far? A: Well, the code seems to become a little too complicated for our developers to work on. We'd like to get it to a cleaner and more maintainable state. F: Have you considered other frameworks? A: Sadly, no. Company has invested more than 2 years in re-designing the app. And besides, Angular is backed by Google, hence, we seem to think that it will be the right tool for the business. We've invested a lot of time as well with it. F: But you are saying that productivity overall is low because the complexities of your Angular code base is taking a toll on your developers? A: Yes, in some sort of ways. There are Angular constructs which just does not make sense. And nipping the warnings and errors in the console is just a task that's too heavy and tedious. Although we like the fact that Angular can play nicely with our backend stuff with very minimal changes required on that side.

Practically, the architect was saying that the enterprise adopted Angular due to its immense popularity way back then and being heralded as an Enterprise framework.

Although my friend was offered a very good salary (by Canadian standards), he politely declined the offer, after inspection of some of the code base and the challenges that he would be facing.

That sounds more like a quality problem of the particular dev shop than an indictment on Angular.

I think the conclusion chart shows it clearly: Angular has very high usage (nearly as much as React) and very low satisfaction in using it.

(Which is often what you would expect of enterprise development: go with the solution "everybody else uses", whether or not everybody else enjoys using it. ;)

I suspect one of the reasons people are happy with JS (even though there's plenty of much better languages) is that it has made a huge progress. Writing ES6 after a few years with ES5 is so much more pleasant. I used to be annoyed every time I had to write some JS code in the past, now I must say I even enjoy it.

However, regarding the metric that shows developers' happiness over the years:

* If someone asks me if I'm happy writing JS these days vs a few years ago I'll say I'm much happier now than I was before.

* If someone asks me if I'm happy writing JS vs writing Elixir (or Python or some other language), I'll still say I'm much happier with Elixir.

I think we should also consider that most people have gotten used to the fact that JS is the language of the web, and there’s basically nothing we can really do about it in the short term, so let’s just have a positive attitude towards it!

P.S. I don’t, but most people I have met seem to have this kind of mentality.

Yep, the Stockholm Syndrome. I still swear a blue streak when I get pulled from my nice backend world over to do some trivial UI work on the front-end, and it takes me frigging forever because there's no type system, and no compiler, and the tooling is stone age, and it takes me longer to run gulp and babel to build it to see changes than building my entire backend solution and running all my tests.

It's all we've got, but it is assuredly not good. Hopefully WebAssembly comes to fruition and we can leave this dark era behind.

> to do some trivial UI work on the front-end

If that takes you forever, consider that it may also be your lack of familiarity as much as the lack of type system/compiler. Despite my preference for the back end, I have spent plenty of time on the front end and can pump out changes very quickly.

But client development is always hard. Comparing backend work to browser client development in an effort to attack Javascript never made sense to me.

At least you have pretty good wiggle room to use other solutions on the browser client, whether it's other languages (TypeScript, Elm), to completely new abstractions (React, Elm again, etc). For example, Elm or React are a fuck ton better than anything we have native on Android and iOS.

Look at other clients people development for like iOS. It's not easier. And any gains in ease of use are traded off because you're developing for a platform that not everyone uses.

Also, continuing with iOS, things like CoreData and the entire UI abstraction are super OOP and not very pleasant (especially the former). And it's nontrivial and a lot more warty to switch out abstractions (like using Rx) or use something other than Swift.

So that things are harder that you moved from backend to client development isn't a very scathing review of Javascript because client development isn't easy.

Look at flutter. Please.

Like everything, it has trade-offs and is not a free abstraction.

That is why I love React Native. Things like laying out screens is simple using flex and position properties. Laying out in iOS? Not as simple with those atrocities like auto layout, constraints...

That isn't surprising because the backend is simple and the frontend is not.

By that, I mean that you get to choose your entire playing field on the backend. What language are you going to use? What database? What OS will it run on? What (reliable) network connection? All can be tailored to your heart's desire.

No such luck on the frontend. Your code is going to run on a diverse set of clients, which you have no control over. The connection quality might be awful. The CPU on the device might be awful, or it might have low memory.

As much as people like to crap on JavaScript, it isn't the reason the front-end is difficult to program for. And WebAssembly isn't going to solve all of these issues either.

These technical problems you present, are difficult but solvable if a big player is willing to pitch in.

I don't like to target specific words, but the problems you specify apply to JS as much as they do to any other language.

A C/rust like language has far better CPU/memory efficiency than JS.

A batteries included language like python might even be better at network latency since it doesn't have to bundle in the code that should've been in a stdlib, not client code.

We use different languages because they are good at different things. The browser doesn't seem to respect this Philosophy :(

> TypeScript is gaining ground, people are moving away from Flow.

Is it really the case? Both projects are watched and have quite big number of stars in github.

I have tried flow and liked it. I have used typescript in the past and I'm not crazy about it. Therefore I would like to get better understanding here. Is there anything I could read about it?

I don't have hard data, but a large part of this is probably ecosystem. TypeScript updates more often and, most importantly, almost every relevant library has TypeScript type definitions available. Interesting hard data would be the percentage of popular libraries with TypeScript type definitions available vs. those with Flow definitions available. I'm quite sure that would heavily tilt towards the former, though.

Don’t have to take the survey so seriously. It’s not representative of all JS community. My circle of JS hackers don’t even bother to participate.

Is there any reason to suspect Flow users are less likely to do the survey than, say, TypeScript users?

I can speculate here a little bit. Majority of survey users has less than 10 years of experience. That makes them susceptible of being Visual Studio Code users. VSC - Microsoft product. Typescript is Microsoft product as well.

I am curious (as a VSCode user) what makes you conclude that junior devs are likely to use VSCode?

It is really good tool and free one. Better tools are either commercial or requires a lot of learning.

You're mistaking "representative" with "inclusive".

The survey can be a representative sample, without including your ̈́"circle of JS hackers". That's how surveys work.

The proportion of Flow users who said "would not use it" has increased substantially over the past year. (24% vs 41%)

I started using TypeScript professionally for the first time this year. A few more datapoints: I've had recruiters calling me for TypeScript projects, but not for Flow. This is in the Netherlands.

>Given the amount of hype with GraphQL, I am surprised only 20% are actually using it.

Glad to see people don't adopt things only because they are hyped.

You've never been or spoken at a JS meetup... the whole audience glazes over whenever you talk about something that's not hyped right now.

At the end you'll even hear questions like "So where do I add <insert hyped thing here>"

New JS dev's in the last few years have been under the idea that using whatever is hyped is cool... ignoring that it's not stable and you shouldn't probably use it in production.

The State of Rust is a yearly survey:

Unsure if the 2018 results are done?

https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul...

Still analysizing them. Soon though!

> And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

I think a primary reason for this is that Javascript first was a language that was easy to hate because mistakes couldn't be fixed - "don't break the web" and all that. The community then found a way to improve it without breaking the web: add improvements with different syntax, and let your editor/build system/whatever use a linter to deprecate the old syntax from your personal codebase. It's greatly improved in that way and now easily holds a candle to other long-term popular languages.

Just curious why no one want to touch it again? I never developed with Angular but I loved to develop with AngularJS (and still working with it). Can anybody entlighten me?

My personal experience (used Angular JS and EmberJS, before React) -- AngularJS (like Ember) required a lot of Angular _specific_ understanding to use properly, and (_unlike_ Ember) some of those had significant performance impacts. When I switched to React, i felt like there were 3 or 4 API's I needed to understand, and that the escape hatch was easily reachable at all times. There were numerous features I extended deadlines for in Ember and Angular where I would say to my teamates: "I could solve this with Javascript, but how do you handle this in Angular?". Some people are ok with that tradeoff, but both sides feel relatively strongly about that particular choice.

IMHO Angular in its recent versions is the most simple front-end framework ever. It's not even JS anymore. It's type script + reactive framework. Those 2 things makes programming extremely easy.

I keep repeating myself here...

    import React from 'React';

    export default ({name}) => <p>Hello {name}</p>;

Now duplicate in Angular and tell me it's simpler.

what's the point of this? I mean, Angular has its use cases aswell as React does. The point you are trying to achieve leads to nothing.

My point was, angular is emphatically NOT the most simple component option. I, personally, can not think of a single use case where Angular (any version) is a better option than React, Vue or Polymer.

If I were to write such an app, html + vanilla js is more than enough.

The point was in response to how "angular is the most simple..." where it is emphatically NOT so.

After having dropped Angular in the 1.3.x days, I was pleasantly surprised by how much it's changed. There are still a few mental concepts a new programmer would have to grasp (DI, observables, OO, type-safety) but overall, it's not too bad. I'm not sure I could call it "simple" though. Maybe I'm conflating simple with "easy". I'm of the few that still believe in Redux though. A one-way data flow, a finite state-machine, a new version of the state on every action.... that just defines "simple" to me. (not arguing at all)

All right, my background is 10 years of .NET programming where DI, OOP, type safety are fundamental concepts, so having these things in the front-end framework is extremely helpful.

> Angular is dead? Most don't even want to touch it again ( Great ).

I don't get the Angular hate. I work with it daily and seems like a productive environment. I did some tests with React and Vue too and couldn't find any relevant advantage. Angular has batteries included tools for a lot of tasks: i18n, routing, isomorphic builds, web components, etc.. You get a cross platform mobile development environment too using NativeScript and a somewhat Angular-esque backend development framework using Nest.js. Seems like a good deal to me.

One major reason is that Ng is its own thing. It's not JavaScript, nor HTML. Also, "batteries included" means buying into the whole monolithic framework. The React ecosystem requires more decisions, but also benefits from ability to pick and choose the right libraries for a given project. That said, Angular has some great parts, eg TypeScript and RxJS.

I think people will grow "hating" React because of the ease of use. Just like JS and PHP.

I weep for the people that will maintain all the React mess that is being created. React is great, but the current ecosystem has too much liberty for too many junior dev using it.

Angular being a framework has a lot to offer in term of maintainability and good practices.

I can assure you that nobody on earth hates Js and PHP for "ease of use"

A couple good points. I agree w/ your 2nd and 3rd sentences. That said, I'm personally glad I invested in React and its ecosystem.

I find the "build your own framework" aspect of React to be as much a curse as it is a blessing. You can skip some of the bloat, but you also have to kludge together multiple libraries of varying quality to get the same things you'd get out of the box with a "batteries included" framework.

especially for new developers and organizations. You have a choice between a wide-open landscape and a script that you're deathly afraid to eject because you can never go back. Neither is great for someone considering adoption for a new commercial product.

Yeah, I hear you about the "eject" problem for create-react-app. In CRA1, react-app-rewired emerged as a reasonable approach to no-eject config extension, but CRA2's switch to Webpack 4 (itself having moved towards zero-config) broke almost all the rewired plugins. There are solutions in the works (eg babel-plugin-macros), and alt approaches like Neutrino, but timing is tough right now as there isn't a clearly-established and well-lit path for good defaults plus low-maintenance config.

> One major reason is that Ng is its own thing

You're spot on with that in my case. I already knew JS and wanted to build on top of it. React just felt natural to pick up than Ng. Also, the fact that ng completely changed in v2 really put me off and I haven't looked at it since.

I think they could have avoided 90% of their problems by just giving it a different name.

Agree, I can't believe that the company owning the major Internet search engine gave the same name to two different frameworks.

> I really wish other languages communities do a similar survey, Python, PHP, Ruby, Java, Rust etc... It will be interesting to see the trend and big picture.

2018 state of Haskell survey results:

https://taylor.fausak.me/2018/11/18/2018-state-of-haskell-su...

Rust do a survey, https://blog.rust-lang.org/2018/08/08/survey.html

> Angular is dead? Most don't even want to touch it again

Quite the opposite is happening from what I'm seeing. More people seem to move away from React towards Angular, but that's just my anecdotal observation.

That's just absurd - I have no love for React, but I can't imagine why anybody would adopt Angular now.

why? because you don't like it? Angular 2+ is the perfect transition for most of the developers who are used to do Desktop or Backend development and want to jump to front end stuff. In the enterprise, Angular 2+ is loved over any other framework. Is the best one? who cares.

Of the several dozen people I know who've used Angular and React, I know only one that would prefer Angular. Also the only one that would use Angular over Vue with experience in both.

And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

I enjoy modern JS myself, but I'd be careful about coming to a conclusion like that based on this survey. All it tells us is that JavaScript is very well liked among people who wanted to take the time to complete the State of JavaScript survey.

People who dislike or hate it JS probably wouldn't see the value in completing the survey, so the happiness factor might be a bit biased as a result.

JS is not loved. Is hated less :)

BTW, I insist that is a missed oportunity of clean JS even more (ala typescript, whit some of the wats removed).

I don't know a language in a better position of improve by a HUGE margin than JS.

GraphQL has a LOT of boilerplate to be able to use it. In many situations the effect is barely, if at all better over direct REST/RPC API end points. That has a lot to do with only 20% using it.

I really wish more would migrate to Koa over Express, but I get it.

As to the JS Love, I think there's still plenty of hate around.

>> And my biggest surprise is how Javascript turned from one of the most hated programming language ( besides PHP ? ) into being acceptable and loved.

For real?

I personally think JavaScript is awesome.

I personally think jQuery is awesome.

And I feel really alone a lot of the time in these opinions. I see a lot of disdain for JS here in comments in particular.

I also see a lot of people browsing with JS disabled, and who complain when a site doesn't function without it.

One important data point there is Visual Studio Code.

It used to be really popular in 2017 (double the popularity of Atom/Sublime/Webstorm), now it's just eating everyone's lunch (triple the popularity of Sublime/Vim/Webstorm/Atom, almost equal to all of them combined).

Also Atom is declining sharply.

Compare https://2018.stateofjs.com/other-tools/ to https://2017.stateofjs.com/2017/other-tools/

Microsoft owns both VS Code and Atom, so probably they're not crying in their beers about that...

Anyway, props to Redmond for a major coup — from webdev pariah to owner of the most popular development platforms in just a couple of years! It took both money and sincere dedication, but they managed to effectively turn around the external perception of Microsoft in this field.

VSCode seems unstoppable. From my limited understanding, it has very powerful architecture, and it will be most popular editor for .net, Go, Python, Rust in couple of years.

Fully deserved from where I stand.

I have 3 editors I regularly use, emacs when I need to edit something in a terminal (eg ssh'ed somewhere), Intellij when I need a full blown IDE (refactoring and debugging), VSCode for everything else.

It's fast, well updated, works well ...

This makes total sense too. I was so hesitant to use something besides Sublime forever, then I tested out Atom and it was slow (this has probably since been improved) and didn't offer much more so the trade off wasn't worth it for looking pretty. Bounced around a few others and then thought I'll try out the VSCode thing, hooked right away and it seems to keep getting better.

Same experience as you. Thought I would always use sublime but my coworkers were so adamant about VSCode that I finally gave it a try. I don't even know that I can point to any single reason for it being better than Sublime -- feels like everything just works a little more seamlessly.

After Atom and Brackets, I almost didn't even give VS Code a try... I'm really glad I did... everything I want in an editor (except maybe binary/hex mode). Integrated terminal and the directory tree are hands down my favorite features, I've seen the directory tree before, but never as good an integrated terminal..

VSCode does everything so well, that it is hard to compete right now. It really was built upon the lessons learned from several others code editors.

> JavaScript is always changing. New libraries, new frameworks, new languages… It's part of the fun,

No.. NO, it isn't.

...yes it is?

NO, it isn't...

yeah nah…

Using JS through time is like observing a freshman student who discovers new stuff in old books.

Amusing, but we've got better things to do.

well it's certainly better than listening to ranting retrograde gramps

"zomg new framework, I have to LEARN again :("

This is a fairly vacuous remark, if I'm frank.

The problem isn't that you have to learn another framework (although it does become a problem when they're all slightly similar and they start to meld together after the umphteenth, not to mention that learning slows down with age). The problem is that each frameworks brings along new edge cases, new problems and forces you to reinvent tools you already had for this new framework. Although learning new shit can be exiting, at some point, you gotta stick to something for a while so you can also actually build a lasting product with it, rather than building a new prototype but never finishing anything because you're distracted by a new shiny.

No one forces you to learn anything new if you don't want to. People aren't stupid, if they invent new something (and pour shit ton of effort into it like with Vue or React) they probably have a good reason to (previous PITA first comes to mind). And anyone's "I don't want to learn" whining is in no way a reason to not invent that new something because that will actually slow down progress of tech field (which we can't have under any circumstance, this is the backbone of my argument). Get your act together or give way to those who will.

Besides, client development is a cutting edge field.

I'm sure glad we're advancing beyond the abstractions we have in, say, Cocoa development (which is evolving as well). Seems incredibly selfish to suggest that everyone is incompetent and nothing new is good because you don't want to have to learn new things.

Yet somehow HNers convince themselves that it's scathing sociotechnological criticism of an ecosystem because we tolerate it for some reason. Meanwhile everyone would roll their eyes if you suggested something like "ugh, Objective-C replaced by Swift is like watching Apple read old books."

> if they invent new something ... they probably have a good reason to

https://en.wikipedia.org/wiki/Not_invented_here

Even if there were no reason at all, the bias toward writing things ourselves ensures that we'd continue to see these new frameworks.

That's a fantastic analogy!

I suppose the analogy in medicine would be to have this "medical hacker" mentality where you just go and do things, all the while learning. First you start with leeches, then you develop your own theory or four humours, https://en.wikipedia.org/wiki/Humorism, then you figure out there was this guy called Hippocrates who had lots of great ideas about medicine which you should totally read, but hey, who has the time nowadays, so you just skim through a blogpost with the summary of the most interesting tidbits.

You keep hearing the name "Pasteur" and the "germ theory of disease" which sounds mildly intimidating. Instead, make your own plague doctor mask with a organic herbs as a safekeep. That'll keep the germs away.

People think your plague doctor mask is really cool in instagram and you become moderately famous. People start asking medical advice from you. They keep mentioning something called "vaccines", which sounds really convenient. You read an obscure reference about primitive vaccination to smallpox and decide that's a great idea. You start scratching yourself with random things you find in the street to increase your "resistance" to all ills.

You create a blog around this cool concept of "resistance" and invite other people to scratch themselves. Someone dies from infection and you say they just can't use the tool right....

etc.

I presume the protagonist will eventually reach modern medicine if he's alive still, but it would be so much more convenient for all parties if he had become familiar with established standards before starting to share his ideas with the greater public.

I'm reminded of back in 1997 (maybe 98, anyway long time ago), I had been on a JavaScript course with a British guy, and went over to his house. He showed me the little cv site he'd been working on, it had quite a nice design, much better than I would ever do if asked to design something. I looked at the code - it was all tables, so I decided to show him CSS at the end of which he thunderously proclaimed "That's what's wrong with this industry, there's always something new to learn!"

I think he's doing something with Sitecore now, make of that what you will.

I think he kind of had a good point. It would be nice to have a single set of tools that can always get the job done no matter what.

yes that would be nice, but then lots of things that do not match reality would be nice.

The second step to making things better is to believe they can and should be improved.

The first step is knowing that the current state of things is deficient in some way.

I think the should be improved is implicit in the first step, does can be improved imply a suggestion - if not the third step is a suggestion, and it's that third step I'm always seeing problems in, not to mention the third step in a scenario of too much too learn runs into the XKCD standards problem https://xkcd.com/927/

Not long ago I had to write some JS (had to, not wanted to) to do something on a site, and got something working based on what I knew, only to be derided by a "real JS developer" that my code was "deprecated", "not following best practices", "not modern", etc.

He gave me his version which was around 10x more code and only worked in a subset of the latest browsers, while mine not only did but would probably work in everything since maybe IE5 or so...

Maybe that's considered a bug, but I don't want any of this trend-chasing. I write code to get things done. My users don't care, and they want to get things done too.

Sounds like he wasn’t a very good JS dev...?

if someone ended up with 10X the code using 'modern' JS and it did not work cross-browser while yours worked cross-browser including IE6 and up, then I strongly suspect I would prefer yours.

If his ES6 required 10x more code than your ES5, then he doesn't actually know ES6.

I think he probably doesn't know JavaScript at that point. I remember I got invited to an interview one time and they were impressed by my code for their coding assignment partially because it could print out in less than a page (no minification), and they referred to another applicant whose code had taken 6 pages. And I was just like - how could it take that much code?

The funny thing is, we've just been finding more and more complicated ways to make table-based layouts ever since, but they're better because they are CSS based? I dunno, I don't have to squint hard at CSS-Grid to see old table layouts peeking back at me.

It could also have to do with no longer requiring, say, a 1x1 invisible pixel...

With HTML Tables, it's easy to switch on the grid (border=1) and see what's really going on. Maybe I'm old fashioned, but WYSIWYG sure the hell made life easier. Unless you are a dedicated UI specialist, you'll probably spend way too much time dinkering with the web UI because it's not WYSIWYG. It's like trying to park an 18-wheeler truck in a normal lot: you can't just "go there"; you have to plan it all out in 7 steps and hope it all works. Bicycle science is now rocket science. I'd like scientific proof "it must be this way" to get whatever wonderful benefit non-WYSIWYG has. Device size handling? Make 2 UI's: fat and skinny; that's easier than parking the 18-wheeler.

> With HTML Tables, it's easy to switch on the grid (border=1) and see what's really going on.

With CSS it's actually easy to display the grid `\*{border=1;}`. With tables, you have a lot of them, and must go into each line of your page adding that clause.

Nah you can target both with css (I.e. use table td selector to target all cells)

Then you border-tize all div's. That's messy. I suppose one could write jQuery to filter certain divs, but it's not a universal solution.

Conclusion in the end is almost the opposite:

> It looks like 2018 was mostly a continuation of the trends we already observed last year.

> That's bad news for us, because we can't come out with a big scoop on how React's days are numbered, or the next big thing is this new state management library created by a 17-year-old Vietnamese high-schooler in her spare time.

> But that's great news for you, because it means you can spend less time worrying about what to use, and more time actually using it!

Between the two ends of "language is never updated ever" and "language is updated to make developers extremely happy," I'm firmly in the latter.

Then stop learning the frameworks and start learning the core of the language.

I got dizzy from all the options out there so I spent some time improving my knowledge of JavaScript itself instead of focusing on someone else's library.

In the end, those frameworks are "nothing" but a lot of JavaScript patterns stuck together.

Switching from one framework to another should't cause THAT much friction.

The main problem with frameworks isn't the frameworks but the MBA's who finished reading "Lean In", congratulated themselves for finally finishing a whole chapter book, and set out to "conquer the world" under the assumption that developing software is trivial, and the fact that it's not done yet is because the programmers are lazy and stupid and aren't using the right frameworks, googled "good web frameworks" and forwarded the first link to the engineering organization with the title "FYI".

> > It's part of the fun, > No.. NO, it isn't.

Well, it would be, and it should be, except for the unreasonable expectations from the "owners" who assume that everything they don't understand must be simple to do.

The weirdest part of this survey is in many categories, the most experienced developers (and by extension, the highest paid) were using a less popular technology. Over 50% of people surveyed had heard of ClojureScript and were not interested, but the developers who used it and liked it had the highest average years of experience and highest average salary. Same goes for Ember and Polymer for frameworks, and Relay for data store. I'm really curious what the reasons for this are.

Ditto. While I really appreciate this ongoing survey, it seems like with a little more effort, a lot more could be gleaned.

Could it be that only the most experienced developers have actual production experience with the more niche tech?

A junior dev is going to learn ES6, and Vue and/or React because they want a job, but learning Polymer/Ember/Relay/ClojureScript isn't worth the time because there are fewer jobs for it. But a more senior dev has probably maintained a few projects using that tech, maybe surveyed it for use in a new project, etc.

For some insight, my experience is that oftentimes the more experienced developers are the only ones let near legacy, but valuable projects. Newer developers are often not familiar with the technologies and thus the risk of regression is higher.

I suppose there are 2 reasons for it:

1. Popular languages would have lot more developers so lesser salary (Supply-Demand)

2. Since the newer devs have started their careers when the newer languages have started to get mainstream, more senior devs are the ones who remain with the niche languages.

Co-author of the survey here, thanks for posting! Happy to answer any questions :)

(As long as the question is not something along the lines of "My favorite library Foo.js is doing pretty poorly in your survey, surely there must be an issue with your methodology?")

My favorite library Foo.js is doing pretty poorly in your survey, surely there must be an issue with your methodology? ;)

Not a question but a suggestion. I live in England and am very aware that the residents of Scotland and Wales don't like to be classed as "English". You might want to change the title to the more neutral (and correct) Britain, Great Britain, GB, United Kingdom, or UK.

Oh I didn't even see that, thanks for the feedback!

To be absolutely correct it should be United Kingdom, not Great Britain, as you also have Northern Ireland marked as England.

Here's a map to explain the difference.

https://www.ordnancesurvey.co.uk/blog/2011/08/whats-the-diff...

You're welcome. I see you've changed it now. Glad to be of help :-)

It would be UK, as it includes NI.

To the parent - Great Britain is the land mass containing England/Scotland/Wales. The UK is the whole thing.

Good point :-)

I keep hearing about this Foo.js framework being the new React but can't find a repo!

Not a Javascript developer. But that survey was beautiful!

Anyone doing a state of any language/platform should take note.

On the demographic map of respondents, you say England when you presumably mean the UK. There is a difference!

The links to learn more in the popovers on the other libraries page [1] are impossible to click since they disappear when not hovering over the name. Apologies if someone has mentioned this before. Edit: I'm using Waterfox. It works well in Chrome.

1. https://2018.stateofjs.com/front-end-frameworks/other-librar...

Are you surprised by the low percentage of solo devs and small teams (startups) in your survey?

How do you think does this bias towards "enterprise" affect more full featured solutions like Meteor, that are more geared towards small teams and indie hackers?

Not really surprised. And I think Meteor got in trouble precisely because it appealed mostly to small teams, so that doesn't seem to be a viable business model.

A bit sad that d3.js is not even mentioned here. To me it's a solid replacement for any MVC/MVVM framework.

I guess it deserves its own category, maybe data model library?

I think it's a real shame that D3 was never broadly recognized as such back when it first came out.

I knew about it then, and made some small uses of it for SVG, but thought it was just an SVG generating library that could technically be used for HTML.

I did a deep dive into D3 last year and it is amazing for generating HTML. I think in 2018 I prefer the model that React provides, but I didn't like approaches that required the sort of infrastructure React and Angular require back in ~2010.

D3's use of vanilla javascript would have made it a top choice, and maybe would have promoted more D3 development.

no built-in routing, DI, templating, components..

No it's a poor tool for what you are suggesting.

huh?

People using d3.js as a library for generic data binding UI? It's technically possible I guess, but the API, with its enter, update, delete paradigms, is very much data viz centric. Not the best option for a general front-end UI library.

As a matter of fact, I use it to build web apps and it works pretty well:

https://paradite.github.io/hn-ratio/

Source code (87 lines of JS):

https://github.com/paradite/hn-ratio/blob/master/app.js

A sudoku solver I built with d3.js a few years ago:

http://paradite.github.io/sudoku/

I think d3.js really striked a balance between raw jQuery/JS and full-featured React/Vue.

I would recommend using it for building small-medium sized web apps with heavy data-centric UI.

I guess people with javascript turned off are not the target market for this site, but I found this humorous:

http://tinypic.com/view.php?pic=2v31s94&s=9#.W_KD0idx2Rs

I can't see anything even with their js enabled. Seems like they depend on google analytics and fail if that's not loaded too.

It's easy to wind up in that spot, irritating all the same though. I try to use everything I do with clean degradation with ad-block, etc... only local and/or cdnjs scripts required (if anything).

Me too. I develop with umatrix enabled, with font loading disabled, so that I can catch these problems, etc.

Forces you to use sensible technology, like svg and not fonts for icons, and catch these types of missing optional dependency errors, and not depend too much on a specific font in your design, so that if brwser forces something else, you don't start having overflowing text everywhere.

I find it amusing that your post links to a page which itself doesn't work without javascript. :)

Fortunately there is a direct link to the image there. http://i64.tinypic.com/2v31s94.jpg

Don't start thinking you can link to that directly. They redirect you to their js-enabled page which doesn't work with adblockers/analytics blockers.

I'd say that nicely sums up the "State of JavaScript in 2018": you'll need it even to view a non-app information-oriented page. :-(

It is interesting to compare the popular front end frameworks year over year. The percentages for 'Used it, would use it again':

2017:

    React: 58%
    Vue  : 20%

2018:

    React: 65%
    Vue  : 29%

So both have been growing at a similar pace.

Not sure about Angular, as in 2017 they listed 'Angular 1' and 'Angular 2'. This year only 'Angular'. Is that the combined number for both versions?

I would have broken Angular into two categories.. 'Angular 1' and 'Angular 2+'

From what I've seen, if there's an Angular project it's still Angular 1

Only Angular 5 around here.

> So both have been growing at a similar pace.

Don't know if you can compare these numbers that easily: one increased their userbase by 12%, the other by 45%.

I think that measuring relative numbers would make sense if we assume exponential growth. But looking at 2016,2017 and 2018, it seems to be rather linear:

https://2018.stateofjs.com/front-end-frameworks/vuejs

Fair point. I genuinely wasn't sure how to best compare it (also, I'm sure that growth slows down once a majority of users is awawre of your product, further muddying the picture).

Agreed. If I was to place a bet on which framework will grow faster over the next year, I would pick Vue.

I think React has pretty much reached saturation in terms of raw percentage. I think Vue is going to continue to erode from Angular. Also, I'd be surprised if a revised Polymer didn't see some growth since the other browsers are now starting to support a lot of the vdom features.

We have a revised Polymer, two in fact.

First is Polymer 3, which is Polymer available as standard JS modules and on npm for the first time ever. Dropping the huge barriers to usage of Bower and HTML Imports should have a large impact all on their own.

The other is lit-html and LitELement. lit-html is a template system that's much better suited to being embedded in JavaScript, and allows a very similar style and expressiveness of JSX without the VDOM overhead or a compiler. We've seen a lot of excitement and uptake of lit-html independent even of our other projects. LitElement is a Web Components base class that does async rendering with lit-html.

Given what we've seen with lit-html early adopters, I think trends will look a lot different in future surveys (even as flawed as this survey is).

Understood, I just haven't kept up with Polymer, or that much with the VDOM features in the browser, just know that a lot of those featers have started landing cross browser, and assumed that Polymer was keeping up.

I do think that if not Polymer specifically, something similar will win in the end eventually... probably something between React and Polymer. Of course Polymer will be a better model working with HTTP2 features and js modules. It'll likely come down to who gets the tooling stories worked out, or if the browsers themselves catch up first.

> Note that from this year on, we will not be making a distinction between Angular and Angular.js.

At the top of: https://2018.stateofjs.com/front-end-frameworks/angular/

Good work Sacha! The data now gets more interesting, since it can be compared to previous years and trends become more clear.

What I find most interesting is "All JavaScript development is considered clumsy" – kidding.

What I find most interesting is the geographic distribution of tech. On HN, you mostly find positive comments on React + Vue, because they're super popular in the US. Other frameworks are popular in other countries. So while it probably makes sense to use React and/or Vue, if you're in a country that has a strong focus on, say, Angular, it might make more sense to improve the skills.

Ah, it's that time of the year again – always enjoy seeing where the JS ecosystem is moving.

I would like to see two categories added for next year's survey:

1. Auth – would be interested to see if Passport is still the tool of choice

2. ORM – curious how Sequelize, Knex/Bookshelf, Objection, etc. compare in usage.

I understand this survey will obviously skew towards frontend tools, but some of the categorization just feels off to me:

For example, I wouldn't consider Next.js a backend framework. Sure, it's a server-side-rendering framework, but you wouldn't typically be using it for traditional backend things like accessing a database. Perhaps consider adding a SSR sub-section on frontend frameworks.

The data layer section seems a bit confused – it's mix between client-side stores and server-side persistence which have very different use cases. I'd probably move out the databases into their own category - would be interesting to see which JS devs prefer (eg. Postgres, MySQL, Mongo).

And trying to draw conclusions from the testing category seems odd when both frontend- and backend-specific tools are bunched together.

1. working on some of that now, going to hand-roll multi auth combined with password logins. I don't want to outsource my actual users' authentication beyond oauth to FB/Twitter etc.

2. I don't. If it's SQL, I use a tagged template string library, and just project from the response of the given library. If it's mono or similar, I don't see the point so much. I understand you can use type checking, but you can still do that at the API layer.

As to the data layer, I agree... client side libraries and abstractions should be different from server-side tech... though there's some overlap (libraries that sync client-server for you).

Ouch, the ratio of "would use again" to "would not use again" on AngularJS stunning, if not surprising: https://2018.stateofjs.com/front-end-frameworks/overview/

Offering my personal opinion on the matter, since I've used all three of the most popular libraries in large-scale projects. Angular takes a lot of work to get to know with no real payoff. Comparing the architecture to the other libraries, it's not as intuitive and it's not as easy to maintain; things that are easy elsewhere are often tricky or weird in Angular. I'm sure there are great developers doing good work using Angular, but in my experience it's easier to onboard people and MVP things using other tools.

My bet is that Angular pushes for using TypeScript too much, which makes you wonder where to start. On the other hand ReactJS & Vue work with TypeScript, but are not designed to embrace it.

I've seen lots of questions about Angular on StackOverflow which should be classified as TypeScript questions, since they have nothing to do with Angular itself. I guess that's the confusing and non-attractive part of Angular.

TypeScript is awesome and I love to use it, but some of my clients ( freelancing ) don't want me to write TS code, since they are afraid that it will be harder to find a substitute and will increase complexity - both are reasonable arguments.

I've noticed this too. And I think it's a pretty big reason why people are abandoning Angular. A lot of frontend developers I work with just don't want to use Typescript (or are afraid to), I've found it incredibly hard to push for it here.

As the resident TypeScript advocate at my workplace, I sympathize.

Wasn't there some kind of huge upgrade pain between versions (v1 to v2 I think it was) for people?

I vaguely remember talking with some folks at work who were trying to upgrade at one point, and they ended up changing frameworks entirely (to react) because the effort to upgrade was considered "about the same as a rewrite".

v1 and v2 were completely separate frameworks with essentially no upgrade path.

I don't know anyone who used angular v2+ (although I'm sure many did) but have personally been on two teams who ported to react. It burned a lot of people.

That is certainly the case. Google's decision for Angular have made millions of lines of code legacy over night.

The real reason it ever got traction in my opinion was the built in dependency injection. It solved a real problem at the time, but ES6 modules make it a lot less appealing now.

But we don't know if people mean AngularJS (1) or Angular (2+) here. In my opinion, while angularJS is now getting a bit outdated and very different under the hood, for a user it's pretty similar to Vue.JS, which people do seem to love. Angular 2+ on the other hand seems to have added a layer of JavaEE-like over-engineering on top. I think a framework should be written with productivity as top concern and Angular 2+ is anything but that, it constantly works against you.

They're similar? Then I know to avoid Vue and stick to React.

I have plans to look more deeply into Vue when I have some time since so many people like it, but that's the impression I get from it, it does a heap of the stuff I didn't like about angular, why would I go back?

Angular reminds me of the Spring "framework". Once you peel back the GIGABYTES of framework redirection and figure out what it's actually doing, it's not a bad way to organize code - it's just that trying to wrap that up in a reusable library rather than just recommend it as a best practice is so braindead as to be incomprehensible.

> Finally, keep an eye out for Svelte. By using a radical new approach to front-end frameworks, it's managed to generate quite a lot of interest and was by far the most mentioned option in our "Other Tools" category. [1]

Glad to see Svelte [2] starting to get some attention. It’s a true little wunderkind.

[1] https://2018.stateofjs.com/front-end-frameworks/conclusion/ [2] https://svelte.technology

Really used to hate JS in the years before 2012/13. I struggled on moving away from desktop development to web app development.

Then in later years found React/JSX/Redux, Typescript and VSCode ... and started loving it.

Really interesting to see what the trends are!

I have to say that Typescript in particular has made me like the JS ecosystem a lot more again. Especially in combination with React – type-checked JSX quite often feels like magic. Of course, the downside remains that there is still a large number of JS libraries without type information.

The State of JavaScript 2018 is inaccessible in IE.

That seems about right.

It's hilarious. Doesn't work in IE, in Edge the button to start doesn't show and if you go directly to https://2018.stateofjs.com/introduction/ the navigation and styling is broken.

And in 10 the floating squares don't even show up. And it doesn't have fall-back for browsers with no SVG support - really nitpicky but it is an actual problem.

Works just fine in Edge. And TBH that's good enough for me, I don't think supporting IE is necessary for a tech-enthusiast targeted site.

As a survey completer, they still don't include ES8 as an option: https://2018.stateofjs.com/javascript-flavors/overview/

'await' is a game changer for JavaScript: major libraries like Stripe and Hapi are rebuilding their docs too be ES8 based.

I believe the survey uses ES6 (which officially is named ES2015) to refer to the "current version" of ECMAScript (which I suppose is ES2017).

I don't know if the solution is to include each yearly release of ECMAScript since ES6, or to simply add an "ES.Current" option, which would just be the latest proper release.

Next time I think we'll just drop the ES* item altogether and instead ask developers which JS language features they use directly.

Well yes, that's my point. There's a massive difference between using class and template strings with callbacks or 'then' vs actually using Direct Style with 'await'

Is "Angular's Popularity Over Time"'s bad stats based on combining Angularjs and Angular2 into one?

In previous surveys we had both Angularjs and Angular, but starting this year we stopped making the distinction. So yes, the "bad" stats include both versions. It's not perfect but we thought it was best to just bite the bullet and combine both going forward.

I'd love to see what the stats were for Angular 2+ only - I imagine they'd look a lot different. If they'd chosen a more appropriate name for Angular then I feel like this wouldn't even be an issue.

I think that mixing up AngularJS and Angular (>= 2.x.x) is misleading. They are two different frameworks, so little knowledge can be inferred by combining the data about the two. As an Angular Dev the most frustrating thing when v. 2 came out was precisely the fact that I had to re-study from scratch all the documentation. As a matter of fact I've used AngularJS since v. 1.1.x (2013) and I then switched to Angular (latest release) as soon as v. 2 came out, and I would definitely answer I'd use it again, but then if you asked me if I would use AngularJS, I would say definitely not.

I don't understand what is "Native Apps"? No links are provided.

The description is "tools_descriptions.native-apps", on the page https://2018.stateofjs.com/mobile-and-desktop/native-apps, which is probably, a bug.

My guesses are:

1) Non-JS mobile native apps built on Java and Swift.

2) Native script https://www.nativescript.org/

3) Smth idk about.

Most likely it is Non-JS native apps, Java, Swift etc.

I'm guessing it was a bug, because now the page you linked to says: The majority of mobile and desktop apps are still built with native languages like Java, Kotlin, Objective-C, or Swift.

NativeScript has its own separate page.

I hope Haxe[0] will make its way into this survey for next years, it's a solid JS (amongst other targets) transpiler alternative (better results than others, but less known).

Also, seems like a translation string is missing for vim (displayed as "tools.vim" in Other Tools > Text Editors)

[0]: https://haxe.org/

Thanks, I'll fix that. Regarding Haxe, sadly it didn't get many mentions this year so we probably won't include it as an "official" answer next year. Maybe in 2020 though!

Is it just me or the website is very hard to read?

With uBlock, I added a local rule that forbids access to fonts.googleapis.com from this site. Now it is much more readable with fallback fonts.

It is part of the sad state of the web that I often have to hack fonts and CSS of websites just to make them readable.

Not just you. If you narrow the browser the index hides.

A great state of js survey. Hmm where do I click to see the results? Maybe it's on the homepage. click. ooh fancy. Start - sounds good. click. View results yes that's what I want. click. But I'm back at the start?! That actually sums state of js in 2018 quite well!

On Android 8.0

As a student currently studying and working in Berlin I wonder why Vue and specifically Angular are way more popular than React. Looking at local job posting Java and Angular seem to be king for almost everything. How come?

Popularity with developers who reply to surveys is not the only factor in whether it is used. There's loads of sites that would need maintaining already written in Angular.

There are lots of new projects being written in Angular as well. Just not in the United States, Canada, or Australia.

Did you look for jobs in Germany only? Because Angular is quite popular in Germany. I guess this is because in Germany, freelance devs mostly do "enterprise stuff" (for car manufacturers) and Angular is "the enterprise framework".

Reminds me of the prevalence of TYPO3 as a CMS in Germany, which doesn't seem to have a big following anywhere else.

Yeah, that's my guess as well. Angular leaves you with fewer choices on how to structure your application. In comparison React only provides you with the view layer and even for routing you have to rely on third party packages. I personally enjoy working with a lean library like React but I can see why enterprises tend to prefere Angular.

Vue is popular outside the workplace. React is still the tool of industry. Plenty of Angular stuff out there too.

The survey highlights what devs want to do out of interest, not necessarily because that's where the job market is.

No surprises here this year: es6 & typescript, react & vue. I think I’d put redux and graphql in different categories as they’re not mutually exclusive. Nevertheless, I’m happy to see excitement for the latter.

For connection between technologies, this wheel chart type is not very helpful, things would be much clearer on confusion matrix[1]. It is a (ha!) confusing name, so it is better to call it coincidence matrix, but "confusion" is a traditional name for this already.

The authors actually use thix matrix type viz many times in the report e.g. for correlating salary information to other categories.

[1] https://en.wikipedia.org/wiki/Confusion_matrix

I get these surveys every year and every year I find myself unable to complete them because the choices you can select are awful - I forget what, exactly, but none of the choices apply.

It seems to me that like last year, several countries with very large developer bases are underrepresented. I'm thinking of India and the Philippines in particular, where English is not an issue. I'm an American, but I'd like to get a good global picture.

In addition, it would be good to see other indicators such as downloads, jobs (admittedly hard to measure accurately), BuiltWith trends, etc. Considering the millions of front end developers, this seems a very small sample size.

I felt that the average salary for India was very high. I was hoping to see somewhere near $20000 but it was $30600

Great work! I especially liked the quadrant charts in the conclusions, such as https://2018.stateofjs.com/front-end-frameworks/conclusion/ because they provide a quick way to see the opinions from the survey.

I can’t remember prior years, but browsing this site on mobile has been the most painful web browsing experience for me in years (iOS Safari).

Consider the design of the site in the future and mobile browser behavior - for example, tapping the bottom right button to navigate to the next view brings up the toolbar on Safari instead of navigating to the next page.

It is really awesome that they are using colorblind-friendly colors for the charts.

Props to Sacha Greif, another work of art in design and visualization.

2 data vis recommendations and neither are d3js

C'mon, is it that time of year again!!

budding dev here! I'm so impressed with the :onhover action of 'Start' button of https://2018.stateofjs.com/ Can anyone provide me a direction how to achieve that?

In sources panel open up the webpack:// folder and see ./src/components/elements/animation.js

First, see if you can figure out how to animate the boxes the way they are when you're not hovering over start: they're moving around the screen in a straight line until they reach the edge of the screen.

The animation we're looking at is moving SVG boxes around the screen, so if you search for tutorials about how to animate SVG with JavaScript, you'll quickly figure out how to make the animation happen. Although the technique isn't really specific to SVG; it'll work the same if you're moving divs around instead.

Once you've figure out how to animate DOM elements, to recreate what you saw on the start page of the survey, you'll want to keep track of each box's x and y velocity to know where to move them when you render each frame. If a box hits the top or bottom of the screen, reverse its y velocity, i.e. if its y velocity was 2, when it hits the top or bottom edge, it'll be -2. If it hits the left or right edge, reverse its x velocity.

Next, let's look at what's happening when you hover over the start button: each of the boxes has an assigned position, and when you hover over the start button, each box rapidly moves itself back to its assigned position. And it is timed so that each box reaches its assigned position at the same time.

To make that happen, you'll first need to figure out how far each box will have to move horizontally and vertically to get back it its assigned position. To get this, you just do (assigned y - current y) and (assigned x - current x). This will tell you how far each box needs to move in both directions to get to where it it needs to be. Based on this, you can calculate new x and y velocities for the boxes. Each box will have to move at a different velocity, because they'll all be at different distances from their assigned locations.

I've deliberately been a bit vague here, I know. I was going to put together an example on Codepen, but decided against it because it is so, so easy to take a look at someone else's code example and think you know what's going on without really understanding it. Whereas if you learn how to animate elements yourself, and then follow the thought process I laid out, you're a lot more likely to learn this deeply and remember it.

I hope this all helps, but if any of it seemed unclear, let me know and I'll do my best to clarify.

@rpeden: Thanks a lot for such detailed explanation! This is exactly what I wanted. I didn't even think that when I hover on 'Start' each box will have to come back with different velocities! Stupid me :P

And I really liked the idea of not putting a codepen -'think you know what's going on without really understanding it' - I totally agree and that has been happening quite a lot to me!

Just one more question - if I may! In the 'Connections' page, the graph looks a lot like D3js interactive 'Chord Diagram'. But I don't see d3js mentioned in <script> tags. Is this due to the webpack that it's possible to hide the underlying dependencies? I'm sorry if this is a dumb question - I've never used webpack.

Yes, d3 is loaded by webpack and you can find it in the webpack sources where it is loaded from node_modules.

OK. So it looks like my love of Angular is misplaced. Great now I have to migrate to React.

Website looks crisp and nice. Wondering if the source code for the site is available?

right click -> View Source.

https://github.com/StateOfJS/StateOfJS. It's in the surveys/2018 folder

Great content and great visual presentation, thank you!

that salary breakdown must be for world wide, including third world countries... $10K-$30K category?

Missing description for Storyboard.

TL;DR

The state of javascript in 2018 is a dumpster fire. It was a dumpster fire in 2017... it will be a dumpster fire in 2019.

I think the site is broken on my phone. I'm going to plug in scala-Js because nobody I have told it about has resisted saying wow

No mention of Nuxt.js. This survey is biased/flawed.

Ok, that was premature :) So it seems we're really not quite there yet -- fair enough. Was just surprised given there's a vibrant Nuxt.js community. Let's see next year!

I believe JS will be the universal language in the next 5 to 10 years. Other languages will continue to exist but 90% of developers will do JS... I can't wait to quote myself in the future :p

With the advent of WASM I'd be inclined to think otherwise: better languages eating javascript's lunch.

One can hope.

Been Waiting For this since Sascha was on the FreeCodeCamp Podcast

18000 respondents are men vs only 900 women

The State of What Men Think about Javascript

but seriously how was this survey distributed and is there any explanation for the gender discrepancy?

Maybe that's actual representation of the genders in the web development field.

If so, then it's still "What JS users think of JS."

https://www.ncwit.org/blog/did-you-know-demographics-technic...

According to this woman make up around 30% of web developers in the US. The highest amount of respondents are from the US so I would expect the woman respondents to be more than a measly 5%.

Eh. You raise a good and reasonable point but in this particular case I think you're comparing pomes to apples. "Web developer" is a pretty broad term, and was even moreso in 2012 when your statistic was generated. As an example: I'm a "web developer". But if I was surveyed about CSS (as a particular technology I barely understand, avoid using, and don't care about) I wouldn't respond. I would expect a number of my backend-focused colleagues to do similarly for other topics.

Being aware of sampling bias is good and useful; I'd just worry a bit about pulling too hard on that ripcord here.

This is very interesting: https://2018.stateofjs.com/javascript-flavors/overview/#tool...

Nearly 70% of JavaScript developers have less than 10 years of experience (with an average of 8.3 years).

This means they have never seen a Web where JavaScript was optional and Web developers were used to test their projects without it.

This in turn explains their outraged reactions to anybody that dare to point out its severe vulnerabilities.

See

https://bugzilla.mozilla.org/show_bug.cgi?id=1487081

https://dev.to/shamar/the-meltdown-of-the-web-4p1m

https://dev.to/shamar/i-have-been-banned-from-lobsters-ask-m...

https://www.reddit.com/r/firefox/comments/9v5qst/1487081_und...

I think your link regarding experience should be this: https://2018.stateofjs.com/demographics/years-of-experience

Reply on news.ycombinator.com