NodeOS – A Node.js Operating System(node-os.com)
node-os.com
NodeOS – A Node.js Operating System
https://node-os.com/
81 comments
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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’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.
As much as I love JS on web and backend via Node, I really hate desktop apps in Electron.
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.
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.
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.
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.
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 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 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>
<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.
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.
[deleted]
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...
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.
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 ?
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.
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.
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.
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.
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.
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?
He's probably this cynical because he's actually worked with Javascript before.
>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?
This is interesting, in the light of recent supply chain attacks on npm. How safe is a npm-based OS?
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.
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.
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.
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.
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
NodeOS 0.04
Your welcome
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
curious if there is practical use for this kind of systems
Yes. Lisp Machine [1].
[1]: https://en.wikipedia.org/wiki/Lisp_machine
[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
> 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.
[deleted]
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.
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)