Node.js 15: What's new, what's coming, and keeping pace with Deno. 'We're not going to reinvent' module ecosystem Popular open-source JavaScript runtime Node.js hit version 15 last week, and to bring us up to date we spoke to Michael Dawson, Red Hat Node.js lead, who is also chair of the Node.js Technical Steering Committee and Community Director of the OpenJS Foundation. So what's new in Node.js 15? One thing is what happens when an …
True words. Companies need to stop developers from just referring to GitHub. Take that library in-house, examine it, test it and then put it in production from your own server. When there's an update, check to see if it brings you anything. If it does, then you put it in your test environment and start over.
There is not one line of code in a production environment that should not be known and vetted.
"There is not one line of code in a production environment that should not be known and vetted."
You'll hate NPM then as NPM is utterly full of dependency chains. Check out http://expressjs.com/ sometime. It's full of so many shit dependencies you'll never be able to get through vetting, it's just not realistic. I feel the article should of asked how security is enforced on these larger NPM's that are full of bloat and who has vetted them. That is far more important than who's using cgroups or not.
Also, I'll never understand why Node uses meta fields with NPM, is it hard to just read the release and license information (which you should be doing anyways)? If you really need a meta field to decide whether or not a software package will work, what does that say about what Node has impressed upon its users? Have you ever found someone who's like "FAST, we need a web server, DAMN! .. if only we could sort by meta !!!!"......... ?.
Thanks for this piece.
It is reassuring to know that, regardless of whether you agree with the decisions that are being taken, at least there is a proper process that balances the different considerations at play. We will always disagree on the relative weight those considerations should have, but that's how it is.
I did not understand much what happens in the case of an unhandled promise rejection. It used to print out a warning to the console by default and then keep running, though in production I have it quit. Is that the new default? What I would appreciate is better debugging info to help track down the offending rejection, that can be a bit of a pain sometimes.
Nope, I certainly can't explain that...
I think it's utter madness but there's plenty of folks who seem to love it.
The only real argument I've heard in defence of doing this is that it means that developers can write the full stack code in the same language.
Personally I find the utterly massive number of cascading dependencies pulled in by npm to be quite terrifying.
It's quite cool that it does an analysis of known CVEs when you're installing a module.
I suppose if I were to say something positive about JavaScript - they do at least work hard to improve it and the ECMA Script of today isn't quite as bad as the old hag we all wanted to take round the back a few years ago.
I'd still rather develop the back end in just about anything else though.
I don't think it is utter madness.
When node showed up it won a lot of devs who already knew the JS from the front-end as it allowed them to do break free from all the cruft that java projects imply. It was fresh, simpler way to build backends.
You need dozens of files of both code and configuration to build say an API in java versus a few lines of js if you're using node and for example expressjs. This is powerful.
You don't have to type 20 times the word "int" to pass an integer into functions. You dont have to fight with complex build systems. No need to create 5 classes which are just passing an employee record around.
Just write a few functions in a couple of files and and run it. That's the beauty of the js.
Sure there are other languages with the same advantages but if you already know js you just use what you know versus going to learn something different (or hire another person if you're a manager)
On top of that, JS while it has its quirks, like any other language, it is not as bad as it was and it does have awesome features for many projects. For example, promises and callbacks can be tricky but they're infinitely easier than dealing with mutexes and race conditions in multi threaded server environments.
I speak as someone who's built APIs in java, js and python.
So when everything is considered (cost, team skills, etc.), using js/node is actually the right answer from an engineering perspective, for a lot of projects. Not all, of course.
I agree though that the js ecosystem is a bit crazy as there are too many options (esp for front end is frameworks)..
You think it's crappy. Other people love it. You think a compiler should stop if it spots a type error. Other people would like a warning and if they look at the code and they know it'll run ok they want it to compile.
Putting it on a server was a good idea because it allowed devs who knew the client to move to the server.
Langauge snobs are just snobs. Shit code exists in all languages. All the buffer overflow vulnerabilities of the last 20 years come from C and C++ code. It doesn't matter what it's written in, what matters is that it does what it's supposed to do reliably and provably.
You can test JS just as thoroughly as any other language.
Other people would like a warning and if they look at the code and they know it'll run ok they want it to compile.
"compile"? You mean "lint"?
I prefer languages that at least tries to steer developers the right way. A lot of crap can be caught by a half-decent compiler. I would hesitate to replace a compiler with additional unit tests.
const a = ["2", "1", "3"]
i = 1.5
console.log(a[i])
TypeScript helps, but when the foundation is shaky... I get the feeling that many companies hire entry-level developers, set them up with subpar tools and then hope for the best. For products that are meant to live more than a handful years, this is a very expensive way of running things.
I find JS useful for scripting - both are interpreted. Shell (bash) script complexity increases exponentially with length of script- starting from there being only 255 error values, the difficulty of returning values from sub shells and error handling. Making a system call from JS requires a constant few times more characters than calling from a shell script, but complexity doesn't increase nearly as fast as the script gets longer. JS also has many OS functions of its own to replace system calls.
JS shines when -a priori- only a single thread is needed, there is not a lot heavy duty computation (or that is delegated), and there are a lot of logically independent "lvirtual" threads which are sitting around blocking on i/o most of the time. With promises, pipes, and a good automated scheduler for the "virtual" threads (all interleaved in the same real thread). Yes, a garbage collector can misbehave, bust just as it is possible in C/C++ to write code without memory leaks by following clean design and some basic rules, the JS garbage collector be reliable if the code follows clean design and some basic rules. If the JS performance is sufficient for the task than it has won because it far faster to develop with than C/C++.
On the other hand, JS is slow starting new "real" threads and that can't be fixed. C/C++ shines there. With JS, true parallelism must use system messaging between long term threads.
Also, the ad hoc nature of JS' evolution has resulted in some ugly JS-special syntactical warts and potholes that can't be removed. That's OK if you just turn the lights off to get the job done.
Supporting TypeScript at runtime is just encouraging more runtime bloat.
npm packages are a mess. It's not uncommon for 95% a package's footprint to be unit tests, documentation, or other crap someone decided to publish, but serve no runtime purpose. On top of that, files are loose on the file system, causing more waste due to slack space.
If you're going to fix the mistakes of node.js, look at what java did right 25 years ago. Support optionally running packages from an archive, and have developers publish their runtime separately from their SDK (source code, etc.).
When I read "an application that has been stable for years might now fall over" it just reminds me of the *KINDS* of unintended consequences these "developers" (with real-world blinders firmly in place) "feature creep" into things that have a large user base, only to "not give a crap" when things ULTIMATELY DO FALL OVER.
This is why I will *NEVER* do an application that depends on "the latest bleeding edge version" of something *LIKE* Node.js
We have seen this sort of thing from dependent libs at least a FEW times, particularly when developers capriciously "decide" to withdraw their content, out of spite or malicious intent, doesn't matter, same result.
The C language was originally set up to fail gracefully, which is a major reason why it's ideal for kernel development. In a typical kernel "thing" you already test for error conditions BEFORE you work with something. You force unused pointers and structures to a default state (typically 0 or NULL), and check for it at specific points where it matters. Errors become something you TEST for, and NOT something that CRASHES things.
Back in the day, the FRUSTRATION of a single line of code ending your run in "?Something error at line 500" is what (most likely) drove this feature in C. Also consider the "Unhandled Application Exception" box in Windows versions before 3.1 . That infamous UAE caused SO much frustration, it HAD to be dealt with.
Now Node.js has its OWN version of "Unhandled Application Exception" simply because what was once a warning that COULD BE IGNORED, is *NOW* a FATAL END OF THE UNIVERSE *ERROR*.
Thanks for that, Node.js "developers".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
