JavaScript survey: Devs love a bit of React, but Angular and Cordova declining. And you're not alone... a chunk of pros also feel JS is 'overly complex'

According to a sizeable group of coders who responded to a new State of JavaScript survey, the React framework is not only the most used front-end framework, it also has the highest satisfaction rating. Survey authors Sacha Greif and Raphaël Benitte persuaded 21,717 developers to contribute to the study, reached via social …

[IneptAdept]

Not sure where to go

As a long time web-dev working with .NET and then leaving for a few years to concentrate on mobile and desktop dev

I am not sure where to come back to re frontend frameworks. React looks nice etc but VUE is also fairly appealing

This is one of the main reasons I left web in the first place, to many frameworks lol

[Buzzword]

Re: Not sure where to go

You haven’t coded much web in a few years and you’ve heard the landscape changed a bit? Step this way and read up all you need to know:

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

That piece was written in 2016 and, to be fair, things have consolidated since then. The proliferation of web frameworks has settled down to a handful of winners (those mentioned in the article), though Javascript itself continues to add new features at a staggering pace.

[W.S.Gosset]

Re: Not sure where to go

> Step this way and read up all you need to know:

I filed this when it first came out -- it is excellent.

And also one of the socratic protagonists most wonderfully echoed my own feelings, and this is the quote I kept:

You know what. I think we are done here. Actually, I think I’m done. I’m done with the web, I’m done with JavaScript altogether. [...]

I’m just going to move back to the backend. I just can’t handle these many changes and versions and editions and compilers and transpilers. The JavaScript community is insane if it thinks anyone can keep up with this.

"If it's Thursday, it must be another framework/library/time to re-learn nothing but a ream of new words for the same damn thing. Again."

[K]

Re: Not sure where to go

I had a similar journey story a few years.. Backend developer, stepped out to assist with some servers, when I got home, some bar-steward decided my language of choice needed a dozen new frameworks - So I closed the door and went back to my server racks - I've never looked back.

Here's the thing, I always enjoyed development cause it allowed me to build stuff, it was my "art". But now, its a production line!

[Tim 11]

Re: Not sure where to go

For anyone (like me) who has been out of the loop and feels overwhelmed by it all, I think this video is a useful way to spend an hour of your time - less if you skip over the bits you're already familiar with. https://www.youtube.com/watch?v=0pThnRneDjw

[sum_of_squares]

Re: Not sure where to go

First you have to understand the paradigm shift from the "old school" (server-side) frameworks like RoR, Django, Laravel or ASP.NET MVC and the "newer" (client-side) frameworks. Maybe read up on Fat Clients vs. Thin Clients. That said, the hype train already moved on (the MEAN stack appeared in 2013!) towards other usele.. ehem, other technologies, but you can safely ignore that stuff.

My personal recommendation is to learn one server-side framework first - doesn't matter which one, just take 6 month and kick off a project. Afterwards you might want to look into Vue. If you understood Vue and are still curious you can take the deep dive into React. But be aware that (unlike Vue) React is not only a complete ecosystem with many different components but introduced whole new methodologies. Stuff like Flux or JSX breaks with a lot of classical web dev paradigms (i.e. keeping code and formating separated).

[bombastic bob]

Re: Not sure where to go

"As a long time web-dev working with .NET"

For that, you have my pity.

Question: why does anybody NEED "a framework"?

Javascript (in a web page) really has only ONE purpose: to perform minor UI tasks that would respond poorly if done by the server. On the server side, *USE* *A* *REAL* *LANGUAGE* !!!

If you code your web pages PROPERLY with CSS [not those 10Gb monolithic do-it-all style sheets, but one carefully tailored to your UI] you need very LITTLE, if ANY, javascript in them. I try to avoid it whenever possible, even in an embedded system using chrome in kiosk mode...

If you must script, there are BETTER ways to do it. PHP. Shell. Perl. Python. No "frameworks" needed aside from the built-in features and installible modules (unless you're a glutton for punishment by 3rd party bloatware).

Anyway, I'm sure that the JS fans will hate me for saying this, heh.

[Anonymous Coward]

Re: Not sure where to go

There are basically two kinds of people who claim "frameworks are bloat":

The first type will tell you their own measures against CSRF are much more refined and secure that those of Rails (and is probably right).

The second type will create a website that can be get pwnd easily with directory traversal attacks and SQL injections.

In my opinion the second type vastly outnumbers the first type, so unless you know what you are doing, use a framework. You got your CISSP, right?

;-)

[Anonymous Coward]

Frameworks

The news is not so good for Angular, once the rising star of JavaScript frameworks, but now in decline

The rise and fall of "flavour of the month" Javascript frameworks...

Will they all be superceded by Web Assembly?

[IneptAdept]

Re: Frameworks

Possibly

But again as a .NET dev I really liked the look of Blazor

But that is not a full fat web ui framework really so still in the same boat

[J27]

Re: Frameworks

Currently, I'm more into wondering when someone will write an engine to compile Javascript to Web Assembly. Oh, I know you're going to say something "Doesn't that defeat the purpose?" or "How stupid are you?" But I'm willing to stand by the prediction, because the current momentum in this space is to compile, transpile, minify and otherwise preprocess JavaScript six ways from Sunday and I don't see that changing any time soon.

[MonkeyJuice]

Re: Frameworks

Certainly you could actually do a much better job of compiling JS to V8 if you want to spend some time in an optimizing compiler.

Unfortunately because Spectre popped up, we no longer have access to SharedArrayBuffer. This means you cannot do concurrent garbage collection, so your overall performance would tank hard.

It's annoying but I'd rather not leave my keys in the dash.

[W.S.Gosset]

Re: Frameworks

> because the current momentum in this space is to compile, transpile, minify and otherwise preprocess JavaScript six ways from Sunday and I don't see that changing any time soon.

Uh, oh, it's been infected by its near-namesake's old slogan:

"Write Once, Run Anywhere"

[bombastic bob]

Re: Frameworks

"Will they all be superceded by Web Assembly?"

Angels, demons, gods, and monsters, I sure *HOPE* *NOT* !!!

I'd rather just see the frameworks *DIE* and people go back to doing things simple and clean, low bandwidth, low CPU utilization, rely on CSS features, yotta yotta, but good luck with THAT happening any time soon, as "web coders" still need to JUSTIFY THEIR OWN EXISTENCE.

I'd pay more money to someone who could "NOT use" JavaScript... or frameworks, for that matter.

[Anonymous Coward]

Re: Frameworks

Bob, reality called, it misses you and wants to know when you're coming home.

[djnapkin]

Re: Frameworks

Web pages with all the framework overhead run like dogs. No one ever wants to optimise or cull. We devs only to add more stuff into the page. Performance dies as a result.

Clean CSS, just enough JS to do the job (and no more) - otherwise your pages suck. And you aren't a real programmer if you can't do it that way.

[Pen-y-gors]

Re: Frameworks

The rise is fine, it's the fall that worries me.

I develop a lot of sites for academic projects - typically funded for a few years, and typically delivers a nice website and database at the end, along with various books and conference proceedings.

I'm currently going through some older sites (10yrs+ in some cases) and updating them from PHP5.x to PHP7.x, losing PEAR, tightening security and various other little tweaks. Hopefully they should then run for another 10 years without major work. After that, who knows.

My worry with flavour-of-the-month framework in JS, PHP or whatever is that it may suddenly become unsupported and even stop working in 2,3,5 years. Not a major problem for large corporate-owned sites that have the resources to redevelop, but tricky for academics with no funding!

So I think I'll stick to fairly plain vanilla stuff, even if it does take a little longer.

[Robert Grant]

JavaScript devs are also enjoying graphql more than Redux for the data layer

They aren't equivalents. GraphQL is like REST; i.e. you might replace Axios with a GraphQL client. Redux is state management inside the client Javascript code.

[Anonymous Coward]

It looks web developers spend more time changing framework...

... than actually making web apps really working in a comfortable way.

[Pascal Monett]

Must be the cost of having a vibrant ecosystem.

[bombastic bob]

Re: It looks web developers spend more time changing framework...

it's the temptation of "new, shiny" - like a cancer, except it's shiny.

[J27]

Yeah...

Yup and if you don't keep chasing it, you're out of a job. Web development is like chasing a slow-moving freight train. You can't rest for an instant or you lose it, because it's not stopping for anyone.

[Erp Erpington]

Re: Yeah...

It also means that you're probably gonna have to do some job hopping, just to keep up with the breadth of different tech stacks out there. That hurt me last time I was looking for a job: I'd been at my previous job for too long, and I was good at the tech they used, but there's just so much out there that I'd never had a chance to try out.

Of course, you often have to change jobs a lot if you want to be paid what you're actually worth, because hardly anyone gives real raises and promotions these days...

[Erik4872]

Doesn't paint JavaScript in the best light...

Wind the clock back to the pre-framework era for a second. JS is being twisted into so many things it was never meant for. It used to be a simple language for controlling page elements dynamically.and was never designed to be a real "programming language" in the traditional sense.

What boggles my mind is that the entire tower of frameworks, libraries and abstractions is built on such a rickety base. Just because every browser understands it, developers assume it's the best thing to build their entire world around. The fact that a coder-bootcamp graduate can't really be productive unless they're using some massive framework is not a good advertisement for the suitability of JS for all the things it's being pressed to do.

If only Flash and Java weren't such security nightmares, web development might have been different. The web is littered with different tries at putting in something more suitable -- I wonder if anyone is going to try again, or if they're so scarred by Silverlight/Flash/Java that they're just going to keep heaping junk on top of JS.

[Marco van de Voort]

Re: Doesn't paint JavaScript in the best light...

Yeah, I get the feeling that first gen JavaScripts are being confronted with legacy concerns, and it was not a nice meeting :-)

[Charlie Clark]

Re: Doesn't paint JavaScript in the best light...

One of the things the frameworks face is being replaced by native functions in the browser. This is to be welcomed, because over time it will simplify some of the stuff that is currently way too complex, but imposes a higher maintenance cost. And, as we all know, many many websites are barely maintained once written.

[Anonymous Coward]

Re: Doesn't paint JavaScript in the best light...

Native functions? Like all the proprietry junk that has littered web browsers since their inception? Native functions that will stifle innovation, because it has to be built into the browser, then tested, then downloaded, then have a significant userbase before anyone adopts it? Or do you want to head back into the dark world of shims and compatibility js layers just to support a 'framework function'?

The browser should be light, support a general JS feature set, and a general CSS set, and HTML5. All the frameworks should be entirely separate, because I don't want to be forced to use something that the big players have invested in - be it Facebook, Google, Microsoft, Apple, Adobe, Unilever, whoever. They only want what's best for them, not the general use of the Internet.

[Warm Braw]

Re: Doesn't paint JavaScript in the best light...

To be fair, HTML was never intended as a means to produce complex interactive user interfaces, so having to monkey around with the DOM to produce, say, a date-input widget, is not something you're going to write from scratch if you can help it. Changing the language for altering the DOM doesn't really fix the underlying problem.

[W.S.Gosset]

Re: WWW was never meant to be interactive

> HTML was never intended as a means to produce complex interactive user interfaces

Quite -- & actually quite the opposite.

Our entire "modern" world-wide web is in fact only the Read-Only Prototype subset of hypertext, quickly hacked out by a chap frustrated at the slowness-of-progress on the all-singing-all-dancing 2-way hypertext environment -- just as a bit of a talking point, a demonstration that at least the display ideas worked, to actually SEE something tangible rather than all the endless theoretical wrestlings, and to encourage progress on the main problem.

Instead, the world+dog leapt on the prototype and ran screaming off into the middle distance with it, and the full proper non-jumble-of-DSLs-masquerading-as-frameworks hypertext project kinda withered away in the background.

It's been "amusing" to watch people progressively plug that originally-planned functionality back into things, but via nails-on-blackboard bandaid hacks tottering on top of, and leaning backwards over, something fundamentally read-only.

[Kubla Cant]

Re: Doesn't paint JavaScript in the best light...

I suspect that part of the problem is the way the browser environment blurs coding skills with presentational talent. High-end sites will have UX specialists and graphic designers, though it's still a coder's job to get the concept on to the screen. Many sites make do with coders who have some sense of design.

[Michael Wojcik]

Re: Doesn't paint JavaScript in the best light...

When has that not been the case for user interfaces? Even in highly-constricted environments (GUIs built from simple, non-customizable widget sets, or CUIs in predefined menu environments such as ISPF, for example), user interfaces inevitably realize a user interaction model and enforce certain user experiences. Rarely do we see evidence that real UI designers - people with actual understanding of UI theory, doing actual UI research - were involved.

How many people here have ever worked on a product where someone did a user ethnography study, or contextual inquiry, or any other methodologically-sound research into usability?

[W.S.Gosset]

Re: Doesn't paint JavaScript in the best light...

...or who even have a clue what Fitt's Law is?

[AndyD 8-)₹]

Re: Doesn't paint JavaScript in the best light...

"...or who even have a clue what Fitt's Law is?"

hah! pointing devices - that's when it all went wrong -

computer systems and interaction with same worked fine when output was read and input was typed. UPPER CASE ONLY even helped a bit with the typing (only slightly joking)

[Mike Pellatt]

Re: Doesn't paint JavaScript in the best light...

Rarely do we see evidence that real UI designers - people with actual understanding of UI theory, doing actual UI research - were involved.

Certainly no such evidence when it comes to the Windows UI. I still want to know what the guys who dreamt up the Ribbon for Office, whilst keeping the rest of the Windows UI as the "traditional" one were smoking.

Coz I ain't going near it.

[Kevin McMurtrie]

Re: Doesn't paint JavaScript in the best light...

There were attempts to integrate Java applets into the HTML DOM. The idea was to ditch the arcane Sun Applet APIs in favor of something more modern and manageable. It never caught on for practical reasons. Java is a statically typed and compiled language while the HTML DOM is completely dynamic. It's not a good fit so it's hard to maintain.

[Elledan]

It's not about JavaScript

The thing about these 'frameworks' is that they aren't so much JavaScript frameworks as DSLs: domain-specific languages, which just happen to be implemented using this prototype language that supports only IEEE 754 32-bit floating point and ASCII strings due to legacy reasons (like being dreamed up in two days back in 1995).

Why nobody feels sad about these frameworks coming and going, and JQuery being the target of any front-end dev's jokes is that websites are pretty much disposable items. Give it two, three years tops before the next redesign and change to what's hot and new then.That's why backwards compatibility or even compatibility altogether doesn't really exist with anything JavaScript.

Want to use JS modules? Pick your poison between AMD, NodeJS or ES6 modules. Oh, and there's that requireJS thing that nobody uses any more. Unless they do. Found a nice JS library? Too bad it was written for NodeJS and doesn't work in a browser. Or vice-versa.

Having done both front-end and embedded JavaScript development (yes, it's a thing...), it's left me burned out to the point that I'll be very happy to never have to deal with it again in a professional setting. It's a very special world, but not one which I'm convinced is healthy for itself or those who venture deep into it. I'd rather deal with legacy C or FORTRAN code bases than ever touch a commercial JS project again.

[jake]

Re: It's not about JavaScript

For the record, there is still far too much work for not enough Fortran and COBOL coders. If you know either of them well, you can make a lot more money than a common or garden Java Script coder. If you know both, you can pretty much write your own ticket.

Good old fashioned C will always have a place in the world of coding. It should be a part of any real programmer's toolbox.

[Tom 7]

Re: It's not about JavaScript

I'd be quite happy to work on a JS project if it adhered to simple software management standards* and KISS - not found one yet.

* perhaps the Unix idea of "Do one thing and do it well" is all we need..

JS is like any other language - but it seems to have far too many self taught code warriors who can produce a simple flashy interface with all the bells and whistles but none of the organised back end supply lines required to keep it fighting for long.

I think its fair to say legacy C and FORTRAN code is easier to work on - but only because the code warriors who wrote this stuff had experience of keeping the supply lines going - if they hadn't we wouldn't need to keep supporting it as it would have died out long ago,

[Michael Wojcik]

Re: It's not about JavaScript

supports only IEEE 754 32-bit floating point ASCII strings

ECMAScript (which all modern "Javascript" implementations conform to, more or less) has supported 64-bit IEEE 754 floating point and Unicode strings since at least the 5th edition (2011). I'm almost positive earlier editions supported Unicode too (unsure about 64-bit floating point), but that's the version of the standard I have at hand.

See ECMA-262 5th edition, sections 4.3.19, 7.8.4, and 8.4, and their references.

[Mike 137]

JavaScript is "overly complex".

JavaScript is bloody lethal, and that's much more important than any complexity. The fundamental problem is an ingrained insistence of doing things client side that for safety should be done on the server. Add to that the common practice of kludging together arbitrary code fragments off web repositories and invoking unverified third party modules, and we get the mess we now call the web.

A significant amount of JavaScript I've investigated is utterly unnecessary - e.g. using script for links and blocking the HTML anchor with #, or loading images using a script instead of the <img> tag, and can only be explained either by lack of understand or by the desire to force JavaScript to be enabled to allow snooping.

Thank goodness for NoScript, and if I can't see your lovely pages as a result of using it, tough on you. There's always another better site I can visit.

[Sir Awesome]

Re: JavaScript is "overly complex".

Call it self-celebrating, but I've always written all the JS I use myself, with the exception of the odd tool such as CKEditor. If I find a snippet I need online, I pull it apart and rewrite it to be sure I understand it and it adheres to my own standards.

I'm also careful to also only use JS when something's not possible with native HTML or server-side code. Surely this is just a part of becoming a good coder?

[Spamfast]

Re: JavaScript is "overly complex".

I'm also careful to also only use JS when something's not possible with native HTML or server-side code.

I upvoted this because I largely agree, the gratuitous use of JS to do things that HTML and CSS are perfectly capable of doing alone annoys the hell out of me, for example.

But there're some things that can't be done server-side such as rapid interactivity. Google Maps would be very clunky without client side code, for example.

There's also the advantage of doing things client side in that it's more scalable. The server-side CPU and bandwidth resources required to serve up a set of static JS scripts, media assets, CSS & HTML files and a few WebSockets are way lower than trying to do everything at the head end for every client device.

[bombastic bob]

Re: JavaScript is "overly complex".

"only use JS when something's not possible with native HTML or server-side code"

Good! Job!

[djnapkin]

Re: JavaScript is "overly complex".

Re "but I've always written all the JS I use myself, with the exception of the odd tool such as CKEditor" - do you use jQuery? I find it doesn't impact the performance of my sites at all. Plus, the user's browser almost certainly has a cached copy already.

[bombastic bob]

Re: JavaScript is "overly complex".

(did you actually PROMOTE jquery???)

I had to take over the 'web stuff' on an embedded project, and the "developer" slapped 3rd party "strap-ons" together to create the UI, which I then ended up hacking and heavily modifying to make it work.

And throughout the code I've marked it up "TODO: un-jquery this" and similar. *I* *HATE* *JQUERY* - it is the *WORST* example of *WHY* *YOU* *DO* *NOT* *WANT* *SUCH* *THINGS* !!!

It is *THE* PRIMARY example of why you do not want such "frameworks" at ALL.

[learn to use DOM, and you will not NEED such things - W3Schools web site and others will help you. Search engines are your friend. I use them a LOT]

[Michael Wojcik]

Re: JavaScript is "overly complex".

The fundamental problem is an ingrained insistence of doing things client side that for safety should be done on the server

That is not a "fundamental problem" of the language, by definition. It's not an attribute of the language at all. It's a matter of how it is used.

[Spamfast]

Re: JavaScript is "overly complex".

Let's all do server-side database queries by concatenating GET & POST responses onto SELECT strings and client-side JSON parsing by executing it as JS. What could possibly go wrong?

Never trust anything that's come to you over a comms channel any part of which is not under your control. That applies to clients receiving server data and vice versa. Sandbox everything.

[bombastic bob]

Re: JavaScript is "overly complex".

not so much sandboxing, but sanitizing. A good sanitizing algorithm will eliminate the possibility of SQL injection, as one example...

my favorite is to look for ';' and '/' (or quotes, or path starts with '..' etc. - or SQL keywords if that's at issue) and just reject things outright that contain these characters/sequences. Others also exist. simple test. PHP script has some other built-ins as well.

the only reason you would NOT want to do everything server-side is performance latency [when the server is across the world, let's say, or the bandwidth stinks]

[Anonymous Coward]

The reason javascript has so many frameworks

Is because the people who develop in it are mostly 3rd rate programmers who couldn't cope using grown up languages writing proper systems and couldn't hack their way out of a wet paper bag so need even the most basic things done for them so they can plug lego their brick code together and pretend they're professionals to the pointy hairs.

[martinusher]

Re: The reason javascript has so many frameworks

>Is because the people who develop in it are mostly 3rd rate programmers

That's probably being a bit harsh. Judging by the profile of these programmers they seem to be both inexperienced and badly led. You get young people straight out of their CS degree course, you pay them big bucks and work them to death (because the language requires that kind of bottom up knowledge; more experienced programmers would be asking the 'why' and 'what' and probably wouldn't appear as productive in terms of 'code lines per day' output). The result's invariably rubbish -- there's a few exceptions to the rule, but generally the result is bloat, communications overload and bugs.

I don't blame the guys in the trenches because someone blew the whistle and ordered them to attack. Lions led by donkeys....

[jospanner]

A javascript-heavy website is a bad website.

Thank god for uBlock.

[(m)any]

And uMatrix.

[John Gamble]

Everything Changed with ECMAScript 6

It's the reason jQuery (and a couple other libraries) became irrelevant, and it's why "good parts" philosophy could be enforced. Javascript is still a little clunky, but a lot of the comments above are clearly based on turn-of-the-century experiences.

I'm still a little scarred from previous experiences, and I'll note that I backed a couple of losers in the Javascript world, but on the other hand I'm glad a testing framework has finally gotten some consensus.

[Dave559]

More of this sort of thing, please

More of this sort of thing, please.

Thank you, this was an interesting article, and, as usual, further greatly enhanced by some helpful and informative comments by fellow commentards.

I don't know why The Powers That Be at The Reg decided at some point to silo off software development related articles to a dead-end separate website (Dev Class) with no commenting/forum available (and therefore, no disrespect to your journalists intended, immediately losing half of any potential value that it might have, by excluding the input of the community that The Reg itself has built up over many years), but I for one would be very pleased to see more software development articles, like this one, actually on The Reg itself in the future.

[W.S.Gosset]

Very much more of this sort of thing, please

Hear hear. Very much hear hear.

I've been growingly concerned that El Reg is turning away from its USP.

Viz., (ex)front-line practitioners, writing entertainingly but with ability to land more telling blows than others due to actually understanding what's important and understanding what's going on under-the-hood and behind-the-scenes. Not just pure IT but relevant and insightful, eg Worstall. This, in a nutshell, is how TheRegister has garnered a global gold-class reputation.

Latterly, it's all got very samey-samey, little or no UTH/BTS insight, cookiecutter journo-ese. Very occasional and very refreshing returns to form (eg Dabbsy, Stobb), but so few now as to start mourning the loss of what ElReg stood for.

[Anonymous Coward]

Why is JavaScript "overly complex"?

Because of all the features developers kept asking for. And the pressing need to be "ahead of the Joneses".

[Anonymous Coward]

C

C never needed all this gubbins tacked on. Is Javascript really fit for purpose?

[Anonymous Coward]

It's always been a mess.

I was a server side developer and we used to develop with a lot of MVC and have been amazed at the capabilities of these frameworks ,BUT, having put up with my own browsing and increased network volumes loading frameworks and libraries (especially on high volume websites) - I long for the day of a clean interface.

When I started with CSS, JavaScript etc - I used to always go back to the likes of http://csszengarden.com/ to see how we could focus on the content and clean, simple, low bandwidth HTML code and separate out the CSS and design elements.

[Kevin McMurtrie]

DOM it to hell

I think JavaScript is evolving fairly well but the object model HTML isn't. HTML elements can't behave as ordinary data structures for JS to manipulate. You can't define them in JS variables/constants using HTML syntax. You can't manipulate them in the DOM without rebuilding the GUIDs and backlinks. This is where the frameworks come in to help. These frameworks seem to die a bloated death every 6 months and be replaced by another having the same fate. Just fix the object model and give poor front-end developers a break.

[prandeamus]

How to track this one

I think this website says it all: https://dayssincelastjavascriptframework.com/

[Joker421]

Angular still strong

Angular is declined? No way. Angular has it's own market and it is still strong.

AngularJS is declined that is true, moreover it is just was being officially deprecated in Dec 2021

However AnulgarJS (v1.x) and Angular(2+) are two completely different things

https://angularjs.org != https://angular.io

[diodesign]

You're commenting on an article from 2019...

...in which the people who did the survey chose not to make a distinction between Angular and AngularJS.

C.