Curious to know if anyone has experimented with running Node-RED on Deno or Bun and conducted a comparative analysis?
Bun 1.0 “should be” a drop in replacement for node/npm, I wonder if it gains traction.
I did take a quick look at Deno a few months back but it doesn't seem to be all that compatible with Node.js and so it didn't look as though you could simply switch.
Deno is specifically designed to fix a number of perceived issues with Node.js and so is unlikely to ever be compatible.
Neither approach has any real widespread community support and without the many thousands of support libraries available to Node.js along with the strong integration of npm, Node-RED and its own community of thousands of extensions, would take a massive effort of hundreds of people several years to change.
This is the same issue Node-RED has with trying to switch over to ESM from CommonJS. The node.js designers/devs really messed up here making it nigh-on impossible to do a phased migration from one to the other.
This page reports their compatibility with node.js. Summary - lots of good work done, but a lot still to do.
year or 2 ago, I made a handful of modifications to Node-RED and successfully ran it up in ESM. Unfortunately, a new job and 2 computers since, I can no longer find that branch
Deno announced NPM support in the last week - but it isn't through require
/commonjs (so lots of rework)
Bun does look promising tho.
I tested Node-RED about 3 weeks ago, it started loading, looked good, then just froze - likely due to one of the missing items - but it is getting close However, my thoughts wander to "once it has enough of nodejs to be compatible, will it end up losing the thing they are touting - speed"?
Oops!
Well, we will need to revisit at some point I fully expect since more projects are already switching to ESM-only. That is already a pain for uibuilder since it knocks down the review score because there are a couple of utility libraries I can no longer upgrade. Even moving to dynamic includes isn't easy since you seem to end up having to rewrite everything as async from the top-down once you start on that route. And, of course, you also then have to wrap everything in another pointless layer to avoid the lack of top-level async.
Any ideas you might have on easing the path would certainly be welcome.
For anything that I'm publishing now that is either browser-based (such as the uibuilder front-end library) or pure Node.js usable, I'll be publishing in all formats. With grateful thanks to the esbuild
tool which makes things very easy indeed.
This is what bun has solved - transpiling & bundling is done natively, you can use native js, ts(x), modules, commonjs all within the same project, no more need for doing all kinds of scaffolding and tooling it just transpiles and bundles natively and supposedly much faster than alternatives while doing hot reloading, it sounds quite impressive. See the announcement from the weekend.
Very interesting and I got quite excited until I got to this part:
Bun is built using Apple's WebKit engine. WebKit is the engine that powers Safari and is used by billions of devices every day. It's fast, efficient, and has been battle-tested for decades.
Which should be fine except that, if you know anything about Apple, their browser is the Internet Explorer of the modern age! For good or ill, V8 now powers the majority of the Internet (between the majority of browsers and node.js) so not so convinced that using webkit will be the best experience and sadly may hinder adoption of Bun. We will have to see I suppose.
You can even use
import
andrequire()
, in the same file. It just works.
This is what node.js should have done and I've no idea what the node.js devs were thinking when they didn't do this (well, they clearly weren't thinking).
You can run Bun with
--hot
to enable hot reloading
That is massive for anyone doing the typical JavaScript approach to programming e.g. write and pray.
If Node-RED were to be able to run under Bun, it would make custom node development sooooo very much easier and quicker.
Bun provides native builds for macOS and Linux, but there's been one notable absence: Windows.
Another negative and now we understand why they used webkit instead of v8 like everyone else - they are Mac native devs. Apple through and through. At least they've started work on a Windows version though, that's something.
Certainly one to keep an eye on. If nothing else, maybe it will force the node.js devs to smarten their act.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.