Nodebox: A Node.js runtime that runs in any browser
codesandbox.ioWe created JavaScript to run complex code in the web browser.
This worked well, until someone went – hey, we should also use this cool language on the server side. So node.js was born, and it added extra APIs for stuff like filesystem access and web servers that the V8 sandbox didn't allow.
Then someone went – hey, wouldn't it be neat to run all this cool node.js code in the browser? So Nodebox and Webcontainers were born that wrote a compatibility layer and added pollyfills for all the node.js-specific APIs that were missing in V8, and so some of this code was able to run in the browser.
My question is – why couldn't all this code run directly on the browser in the first place without Node.js and Nodebox?
Because this would be too easy?
Modern computers and their software are all Rube Goldberg machines, and we're only adding new parts instead of finally having a critical look at the whole and rethink the monstrosity from the ground up (considering all we know by now, of course).
NodeJS pffft... Netscape livewire was doing JS on the server side in 1996.
What do you mean? Most of Node's APIs are available on the web and vice-versa but they're slightly different, so if you want to run the same code in both places you need some shims.
I don't know how I feel about this.
It is _technically_ cool but I feel like this existing is a definite step backwards with regards to Node.js' lack of modern web APIs.
Software like this relieves pressure in moving from Node.js specific APIs towards standardised web APIs and in addition to that itself boasts about portability by ignoring modern features too. From their WebContainer vs Nodebox FAQ:
Nodebox runs on any browser because it was built from the ground up with cross-browser support in mind, avoiding modern features like SharedArrayBuffer."
So now we've got an escape hatch for Node.js not having to implement modern APIs because software like this implements its runtime for the browser, and also this same software removes pressure on browser vendors bringing their implementations up to webstandard specifications by "... avoiding modern features".
While this is _technically_ cool I feel like it's a lose-lose for the overall ecosystem.
Nodebox is already the name of a long lived creative coding tool, please change the name of this.
>If you have heard about or used Sandpack, you probably know what it’s all about: running any JavaScript application directly in the browser.
I've been a full time JS full stack dev for maybe 8 years, and this sentence doesn't make any sense to me.
Pretty sure it's like webpack but runs in your browser. i.e. a bundler+transpiler.
Usually you have a bundler/transpiler running on the host, with sandpack we moved that step to the browser so you can share a link with anyone and they instantly get a development friendly (JSX, TS, ...) project that works without having to install any tooling. It's also a lot faster than something like webpack as most of the bundling complexities are taken away as sandpack transpiles files on demand without the need for bundling as it also controls code execution. With nodebox we pushed this a bit further by also implementing most of the Node.js standard libraries.
So now we can run the JavaScript interpreter that was built to run outside the browser in the browser instead of JavaScript.
Finally.
(I’m actually kidding and don’t know anything about this project nor use cases. Just thought this was funny)
But... why? I don't understand the benefit or business value of this at all, except for very specific niche cases like CodePen
CodeSandbox is a service similar to CodePen (or StackBlitz which also uses nodejs emulation in the browser).
The benefit is that you can use a web editor with the same dev tools (TypeScript, Babel, vite, webpack, etc) without a server VM. That saves them a lot of money in cloud instances, and speeds up things for the end user.
Other than that a posible niche use case is to emulate a full-stack for prototyping or testing purposes.
Now run a browser version of Wayland so you can run Electron inside the browser. We must go deeper!
Looks like a interesting technology. I am not sure how capable it is, but this might mean, we could essentially have a full NodeJS build env running in the browser without having to have a container running in the background for web IDEs.
However, the complexity of this innovation just makes me want to scream into the void. I don't want to touch the frontend toolchain at all, anymore. The layers of abstraction is seriously hurting my brain.
Rather confusing when here is already:
yeah it was a very cool visualization project. Python had Shoebot
Nodebox is built on Python (Nodebox1 = Python on Mac, Nodebox 3 = Jython) - there are new Nodeboxes on other tech.
Shoebot is not dead (even if it is getting a bit old), currently working on a new release to sort out a bunch of the tech debt.
https://github.com/shoebot/shoebot
For those into Nodebox1, on the Mac, Karsten's fork is active.
https://github.com/karstenw/nodebox-pyobjc
Plot device is a fork that went in a different direction
https://github.com/plotdevice/plotdevice
EDIT: I should also mention drawbot, the progenitor for all of these is pretty alive these days using a Skia backend
https://news.ycombinator.com/item?id=34793858
FYI, stackblitz released something similar called web container.
There’s a section called “Difference with WebContainers” on the announcement
We've gone full circle! Node.js, a javascript engine stolen from browsers, now re-implemented in browsers. But as a serious note, is the value proposition "Less powerful version of Electron without forcing people to download a desktop app"?
I think the target audience would be programmers who don't (want to)/can't install the necessary dev tools onto their system.
I suppose lessening the curl2bashness of many frontend dev tools is also an advantage.
Maybe this is a dumb question, but the "shell" this sets up in which it runs "node" is just some VM in the browser, right? It's not literally executing shell commands or opening ports on the host machine, is it?
Everything nodebox does is scoped to the current browser window, it has no access to any part of the hostmachine, it's not really a vm but actually a new web worker which runs the Node.js code you request. This is heavily relying on the sandboxing browsers do by default and is therefore really secure.
It's very interesting. In that example with the express router, where you're creating `index.js` inside a filesystem inside nodebox, is that whole filesystem just stored by that one webworker? Also, when you invoke express to listen on port 3000 and get back some URL to set the `previewIframe.src`, is that some blob URL returned from the webworker? (in which case how would you set up sockets?) Or is that URL accessible to any other browser tab?
Nice. Stackblitz did this first and this is a killer feature all fiddles now need
CodeSandbox is such a legit engineering org.
I always like to track their progress and this too is impressive, useful work.
My respect for this company runs so deep that I at one point considered approaching them to acquire my own company.
You know what? Fuck it. Just let any program run in the browser, but only if it could rune natively too. The new type of hardware acceleration. Play league of legends in a chrome tab. Just ship it.
the rise of FrontBackend Engineers
// frontbackend engineering tutorial
import React from 'react'; import { UsersService } from './users.service'; import { registerRoute } from 'react-backend-router';
export class UsersController extends React.Component {
constructor(props) { super(props);
}this.state = { createUserPayload: null, updateUserPayload: null } this.createUser = this.createUser.bind(this); this.updateUser = this.updateUser.bind(this); } componentDidMount() { registerRoute({ path: '/users', method: 'POST', handler: this.createUser }); registerRoute({ path: '/users', method: 'PUT', handler: this.updateUser }); } createUser() { const { req } = this.props; const { body } = req; this.setState({ createUserPayload: { name: body.name } }); } updateUser() { const { req } = this.props; const { body } = req; this.setState({ updateUserPayload: { name: body.name } });render() { const { createUserPayload, updateUserPayload } = this.state;
return ( <UsersService create={createUserPayload} update={updateUserPayload} /> ) } }
A counter project to Stackblitz's web-containers?