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.
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.
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 :(
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.
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...
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.
> 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 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.
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.
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.
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.
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?
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
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#.
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.
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.
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".
> 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.
> 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.
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.
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.
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.
> 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.
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".
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.
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.
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].
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.
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. ;)
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
"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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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).
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.
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..
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.
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.
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.
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.
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.
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.
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?
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.
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/
> 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!
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".
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.
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."
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.
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.
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.
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.
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?")
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.
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.
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.
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.
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.
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 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:
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).
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.
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.
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).
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.
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.
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?
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.
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.
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".
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.
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.
> 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.
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.
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.
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.
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'
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 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'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'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.
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)
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!
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!
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.
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".
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.
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.
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 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.
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?
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.
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
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.
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.