Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebContainers: Run Node.js natively in the browser

blog.stackblitz.com

Post reply on HN
Print view View original

111–120 of 238 posts

Re: WebContainers: Run Node.js natively in the browser

#111

Post by ridiculous_fish »

Epskampie wrote: post #40
oolonthegreat wrote: post #34

totally lost newbie here: but what is the difference between running javascript on the browser and running node.js on the browser?

This is going full inception mode. Nodejs is compiled to wasm (like assembly for your browser), and then loaded inside the browser, which can then run javascript. So a full JS engine is loaded, completely separate from the built-in one.

node uses v8. Is the idea that v8 is being compiled to wasm? That seems implausible though it would be amazing if true. Or is there another engine?

My assumption was that the node APIs are simply being exposed to v8.

Re: WebContainers: Run Node.js natively in the browser

#112

Post by dfabulich »

emteycz wrote: post #98
brabel wrote: post #82

Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! Jokes aside: this is actually quite interesting, the demo is very impressive (except for the "onl…

I think the issue isn't with Wasm support, it's the filesystem API. They could've included a polyfill though... But as that API is new it might not be available yet.

It's the "File System Access API," the one that allows the browser to read/write files on your actual computer. It's an I/O feature, impossible to polyfill.

The similarly named "FileSystem API" gives you access to a sandboxed "virtual drive" in the browser. Firefox has supported that for years, and polyfills are possible, but it's irrelevant in this case.

https://caniuse.com/?search=file%20system

Re: WebContainers: Run Node.js natively in the browser

#113

Post by ericmsimons »

jeroenhd wrote: post #86

"StackBlitz v2 Beta currently works in Chrome and Chromium-based browsers. We’re hoping to add support for more browsers as they implement the necessary Web Platform features." Pretty useless, then. What features are missing? As far as I know Firefox was one of the major contributors to pushing WebASM to the web and has a superior WASM engine in many aspects. I'd be more interested in a post about what WebASM feature…

Copy+pasting my answer from existing comment:

It works in Firefox today (minor issues keeping it feature flagged for now) and Safari is close to shipping WASM Threads, so this will likely work on all major browsers by EOY.

Re: WebContainers: Run Node.js natively in the browser

#114

Post by bryanrasmussen »

brabel wrote: post #82

Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! Jokes aside: this is actually quite interesting, the demo is very impressive (except for the "onl…

>JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS!

I remember back when SOAP still had the upperhand against REST but just barely the W3C published a document where they showed how you could implement HTTP over SOAP to basically mass ridicule. Unfortunately can't find it anymore, but it was pretty funny.

Re: WebContainers: Run Node.js natively in the browser

#115

Post by bestest »

frankenst1 wrote: post #81

I assume you still can't use UDP or bind to TCP sockets that are accessible outside of the browser?

Quoting https://github.com/stackblitz/webcontainer-core: > We're limited by the browser's ability to make network requests, so connecting to processes like MongoDB, Redis, PostgreSQL, etc. are not currently possible

Re: WebContainers: Run Node.js natively in the browser

#116

Post by dmitriid »

dfabulich wrote: post #105
jeroenhd wrote: post #86

"StackBlitz v2 Beta currently works in Chrome and Chromium-based browsers. We’re hoping to add support for more browsers as they implement the necessary Web Platform features." Pretty useless, then. What features are missing? As far as I know Firefox was one of the major contributors to pushing WebASM to the web and has a superior WASM engine in many aspects. I'd be more interested in a post about what WebASM feature…

It looks like the problem isn't WASM features, but web I/O APIs, like the File System Access API.

Many of the more "advanced APIs" are unlikely to be shipped in either Firefox or Safari because of security and privacy concerns.

For example, Chrome released File System Access by defaul tin Chrome 86, on October 6, 2020.

And yet, as late as August 2020 they were saying that they'd just got the spec in shape: https://github.com/mozilla/standards-positions/issues/154#is.... And there are still unresolved issues around actual security of the thing (that Chrome happily ignores).

The "spec" itself lists 13 issues: https://wicg.github.io/file-system-access/

And Safari won't implement it: https://lists.webkit.org/pipermail/webkit-dev/2020-August/03...

Re: WebContainers: Run Node.js natively in the browser

#118

Post by dfabulich »

brabel wrote: post #82

Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! Jokes aside: this is actually quite interesting, the demo is very impressive (except for the "onl…

> Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web.

https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...

> WebAssembly is a different language from JavaScript, but it is not intended as a replacement. Instead, it is designed to complement and work alongside JavaScript, allowing web developers to take advantage of both languages' strong points

"Not intended as a replacement"

WASM is a math coprocessor for JS. WASM can't even talk to the DOM API directly (which is the API you use to build web pages in JS); you have to write JavaScript glue code for any/all I/O in WASM.

Re: WebContainers: Run Node.js natively in the browser

#119

Post by slver »

dfabulich wrote: post #118
brabel wrote: post #82

Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! Jokes aside: this is actually quite interesting, the demo is very impressive (except for the "onl…

> Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... > WebAssembly is a different language from JavaScript, but it is not intended as a replacement. Instead, it is designed to complement and work alongside JavaScript, allowing web developers to take…

> WASM can't even talk to the DOM API directly

For now. It's planned.

Re: WebContainers: Run Node.js natively in the browser

#120

Post by slver »

jrockway wrote: post #109
brabel wrote: post #82

Everyone thought WASM would enable developers to write code in any language they wanted (with type checking and higher performance) and deploy it on the web. JS Developers come in: so we can compile node.js to WASM and run that in the browser?! Yay!! Now we can have backend JS running in the browser alongside browser JS! Jokes aside: this is actually quite interesting, the demo is very impressive (except for the "onl…

Browser Javascript suffers from not producing a single "binary" as its build system output. You do get one bundle, but none of the parts know anything about each other, and it limits the ability to optimize. (It is a lot more like the C preprocessor, rather than a C compiler.) Methods that can't possibly ever be called end up being sent to each user, for no reason other than "well someone could write an eval() that n…

Tree shaking works poorly, but is also thankfully not that important, unless you're terrible with managing dependencies.

Why? Because the initial parser is relatively cheap. This makes all of the code available, even if a stray eval() calls something unexpected.

The real resource expense comes when it's time to JIT a hotspot. But a hotspot is by definition code you use for sure. And code you use a lot.

JS engines use tracing JIT. Tracing allows JIT compilers to see how code runs in practice, and compile THAT to machine language. How it's organized on the file system etc is entirely irrelevant.

So basically in a trace JIT system, code that isn't hot is interpreted, and code that is hot is JIT-ted (and code that's very hot, gets JIT-ted with higher optimization).

Interpreting is the new "tree shaking". It saves the compiler a lot of work, but also it won't crash your app (unlike bad tree shaking).

Post reply on HN