JavaScript survey: React everywhere, Jest, Webpack on the up... if only it had static typing, sigh developers

The 2020 State of JavaScript report, a survey of over 23,000 developers globally, has revealed growing use of WebPack and Jest, continuing high use of React, Express and TypeScript, and that top of the wishlist is no longer better browser compatibility, but rather static typing. JavaScript is the most used programming language …

[Anonymous Coward]

At work our "front end" code is a mish mash of Vue and React with builds driven by Gulp, Grunt and Webpack. We're trying to move to TypeScript and standardise on React, but it leaves us with the same problem of "legacy" code that I'm sure afflicts most web projects. I'm responsible for the back end code (Java and C++), but working closely with the front end team has given me some insight into their pain.

It would be so good if the major web browsers could start supporting TypeScript natively, and remove some of JavaScript's more stupid features (the messed up equality stuff being chief amongst them). Given that TypeScript is a superset of standardised JavaScript, all the optimisation work on the JS engines would not be lost.

And as the survey respondents note, a standard library would be a massive improvement. One thing that has helped keep our Java code relatively compact is the class library. It lowers the bar for new people working on the code, since we're not using myriad different libraries to do similar things. It also improves security and stability, since the standard library is generally well designed, consistent and updated along with the rest of the core Java platform.

As for build systems, in the Java world we also suffer from duplication - Ant (although that's very legacy now), Maven and Gradle. I loathe Gradle, thanks to it being based on Groovy and being essentially a scripting language masquerading as a build system, but that doesn't mean I love Maven. However, having one half decent build tool is at least an improvement over the JS world. We even have projects that use a combination of JavaScript build tools to overcome deficiencies in each other!

[captain veg]

The "messed up equality stuff" is simply coders using the wrong operators, usually out of ignorance or laziness. There's really not much excuse, especially as a linter will pick it up.

-A.

[Anonymous Coward]

Frameworks are not your friend.

Just finished a rewrite of a fairly large/complex vanity project. The first time around I'd hunted around for a framework - settled on knockout.js, with framework7. Coming back to it after three years was impossible - framework7, in particular, had moved on so much a complete rework was required. And the build process was just ridiculous, and I say this as someone comfortable with makefiles and ant.

So I redid it without any framework at all. No more stupid wrapper div hierarchies with weird naming conventions, no more overarching paradigms that change every few months, no more desperate attempts to build the project without downloading the internet. Just querySelectorAll, addEventListener and careful use of CSS. Result is about 25% of the original size, and what I've got actually looks like JavaScript. It's quite a pleasant language so long as you use it as designed, and not whatever structure your framework-du-jour has imposed.

[J27]

Re: Frameworks are not your friend.

Large project, large team, short deadlines all make the roll your own everything less attractive than picking one of the framework options. Even if it means constantly updating to stay up with the current version.

Not saying the current situation is good, just that these frameworks make a lot of sense for a lot of projects, especially ones that release updates more often than once every 3 years.

[captain veg]

Re: Frameworks are not your friend.

If only people spent as much time actually learning JS as the frameworks, they might then understand that (a) it's no longer difficult to code for all the common browsers using nothing more than the standard DOM methods, and (b) once properly understood, it's a nice compact language and quite fun to use. I actually find it quite painful to go back to writing statically typed code now. Can't imagine why anyone would want to add a tedious and completely unnecessary compilation step to their web development.

-A.

[Anonymous Coward]

A quicker fix.

Shoot javascript through the head. Don't even bother wasting the time to take it out behind the barn just do it in the front yard and leave the corpse as a warning to others.

Javascript is a security nightmare that rapes and pillages our computers. We don't want the virus' and RCE/priveledge escalation/yadda yadda yadda exploit du juor to be rammed down our throats so we turn javascript off to combat it which makes your javascript infested sites complain that we're either running an insecure browser (snort), an incompatible browser, or it's otherwise unsupported. Get bent. You don't get to dictate what we use to access the web - it's your job to make a site that can be accessed by the viewer not to demand the visitor be running version x of browser y on OS z. That would be like a physical store telling potential customers that they have to be wearing only clothing made of all synthetic fibers in non-soy-based dyes and in a narrow range of spectra that only aged half-dead iguanas can discern.

You want us to visit then don't use the tech that actively chases us away. We want security, you want to run javascript, guess where our money goes when you turn us away...

[martinusher]

Re: A quicker fix.

As a programmer it always interests me when some web component crashes and I get a display of the code used to make it (happened just yesterday). Even allowing for the lack of formatting the stuff's unreadable, it seems to be just a collection of object methods and library calls without any underlying 'What/Why/How'. Apparently people get paid good money to write this stuff.

I also regard Javascript as inherently evil. I've got nothing against scripting languages in general or the practice of embedding scripts in web pages but the kinds of contortions that people do in order to get the pages to do things they were never originally designed to do reminds me of the kinds of contortions wannabe programmers did back in the very early days when they were trying to get some version of Rom BASIC to behave like an operating system. As the envelope gets pushed structure and readability suffer -- the most dangerous person in the room is a really clever programmer, they'll invariably know all the tweaks and workarounds and idiosyncracies, amazing stuff that leave everyone with a steamin' pile to maintain, upgrade and generally sort out. Languages that encourage this behavrior need to be neutered.

[Anonymous Coward]

Re: A quicker fix.

Amen. We finally got rid of Flash. Now let's focus on killing Javascript,

[JustJasonThings]

Re: A quicker fix.

<Michael Scott "Thank you" Gif>

[Anonymous Coward]

Re: A quicker fix.

"Javascript is a security nightmare that rapes and pillages our computers."

Not just our computers, our mobile devices as well.

I just discovered a nasty bit of JavaScript served up by CloudFront that uses several different techniques to fingerprint the users browser and if an Android device is detected it sends push notifications that scare the user into installing bogus apps from Google's Play store with fake virus warnings from two advertising networks with a known history of abuse.

The majority of websites that are infected with this malicious script are frequented by young people making it all the more repugnant.

Thank you Raymond Hill for uBlock Origin and uMatrix for saving us from this crap

[Ian 3]

Having spent 20+ years using static typed languages, I'm shifting quite a bit of work to JavaScript, because it isn't static typed. If you want static typing in the browser use typescript (or scala or f#, if you're feeling frisky), if you want it on the server then Kotlin is quite snazzy. Modern Javascript can be beautiful, it just gets horrible abused - but people forget just how truly awful c++ and Java code there is out there. Just keep everything small, beautifully structured and highly functional with lots of tests, and what's not to love?

[Wilhelm Schickhardt]

Security ?

In many if not most cases an insecure browser JS program will not create security issues, as one must trust the server side anyway.

But if you run JS on the servers side, you better have solid defensive measures or you will be hacked sooner or later. Strong typing is one proven security measure.

You can also run Rust on both śerver and client.

[RichardBarrell]

For what it's worth, I wouldn't directly compare Redux with GraphQL: they're not competitors. You might use either or both on a given project.

Redux is a library that holds onto in-memory state on the client. GraphQL is a technology for requesting data over a network.

[Julz]

If

Tempted by Javascript, just say no...