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

91–100 of 238 posts

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

#91

Post by nailer »

stephenbuilds wrote: post #49
ericmsimons wrote: post #2

Hi all- CEO of StackBlitz/author of this blog post here. Happy to answer any questions! (Also, thanks for posting this bpierre!)

First, congratulations! This is an astonishing advancement. I found this on the GH repo: "Is this open source? Today no, but the API will be open source to developers at GA." I'm confused by what "the API" is, exactly. Is WebContainers a technology you plan to make available for others to use node, in the browser, in their own apps?

> "Is this open source? Today no, but the API will be open source to developers at GA."

If they make it Open Source, Microsoft will add it to VScode and eat their lunch.

If they don't, developers might be afraid of lock in.

Best exit for them is to just grow users and not make a decision either way until they get acquired by Github (aka Microsoft) and folded into VScode.

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

#92

Post by bouh »

ericmsimons wrote: post #2

Hi all- CEO of StackBlitz/author of this blog post here. Happy to answer any questions! (Also, thanks for posting this bpierre!)

hey very nice work !

do you think that a docker.js running containers in the browser is something that could become a reality soon if we follow you line of work ?

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

#93

Post by pantelisk »

kevingadd wrote: post #83
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…

Typically when you see stuff like this be Chromium-only, it's because Chromium has a bunch of non-standard/one-vendor-only stuff enabled in production builds and neither Firefox or Safari have it enabled (or implemented at all). A few examples include Bluetooth, MIDI and USB.

I don't understand why you are downvoted. Filesystem access is another big one! Chrome has the technological advantage and sports an enormous kitchen sink of features. One has to make the hard decision, work on a concept that will work only on one browser, try to cut corners with graceful (or crippling) degradation, or wait potentially a long time until a spec is standardized and implemented. The latter may result in others hitting the market sooner, so it is understandable why we end up with web-apps that function in a single browser only. Hopefully this improves in the future.

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

#94

Post by emteycz »

dheera wrote: post #78
emteycz wrote: post #77

Earlier quoted context omitted.

Names don't have any such requirements - but we should use them correctly. You don't rename Windows even though it's not a hole in the wall stuffed with glass.

It's just irksome. I don't think Windows is a good analogy. More like if I called the OS "Windows.jpg". If you're going to use something that looks like a filename as a product name, then make sure that file actually exists and is in the expected format. D3.js --> good Angular.js --> good Node.js --> bad python3.py --> bad Windows.jpg --> bad Windows.exe --> okay (I don't use windows but I assume there's something of…

I agree it's not a great name - but IMHO using names incorrectly is even worse than bad naming.

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

#96

Post by drew-y »

ericmsimons wrote: post #2

Hi all- CEO of StackBlitz/author of this blog post here. Happy to answer any questions! (Also, thanks for posting this bpierre!)

Can you expand on the capabilities of the terminal? What sort of operations can be done from the terminal?

It looks like the shell is JSH. Is this an in house shell? Is there any more information on it?

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

#97

Post by ampeter »

apignotti wrote: post #52

As far as I understand JS code is being run natively in the browser. Node has been hooked to the native engine, so V8 is not involved. At LeaningTech we have since several months been able to run nodejs, but also python and ruby using our Wasm based x86 VM (CheerpX), the demo is available here: https://repl.leaningtech.com/?nodejs With our solution the full Linux x86 binary of nodejs is running including the whole of…

> As far as I understand JS code is being run natively in the browser. Node has been hooked to the native engine, so V8 is not involved.

What is the "native engine" if not v8?

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

#98

Post by emteycz »

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.

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

#100

Post by tesnirnat »

throwaway284534 wrote: post #61

I used to teach web development and was always frustrated with just how much effort went into setting up a machine. It would be really nice if a developer could just include a script tag in their project that setup a TypeScript compiler inside service worker. I managed to get the basics down, even fixing relative import statements. Requests like localhost:3000/main.tsx would compile and cache on the fly. There were a…

How did you end up doing this? Do you mind sharing?
Post reply on HN