JavaScript survey: Most use React but satisfaction low

The State of JavaScript 2021 survey has arrived, a little later than planned (no jokes about language performance, please) and in the wake of a somewhat embarrassing data leak. 2020's State of JavaScript report came from a survey of 23,000 developers. 2021's was the result of just over 16,000. And although the US leads the way …

[Anonymous Coward]

Representative?

How was the survey disseminated? My undergraduate statistics impression is that there is some MASSIVE selection bias going on. I can't put my finger on it, but (and feeling is important when doing statistical work) I feel something's off there.

[Anonymous Coward]

Re: Representative?

Yup, "mostly learning from inline tools" in a survey on stackoverflow (which does contain a lot of really bad and dangerous code, but also some cool stuff). Since I don't look up stuff on SO (that often) I was not aware of the survey...

[Dan 55]

Re: Representative?

SO attracts copy-pasta coders, and JavaScript is the language they use.

[Anonymous Coward]

Re: Representative?

> SO attracts copy-pasta coders

Specialist at producing spaghetti code?

[CommonBloke]

Re: Representative?

Exactly. It either falls apart at the slightest pull of a string or it rolls over itself and gets way too big to fit where it's supposed to go, whether your fork or RAM.

[Anonymous Coward]

> the vast majority (93.2 per cent) of those who answered the gender question

Yes but of those who took the survey, how many did answer?

Also see representativeness above if thinking of making inferences about the population of JavaScript users.

[Joe W]

https://insights.stackoverflow.com/survey/2021#section-demographics-gender

about 1.5% do not identify in the traditional binary gender definitions, 1.5% prefer not to say, 1% as "Or, in your own word" - whatever that means.

Also: vim is #4 in the loved editors - just ahead of emacs ;)

[AMBxx]

I read that as 1.5% clicked the wrong option. 1.5% don't want to say and 1% are taking the p1ss.

[Joe W]

"Learning how to code"

#1 spot: online, from videos and blogs. Hm. Yeah, lots of good scarily bad examples out there... ;)

50% have been coding for 10 years or less. I feel old now. That would have been the case for me in... the 90s. (no wonder my colleagues keep getting younger and younger - I have now a sudent coding some stuff for me, I am more than twice his age, scary).

yeah, I too tend to look up some solutions online, especially when using features/tools/libraries I have not used before - or not in a while, and most documentation for libraries is in fact online. So I guess I too fall into the "learning mostly online" group nowadays. Oh, and I grudgingly admit that the online courses offered by Microsoft are not too bad as fisrt steps. However, I also tend to attend courses when confronted with (for me) new stuff, much better to get good examples and be able to pepper a pro with questions on why and how certain things should (or cannot) be done.

[zuckzuckgo]

Re: "Learning how to code"

> I have now a sudent coding some stuff for me, I am more than twice his age, scary).

So your students over 30? That is scary... Now I'm feeling my age.

[Scott 53]

Re: "Learning how to code"

I remember making tea in the office talking to a colleague when it struck me that the T-shirt I was wearing was older than she was.

[Rich 2]

Frameworks

I cannot think of JavaScript as anything other than a hacky abortion that is an unfortunate necessity to get some useful website functionality, but putting that aside for a moment I am amazed that the use of a “framework” for a language is so prevalent and deemed acceptable. It says a lot about the language that such a framework is considered by many to be a standard requirement. Compare this to a language such as C - no frameworks here!

As an aside, I have written some quite clever JavaScript websites - you don’t really need any “framework” at all - just a lack of lazyness and some patience.

[martinusher]

Re: Frameworks

I've written some things in it as well but as a programmer I dislike coding it in. It reminds me of the early days of BASIC when a useful but untidy language was stretched far beyond where it was intended to go because of the commercial need to 'get something out now'.

I think there's a hidden menace in these statistics (let's ignore their potential unreliability for now). Reading between the lines it seems that the demands of web development require armies of young people pumping out code as fast as they can. Programming cannon fodder. Most of us who've 'been there' know that the quality of the code will suffer and the current (non) performance of websites and other cloud type applications reflects this. Could it be that much of our vaunted technology industry is really a form of Ponzi scheme?

[I am the liquor]

Re: Frameworks

It's fine that the code quality is terrible. A couple of years into the future, the framework that it's all written on is no longer flavour of the month, and most of the hundred other dependencies that were dragged in are no longer maintained at all. What's the point of building maintainable code on top of such a house of cards? Consider it disposable from the start. Throw it away and build a new one. Building code that'll be runnable and maintainable for a decade or more is such a 1990's concept.

Ponzi scheme sounds about right.

[martinusher]

Re: Frameworks

>It's fine that the code quality is terrible.

Maybe, except what you're really saying is that "the majority of programmers write terrible code because they don't know any better". Or "the majority of our programming productive effort is going towards single use advertising copy".

If anything disturbs this ecosystem we'll have a lot of people out of a job with consequent knock on effects for the rest of the economy. Since the ecosystem is inefficient its essentially unsustainable.....draw your own conclusions.

[pavel.petrman]

Re: Frameworks

I concur. I've taken part in development of a few SPAs in my time that could and would last a decade or more without major rewrites (some even had versioned internal APIs). If I were to attribute their longevity to a single one decision, it would be to avoid using frameworks. I mildly believe, as I have got no reliable data on this, that time invested at the beginning to analyze, think the requirements over and implement our own thing was outweighed by time savings on framework update rewrites in year five or thereabouts.

Frameworks are good for prototyping, especially in today's popular startup economy, where startups most often serve as a vehicle for sharing ideas and facilitating group recruiting. Case in point is the self proclaimed coding hero Elon Musk, who used to brag about how he single handedly built the X.com online payment infrastructure, which apparently worked so well that had the startup not been bought out, it would have died within weeks by bleeding money through many of its security holes, and upon acquisition had to be promply rewritten from scratch by people who had allowed themselves regular sleep and other expensive luxuries. Good for all of them, I would say, and a good use-case for a framework, generally speaking.

The problem occurs whith a company structure that is, sadly, quite often seen today: shareholders and developers are in it for the long run, whereas low level management want to startup their way to big bonuses and C-levels in the shortest possible time. This quite often results into managers forecully startuping and agiling projects which far outlive the said managers' tenure, to the eternal annoyment and suffering of developers, customers, higher management and not seldom even shareholders.

[I am the liquor]

Re: Frameworks

I think that's a good call. For all the shortcomings of languages like JavaScript or of inexperienced programmers, they're secondary issues; I'd agree the number 1 barrier to maintainability of systems is choice of dependencies.

Everything has dependencies of course, but if you've stuck rigidly to "dinosaurish" dependencies like, say, Oracle or MS .Net, or something defined in an ISO standard, then the chances of your code still running in 10 or 20 years are good. If you've machine-gunned your system full of random stuff off NPM or NuGet, then chances are not so good.

[Anonymous Coward]

Re: Frameworks

"Building code that'll be runnable and maintainable for a decade or more is such a 1990's concept."

Surprisingly my Javascript coding for a complex set of web pages was written in 2003 and still works ok. There were hiccups in the early days as browser implementations of features varied - but it has been pretty stable for years.

[Anonymous Coward]

Re: Frameworks

"A couple of years into the future, the framework that it's all written on is no longer flavour of the month, and most of the hundred other dependencies that were dragged in are no longer maintained at all."

…and also during that period, that site or app will have been hacked, twice, and all customer personal data stolen. But it's OK, because "Our customers' data is very important to us, especially because we allow Google and Facebook and others to slurp it up, too, and, oh, is this mic still on? I didn't say that last part, must have been a 'rogue engineer'…"

[AMBxx]

Re: Frameworks

Should the JavaScript frameworks have a description other than Framework? In Java and C#, the frameworks are effectively a class library extending the language in useful ways (I've no desire to write an Array Sort).

In JavaScript, these 'frameworks' are more like layers on top to hide the ghastliness of JavaScript behind some more structured stuff. They're bordering on being new languages in their own right.

[Anonymous Coward]

Re: Frameworks

A hacky abortion?

An abortion saves you money in the short and long term.... *ducks*

JS doesn't do either, therefore your description isn't applicable.

[captain veg]

Re: Frameworks

JavaScript is actually quite nice for grown up programmers who take the time to understand what it actually is. A bit like C, it's small and trusts you do know what you want.

I imagine it's a perfect nightmare for the vast hordes of offshored code monkeys employed by "modern" project managers in "agile" teams. For them I can see that blindly following the precepts of whatever framework is currently in the news would have at least the assurance of prescription, albeit fleetingly.

> you don’t really need any “framework” at all

Indeed not. Some library code saves typing, but you really ought to be able to produce it yourself.

-A.

[Dinanziame]

Re: Frameworks

Some library code saves typing, but you really ought to be able to produce it yourself.

That's all well and nice, but there's really a lot of stuff people should not do themselves. The prime example is encryption, but websites are full of pitfalls as well, especially regarding security. "Nice for grown up programmers" can also mean "lets you shoot yourself in the foot".

[captain veg]

Re: Encryption

Sure, I agree that only researchers should attempt to develop encryption algorithms, and subject to peer review.

But a competent JavaScript* programmer ought to be able to *implement* a published algorithm without too much bother.

Anyone can knock up some code and put it up on GitHub, or whatever. It might be high quality. It might be better than I (or you) could have managed. It might no. There's certainly no guarantee.

-A.

*Substitute your programming language of choice.

[CommonBloke]

jquery

Is all you need to speed up production of sites and make them behave the same as some sites of today, using less than 100kb and being a hell lot more stable, instead of a dozen different libraries and dependencies that might as well be nothing more than a circular dependency hell. You don't need 50MB of javascript to make those sites with different backgrounds depending on where you're scrolling.

[Anonymous Coward]

Re: jquery

As an aficionado of NoScript, and someone who occasionally looks at site source code to see what sort of turbulent mess is actually beneath the surface, in order to try to work out the minimum amount of junk needed to 'allow' to get the site to work, it's sadly not uncommon to see two or three (or more) frameworks/libraries in use, each of which often seems to bring in its own different version (literally different version numbers) of jQuery.

How such a mess of ingredients manages to work at all is beyond me (a bit like that previous sentence, sorry!).

[sabroni]

Re: Compare this to a language such as C - no frameworks here!

I think that tells you more about the mindset of people who choose to code in C than it does about frameworks.

[ShadowSystems]

JavaScript: Just Say No.

Friends don't let friends use JavaScript.

*A loud, boisterous, feisty raspberry of snarky sarcasm*

[Fastitocalon]

"Sadly, the vast majority (93.2 per cent) of those who answered the gender question listed themselves as male, up on last year's 91.1 per cent." It's sadder that, according to government statistics (hse.gov.uk) in the UK: "In 2020/21, 138 (97%) of all worker fatalities were to males, a similar proportion to earlier years".

It may just be that men are generally more interested in programming than women. To spell it out, the programming disparity is being casually presented as a problem when it may not be.

[I am the liquor]

It is a bit of a self-fulfilling prophecy though. Finding yourself the only woman in your class or office is likely to be a discouraging situation to many.

[Fastitocalon]

If someone is discouraged by studying or working with members of the opposite sex then I'm not sure how committed they really are! Learning to program does take some self-motivation and interest in the subject.

I'd like to see a lot more women studying and working in tech but it's better to encourage it at a young age. However, if the outcome isn't as desired and there is still a disparity then there may be a difference that can't be "solved".

[I am the liquor]

Thanks for illustrating the problem.

[Fastitocalon]

Try looking at it a different way. According to government figures around 3/4 of teachers are women. Would it be fair to say that "Finding yourself the only man in your school is likely to be a discouraging situation to many."?

[I am the liquor]

It probably is, though to a vastly lesser degree. A lesser degree for two reasons: 75% is not 93%; and "toxic femininity" is not the same problem as "toxic masculinity".

[Tom Graham]

Thanks for illustrating the problem of toxicity.

[AMBxx]

Maybe women took the trouble to read a manual. Now they don't need our help!

[Anonymous Coward]

StackOverflow is a fairly toxic place.

I stopped posting there a few years ago because of that. These days I only go there by accident of Google hit.

So I suspect quite a bit of this is the self-selection bias.

The site pushed away most of the women etc, and once they've gone they won't come back - and definitely won't waste their time doing surveys if they do hit via Google.

Maybe they've improved their moderation, but I really can't be bothered to find out.

[Disgusted Of Tunbridge Wells]

The solution to the gender imbalance in STEM subjects is to force women into careers they don't want.

Obviously it's never phrased like that...

[sabroni]

re: Obviously it's never phrased like that...

Because that's not what happening. Women are discouraged from these careers by men. They're taught to play with dolls not cars, they should look pretty not accomplish things.

This isn't difficult to understand but it is easy to pretend it's not a problem.

Especially if you're a man apparently.

[Anonymous Coward]

Re: re: Obviously it's never phrased like that...

Yep - my 4 year old daughter has already started telling me that girl's should play with dolls and wear make-up.

I promise you, it's not her gender or inner-self that's telling her this. And I'm doing my best to ensure she knows that it isn't true.

[Anonymous Coward]

It's actually really good news for the women that do work in JavaScript as every large company is desperate to employ them to fix their gender balance stats.

There will never be a better time to become a female coder. I've booked my surgery.

[Tree]

LOVE ALL

When is it sad to have many males? It is common that men and women are different in many ways. Vive La Differance!

[tiggity]

..popular?

"JavaScript remains far and away the most popular language among developers, notching up nine years as the most commonly used language in SO survey"

Most commonly used does not necessarily mean it's popular.

I despise JS, but unfortunately part of my work involves having to sometimes fix web sites / apps that use it.

So I'm a JS user, but an unwilling one (Burn it with fire is my approach to JS*).

A bit like when, pre COVID, I had to be in the office every day.

That meant daily train journeys... that did not mean I enjoyed the train journeys (be it the getting from A to B if lucky, the only once an hour timetable, the pocket hammering cost etc.)

But a survey of my travel would have shown train as the most used travel method (by number of journeys or by miles travelled) - so another "commonly used" but not popular scenario.

* In the unlikely event the current tensions in E Europe lead to global thermonuclear war at least I can look at the mushroom cloud and cheer myself up that its the end of JS too, so not all bad

[Adrian 4]

Re: ..popular?

Another common way to measure 'popularity' is by numbers of questions on stack overflow etc. A measurement not directly of popularity, but of how often people need help with it.

[Anonymous Coward]

Re: ..popular?

"JavaScript remains far and away the most popular language among developers"

No, JavaScript remains the most popular language amongst StackOverflow users who respond to surveys.

This is not the same thing AT ALL.

Bad The Register, go stand in the corner.

[Anonymous Coward]

Re: ..popular?

No, it just means it remains the most popular language for questions because it's a crock of ..... and nobody can work out how to do basic stuff.

Me included - come on '===' for ffs.

Go read some Knuth, Wirth or Djikstra ... other good computer scientists are available.

[itzumee]

What do we want? Static typing!

Why not just use TypeScript then? Yes, it's a lot more than just a strongly-typed Javascript but it also gives you so much more.

[captain veg]

Re: What do we want? Static typing!

Why not use, I dunno, C# then? You can transpile it fo JS with LLVM.

On the other hand, why introduce a tedious and completely unnecessary compilation phase at all? JavaScript is already a general-purpose Turing-complete language. It supports functional and object-oriented programming models. I really don't get the idea that some kind of "build" is necessary. It just isn't. The convenience of deploying source files directly is considerable. Let the browsers optimise the interpretation (which might involve hot compilation) and HTTP manage compression.

Don't get me started on CSS preprocessors.

-A.

[SecretSonOfHG]

Re: What do we want? Static typing!

<<On the other hand, why introduce a tedious and completely unnecessary compilation phase at all?>>

I think they call it "type checking"

[captain veg]

Re: What do we want? Static typing!

Yes. And?

I'm long past the time when assigning a value of the wrong type was a serious source of errors, or a source of serious errors. Strong typing fixes a problem that I simply don't have, and makes me jump through hoops which needlessly harm my productivity.

Your mileage might vary.

-A.

[James R Grinter]

Re: What do we want? Static typing!

It’s a problem a developer may not have, but you can bet the users will encounter it (unfortunately they won’t know that’s why the page is entirely blank or unresponsive).

[sabroni]

Re: I think they call it "type checking"

Only really useful at run time. Your compile time "type checks" don't mean shit when your code has to handle a type it wasn't expecting.

TypeScript does not make JavaScript type safe!

[sabroni]

Re: Why not just use TypeScript then?

Because TypeScript is a compile time veneer over JS and doesn't stop you getting an integer in the field TypeScript told you was a string.

TypeScript makes it worse because users who don't understand it think it makes their code type safe.

TypeScript makes it easier for your IDE to do tooltips. That's what it was invented for. It won't make your code type safe, you have to do that yourself.

[Charlie Clark]

Representative?

Really, who cares about the gender distribution in self-reporting studies? Like other bits of web progamming, JS development has for years been outsourced to the cheapest bidder, so the survey is largely reflecting the career opportunities and choices in those countries.

But if you want more evidence that the survey is not representative then look no further than the number of respondents who want static typing! In Javascript? As if there aren't other, bigger problems with the language. But also with TypeScript there are alternatives for those who crave the staticness.

[IamStillIan]

Re: Representative?

I'd have said the popularity of TypeScript is proof that JavaScript isn't fit for purpose and people do want strong typing...

[Charlie Clark]

Re: Representative?

Considering what Javascript was initially developed for and what it's now used for and you can cut it some slack. In fact, given the speed with which it was released and, despite the fact that I don't like it personally, it was remarkably well done.

But, more importantly, static typing is not strong typing. Static typing gives the compiler some optimisation options and might catch the odd bug but won't solve any real problems. But if you want types for your front end web development, go with TypeScript.

[IamStillIan]

Re: Representative?

I have no issue with the fact that Javascript was made for something very different, so the language itself isn't to blame for that.

However, the way it's used now means it's become a barrier to progress, and is underminding the web.

[Totally not a Cylon]

The language to make the web slower

Hmm, JavaScript the language which makes modern webpages load slower than they did on 300baud modems....

All web developers should be forced to access their 'cleverly designed site' using a 300baud acoustic coupler on a normal phone....

[spireite]

Re: The language to make the web slower

A system I know of was massively slow. Reason? Shedloads of Javascript that noone understood, and actually had no use whatsoever.

On that basis, I wonder if any of the train operators are running their services with Javascript....

[Anonymous Coward]

Re: The language to make the web slower

It could be like the stagecoachbus.com site that has been down for well over a week.

Perhaps someone has hacked the huge amounts of JS that it used?

The IOS App is pretty shit as well. There is no way at least around where I live that you can track your bus in real time.

[captain veg]

Re: The language to make the web slower

Yes.

Anyone who makes a web *site* dependent on JavaScript needs firing fast.

Anyone that puts a web *application* online, however, probably should* use JavaScript. They ought to make it work as efficiently as possible. This is unlikely to involve, for example, Angular.

-A.

*OK, you can get application-like functionality from repeated POSTs, but efficient it ain't.

[IamStillIan]

Re: The language to make the web slower

Bring on WebAssembly..

It's not perfect, but as the first realistic chance of taking down Javascript since it rose to prominance, we've got to support it...

[ibmalone]

Re: The language to make the web slower

I've recently discovered a couple of very cool projects in WebAssembly:

1. Web MiniDisc, talk to a netmd minidisc player from the browser, handles transcoding for file transfers, USB interface. The original software for this stuff is long abandoned and only ever worked in Windows. The tools used in the Web MiniDisc version are from Linux-land, bit of a hurdle for most people.

2. Lichess runs the Stockfish chess engine in the browser. It makes it easier for them to provide a free chess service as server-side computing isn't needed. Sadly hasn't gone the whole hog and you still need to be connected to play against the computer.

In both cases it lets you do things with a wide range of devices so long as they support a modern browser. And while it may not be the most efficient approach, for these applications it's arguably a better experience than running some kind of dedicated container.

[CommonBloke]

Re: The language to make the web slower

One of the systems I'm working on currently loads roughly 12MB of javascript on your browser before it starts working proper. Even running on localhost, it takes some 20 seconds to load. It's as if the answer to Moore's law was creating increasingly unoptimized and use all the extra processing power on utter junk

[spireite]

I often look at Javascript....

... and ask 'Look at the state of that!!'

That's not what they meant???

[Not Irrelevant]

We've switched to using React for most front-end UIs, initially I figured it would make some of the more complex UI systems the designers wanted more feasible. But it has genuinely reduced the amount of time it takes us to write UIs. We're re-using the same API endpoints multiple times and it eliminates some of the duplicate coding (having to do the same thing in back end renderer and manipulating the front-end DOM directly) and the end result performs better and transfers less data to render the same pages. The one negative is that it does use a bit more CPU usage on the client, which is pretty much unavoidable but we do try to make sure that even a very low-end phone is able to use the site well.

P.S. I'd love static typing, living with Typescript for now, it mostly just helps you find logic errors easier and it definitely makes refactoring a lot less annoying.

I'd rate the current state of JavaScript as "not as terrible as it was" I still wish something like Dart (but preferably more open) had replaced JavaScript. WebAssembly is a neat idea because you're able to piggy-back pretty much any language you want on top of it, but currently the performance isn't even up to par with JavaScript for most uses yet.

[captain veg]

I was going to say that

having to do the same thing in back end renderer and manipulating the front-end DOM directly

is clearly a mistake. Rendering should happen in the front end, by definition.

But

we do try to make sure that even a very low-end phone is able to use the site well

Which is admirable. But really, if your UI can't render efficiently on a smartphone -- which has CPU and GPU power that was unimagineable when I started coding GUIs, then your problem isn't which device it's rendered on.

-A.