Programming

Also a great disadvantage with JavaScript being the official scripting language of the web so it needs to work in every browser, but not every browser will implement it the same way. Syntax between the browser and servers also gets conflated.

I've done frontend development in Java and it sucks major ass. The "advantage" of using one language for the whole project really ended up as a net negative. For any server-side project I'm totally fine using Java because for all it's verbosity it's secure, performant, and examples from 10 years ago aren't useless.

I'm struggling to understand how there can be so many security flaws, even in things that don't seem to matter for security. I think the bar for a security problem might be too low; a lot of these look like footguns that could give my package a security hole, rather than genuine security flaws in the packages they are reported on.

Here's a progress bar package with a "high" security vulnerability because it contains an internal utility that merges objects and doesn't stop you writing to the prototype. Did the progress bar package ever promise to provide an object merge function that was safe to use on untrusted user input?

Here's a notification UI element that bills using HTML in your notification messages as a feature. It has a "medium" level "XSS" security vulnerability where the message parameter is not sanitized to remove HTML. A CVE was issued for this.

Here's an arbitrary code execution vulnerability in sqlite3! High severity! The bug is that, if you tell sqlite3 to substitute an object into an SQL statement, it will run the ToString() method on the object. If an evil hacker has broken into your lead developer's house and written a malicious ToString() method into one of the classes of object you use as a database query parameter, then that code would run! The fix here was, instead of letting the normal Javascript stringification rules apply, to hardcode all objects to be inserted into the database as "[object Object]", because surely that is what the programmer meant to store.

You’d rather not be aware that a vulnerability has been found since your last development ?

I'd rather develop with dependencies that don't have so many vulnerabilities.

If you set the versions of your dependencies in the package.json file

Or if you leave that alone, and update your package-lick.json so can install exact dependencies with npm ci

I personally don't trust NodeJS libraries that much - I always run projects inside Docker as a regular user with access to the working directory, just in case the supply chain is poisoned.

In the case of Python, particularly when I was testing out the LLaMA model, I just stood up a new VM for that. Back then safetensors wasn't a thing, and the model tensor file format (python pickle-based) could potentially store arbitary code.

Robust standard libraries are amazing to have.

Thank god for proxy registries. I love Node, but it's like using a house of cards as the foundation of a skyscraper.

C# is also exactly the same, you just don’t get yelled at when things are out of date and you only see that if you go to manually install packages

Most of those are server-side languages and I'd disagree with the assessment. For web services Java needs some kind of server like Jetty, Undertow, or Tomcat. For testing you need JUnit or NGTest. And for common, everyday utilities you need something like Apache Commons or Guava. These things don't "ship" with Java (and there's actually a fair amount of runtimes now, it's not only Oracle).

The thing that seems to benefit Java over Node is major corporate support (Oracle, RedHat, IBM) so for better or worse you can usually rely on a handful of essential tools being updated regularly.

This is not universally true. You totally can, especially today.

And these frameworks will fall out of fashion in three days.