NodeOS – A Node.js Operating System | Hacker News Reader

NodeOS – A Node.js Operating System

node-os.com

55 pointsrevskill76 comments

It looks dead. I think they chose the wrong approach in lots of ways, but it wasn't that far from a JS (and Typescript) based OS on top of Linux that is actually a good idea.

ChromeOS is kind of close to what I'd want, if you could remove Google from it. (I actually like ChromeOS, nearly perfect for my kid's computer)

Firefox OS was also kind of close, but they missed in a lot of ways.

Here are the features of some OS I wish existed:

Open source and not primarily controlled by Apple or Google or Microsoft of Facebook or whatever.

JS and Typescript are essentially native and are the primary ways of building apps, but WASM would be available if you need machine code.

The same JS engine runs in the browser as for running applications. The same rendering engine works inside the browser and to render "native" apps that do any drawing to the screen. Preferably, you could choose to run on one of several browser engines

Most apps that run as native apps can, without much extra work, run as web apps, and vice versa.

The UI isn't built on a framework that might fall in popularity. So not React or Angular or Vue or whatever. If people want to use those in their apps, they are there, but core stuff for the UI avoids relying on them.

That's all I can think of for now. Beyond "design it really, really well and make a slick feeling but non-limiting front end experience." Which is hard.

(sorry to those with unbridled hate for JS and even Typescript)

We’ve seen how Electron performs. The only reason VSC doesn’t totally suck is because a lot of it is still native code. I can’t even imagine how crappy it would be building an entire OS out of that stuff.

And you’re never going to escape the needs for another systems language because unless you find a way of writing non-memory managed code with pointers and inlined assembly in JavaScript, that language simply isn’t going to cut it. And on top of that you’d need a compiler that can compile machine code just to bootstrap node in the first place.

I’m all for experimental operating systems but there’s a reason systems languages differ in design to web scripting languages and really we should be using the languages that suit each domain the best rather than simply putting JavaScript everywhere because we are too lazy to learn anything else.

There's very little native code in VS code: https://github.com/microsoft/vscode It's all typescript, even the main editor component monaco. You might be thinking of the atom editor which tried to do more native code for speed of editing but AFAIK atom has kind of been shelved and not developed anymore.

The search engine is ripgrep, written in Rust, and VSCode makes heavy use of WebGL, e.g. terminal.

You should have gone through https://github.com/microsoft/vscode/blob/main/package.json instead of main repo.

No idea why you’re getting downvoted.

Search, language server engines, even code reformatting, all the stuff that really separates VSC is an external executable and thus not part of Electron.

If any of these fanboys spent even 5 minutes looking at the config of VSC (never mind the source) they’d see just how many references to other binaries there are.

LSP servers and code formatters are often written in JS.

Sometimes sure; but not “often”. The ones that work against JavaScript are probably written in JavaScript however none of the ones I use commonly are.

And it performs exactly according to that statement. Slow as hell. I can’t bare it’s input lag when typing.

It’s a horrible text editor. Maybe a nice IDE but horrible editor.

It's not really an IDE either, as it needs a lot of stuff bolted on to have even partial IDE functionality.

It's a shittier, more bloated Emacs.

Strange, since I find a ton of devs say the slowness is justified since vscode has IDE fucntionality.

I’ve recently got back onto Java project after few years and Intellij feels crazy fast whan compared to VS Code. And it has 2x IDE functionalities built in.

As much as I love JS on web and backend via Node, I really hate desktop apps in Electron.

Its people arguing silly semantics. VSCode is an IDE, features are organized by extensions. Intellij's products work the same.

> VSCode is an IDE, features are organized by extensions. Intellij's products work the same.

The important bit here probably has something to do with first party vs third party extensions when talking about the IDE functionality. Also, what's included in the base install is also important if you want to talk about using either as a text editor.

For example, have a look at JetBrains products: https://www.jetbrains.com/products/

Lots of different IDEs (and nowadays other tools too) for different tech stacks, although all of them are based on pretty similar tech/platform. E.g. if you install a few plugins, you can get parts of the WebStorm functionality in PhpStorm or IntelliJ or whatever, even if it might not necessarily be 100% the same. Some other IDEs out there also follow this approach, providing first party support for certain modules, like Eclipse also has similar packages (installable for free in the base product, though) https://www.eclipse.org/jdt/

In contrast VSC has an extension manager that has both first party and third party extensions available and doesn't necessarily pigeonhole you as much towards a particular extension, even though in practice you might still just go for whatever is recommended, which in many cases will be the most popular (and by proxy, most well supported) extension available for whatever it is that you need. However, the downside of this is more fragmentation and having more difficulty in ensuring consistent behaviour, since what's included in IntelliJ and Eclipse JDT is probably a bit better known than what your unique install of VSC will have.

However, at the same time, Eclipse, JetBrains products (all of them) and even other IDEs like NetBeans all fail at the text editor use case. Want to edit an .ini/.env/.yaml/.json file really quickly? Unless you have the IDE already open, the startup will be slow and cumbersome, whereas VSC wins for such use cases hands down. For example, in situations where i have a Git repo with some Ansible scripts, or some GitLab CI stuff for DevOps, i would almost never reach for anything apart from VSC (Notepad++ or other native editors on other platforms are also okay, though VSC is surprisingly consistent most of the time).

Thus, VSC can be a text editor, it can (mostly) be an IDE, though for specific tech stacks and codebases of certain complexity, it will fall behind both VS and JetBrains products, maybe even Eclipse, NetBeans etc. For example, in IntelliJ i can apply a whole plethora of code inspections, there are lots of helpful hints and fix suggestions for popular frameworks (like Spring/Spring Boot/Jakarta) alongside pretty smart autocomplete. Not only that but i can do refactoring across the entire codebase of thousands of files and hundreds of thousands of lines of code with a lot of confidence about the end result. I doubt that i'd be able to work on some of the enterprise stuff that IntelliJ makes easy to reason about in any other editor, at least so successfully - NetBeans straight up crashes when i try to open 30 files and do refactoring, whereas VSC Java plugin felt a tad rudimentary when i last checked (even though that was a while ago).

In summary, it's definitely not just semantics in my view, each tool has its strengths and drawbacks - in practice you might use both for different use cases and have a pleasant time thanks to that.

I personally don't understand this complaint. I use VSCodium on a daily basis with numerous extensions, and it is far faster than Atom. Yes it doesn't have the speed of properly configured emacs but I've also had emacs configs that take longer to load than codium. Codium is more than snappy enough with my build out to do all of my work effectively, I don't notice any typing lag at all

If you compare it to Atom, then yes, it’s fast. But compare it to anything native and it’s unusable. I’m using Sublime and switching to VS code hurts my brain. It just feels wrong. You can feel that there’s some time between pressing a key and character showing.

VSCode literally runs in the browser with identical performance to the Electron app (because aside from some differences in APIs, the runtime is pretty much the same). Try GitHub Codespaces and you'll see.

A subset of it runs on the browser, it is also how it all started anyway, with the Monaco editor project.

No, it's exactly the same as the "native" app (API differences aside, as I mentioned). Have you tried GitHub Codespaces?

One common marketing gimmick within the JavaScript community is to brand your project "lightweight", just like this project. JavaScripter’s desperately search for that because their ecosystem is the total opposite.

Total collapse? Ha, thanks for the laugh. Snark aside, it’s nowhere near total collapse. It’s not without its problems of course but things are relatively fine compared to other package management solutions in use with other languages.

Either GP edited, or you misread. GP says "total opposite" not "total collapse"

It always said total opposite. You can only edit messages for 2 hours and there is a 4 hour gap between the opposite comment and collapse reply.

It said total collapse or else I wouldn’t have said as such. It was such hyperbole that I had to respond.

No, I wrote total opposite. Nothing else. Never changed it.

I wrote about the overuse of "lightweight" in the JavaScript community and just that fact that building an OS on top of npm can hardly be classified as "lightweight", thus logically npm is the opposite of lightweight, bloated.

Why would I write total collapse when contrasting lightweight? Doesn’t make any sense.

You misread. That happens, I do that too time to time. But own it when it happens.

I read it as “total opposite” and unless the GP has found a way of rewriting both my memory and bypassing HNs automatic hard limit of a 2 hour edit window, I’d say the error is yours.

Plus total collapse doesn’t even make sense given the context of post whereas total opposite does. So that alone should have prompted you to re-read their post.

I believe an OS based on WASM could have merit. For WASM, there is the AssemblyScript language, which was inspired by TypeScript but runs faster because it avoid the complexity of JavaScript runtimes.

<https://www.assemblyscript.org>, <https://leanylabs.com/blog/assemblyscript-intro>

an OS based on WASM could have merit

Came here to say this. Beyond Rust and AssemblyScript, there are quite a few other programming languages that target WASM, meaning that WASM is a good candidate for that holy grail, the unified environment where you can write your stuff in 'any' language and re-use and talk to stuff written in 'any' language without relying on relatively clunky, type-challenged and slow IPC.

Deno plus Tauri is getting increasingly close to this.

Could you just build this OS as a web app?

> The UI isn't built on a framework that might fall in popularity. So not React or Angular or Vue or whatever.

So what exactly has better long term popularity than React/Vue/Angular? We're at about 5+ years of those being the big three...

Why, god, why the heck are you having Node.js to take over every front facing thing.

This is 100% despicable. I thought my own imagined PowerShell based Linux Distro would be insidious enough, but this, this is an absolute, pure evil.

Because of sharing.

Write your function once then u can import to use it everywhere, from server to frontend, mobile or desktop app. Why reinventing the wheel ?

But it somehow reached the "everywhere" status first...

We have a project which's converted into a monorepo due to need of syncing and sharing.

Imaging you have a web app and a mobile app, when the web app has changes, u need to sync changes to mobile app as well. What's the best way to do it ?

Besides javascript, i can't know a better way then. Our team has only 2 devs working on all server, web and mobile appp.

This is certainly sensible. My point was that IMHO it is unfortunate that it is JavaScript that has risen to be this single language.

If there are only two people in your dev team then you absolutely wouldn’t be writing OS components as well as web apps regardless of the languages natively supported by the OS.

Oh yea let's build an OS where we can just import our kernel-mode drivers from the repository of quality code that is NPM. I mean what could possibly go wrong, right?

I'm sorry but we need less NodeJS and JavaScript in this world, not more.

You're just picking something to hate and it's not even correct.

It's not true that OS==kernel. The kernel is Linux, and this is replacing the GNU stuff around it with something else. The result is a new kind of OS. But nobody said that any privileged code will be written in JS.

Java tried this a while ago. "Compile once, debug everywhere."

The project isn't dead, their Webpack builds just now take 4 years.

Imagine promoting thousands of vulnerable non-trustworthy npm packages to first class citizens on your OS xD

That was one of my first thoughts too. Hilarious stuff

Calendar breaks because dependency for checking leap year is also somehow tied to is-odd/is-even

Subtitle to the OS name should be: "I don't need those CPU cycles anyways" or maybe "because the cancer of JS has not spread enough already."

Why do you need to be so aggressive?

Keeps you young, healthy and your skin smooth.

And fun at parties as well I guess

He's probably this cynical because he's actually worked with Javascript before.

Yeah when I was an ITSM consultant. ServiceNow uses JS extensively. Those were the ECMA 4 and ECMA 5 times to be honest though. I guess a lot has changed since then.

Unfortunately not a lot has changed since then in ServiceNow’s JavaScript situation. Still stuck on ES5 Rhino.

>The first operating system powered by node.js and npm

This is interesting, in the light of recent supply chain attacks on npm. How safe is a npm-based OS?

I'd be curious to learn what kinds of safeguards various package managers of Linux distros have employed against supply chain attacks on individual maintainers who might try to poison certain popular packages if compromised?

Specifically, I'd imagine NPM might actually be a bit better than many distro's package repos due to the post left-pad era changes they put in place to make packages more... immutable and tamper-resistant, so the only way for a new malicious package to reach users is for those users to actually explicitly update to the new malicious versions. But being not even remotely familiar with how Linux package repos are updated/maintained, I'm probably missing a lot of nuance.

Seems feasible to create a limited mirror of NPM with only hand-audited packages (and versions). At that point it's not really different from the repositories managed by OS maintainers.

From the title I thought this would be a whole OS (scheduler etc) but the homepage makes it look more like it's just a js shell?

Ain't linux gnome shell basicly css and javascript

The frontend of Gnome shell at least. The API that the JavaScript consumes is still low level.

My experience with Gnome shell is that third party extension, written in JavaScript, is often leaky and leads to massive slowdowns in the desktop and requires a restart of gnome shell at least once a day. Which leads to the conclusion not to use third party extensions, thus removing the benefit of having a scriptable shell.

This seems relevant: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Why some people don't add some screenshots in their projects?

# uname -a

NodeOS 0.04

Your welcome

Why?

Why not ?

I think this link should actually go here: https://github.com/NodeOS/NodeOS/issues/441

reminds me of quote "everything that can be written in js will be written in js"

curious if there is practical use for this kind of systems

Yes. Lisp Machine [1].

[1]: https://en.wikipedia.org/wiki/Lisp_machine

"The website has been blocked as per order of Ministry of Electronics and Information Technology under IT Act, 2000."

I'm interested in making a user interface for the OS with electron

Seeing that, a javaos instantly looks not that bad anymore ;)

I was expecting a kernel written in Javascript

This is dead

This comment seems correct. No commits in years [0], but more telling is issue #441 [1]:

> Q: Is nodeOS an abandonned project?

> A: Unluckily, sort of. I've tried sometimes to retake it, but work has absorved me so much that don't have time to engage on long-term side projects, and size of NodeOS itself give me a lot of respect. Obviously this has not been the only problem, I failed to communicate and delegate some work to the community, although they were willing to do so. If only I could get some extra motivation to retake it, like some funds or something, or at least to focus myself on the project and get over to my fears... :-/

So, it seems that it's stalled and with some love it might be able to be resurrected. But even the issue report is over 1 year old.

[0] https://github.com/NodeOS/NodeOS

[1] https://github.com/NodeOS/NodeOS/issues/441

edit: formatting

Interesting reply from the lead. Very honest.

One could argue that it should have never lived.

That is not dead which can eternal lie, for with strange eons, even death may die.

SCNR

hey, congrats on launching this! what made you want to build it?

And if you get one node polluted whole thing go down. Great move.

Wish the devs all the best and a soonest release from the mental institution.

Reply on news.ycombinator.com