[HN Gopher] WebContainers: Run Node.js natively in the browser
___________________________________________________________________
WebContainers: Run Node.js natively in the browser
Author : bpierre
Score : 223 points
Date : 2021-05-20 16:10 UTC (6 hours ago)
(HTM) web link (blog.stackblitz.com)
(TXT) w3m dump (blog.stackblitz.com)
| e12e wrote:
| So... Two thoughts: this probably means we can run node in deno?
|
| Second: looks like js is catching up with smalltalk. JJust a
| shame the debugger is still rather crappy, and the
| browser/inspector only applies to a subset of widgets/controls
| (the html/css stuff, not the tab bar, address line, bookmarks
| menu etc..).
| _pdp_ wrote:
| I dig Web IDEs. I have been using Cloud9 (AWS) for the past 5-6
| years.
| jeroenhd wrote:
| "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 features are
| missing than an announcement that someone hacked Javascript into
| a browser.
| ericmsimons wrote:
| 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.
| dfabulich wrote:
| It looks like the problem isn't WASM features, but web I/O
| APIs, like the File System Access API.
| dmitriid wrote:
| 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...
| mywittyname wrote:
| Alright, so you can create an IDE in the browser, but, what else?
| I'm just not seeing the value in running servers in your browser.
| Presumably, most sites will still need to connect to a remote
| back-end services to get at data and whatnot, and that back-end
| isn't going to be running locally on a customer's web browser.
| chrisco255 wrote:
| I don't know about your dev environment, but in mine we run
| server code separate from web code. So you could toggle your
| local WebContainer to access either localhost:3001 or a remote
| branch, staging or prod environment for whatever server you
| wanted to test against.
| pixel_tracing wrote:
| Web development is a big gigantic shit storm. Why can't we use a
| real statically typed language without this JS shitty overhead,
| generate compiled binary and send that to users? I personally
| hate writing javascript
| mssundaram wrote:
| Have you not heard of WASM? And while it's not exactly what
| you're asking for, what about Typescript?
| namelosw wrote:
| Mind-blowing. The env spins fast.
|
| Maybe one day, smartphones and tablets are just browsers in hand.
| nightowl_games wrote:
| John Blow is going to lose his mind at this.
| chadlavi wrote:
| "You want it to be a mini operating system"
|
| I don't think this is universally true.
| nynx wrote:
| Someday, I'd like to see Wasi-based webassembly containers. It'd
| be awesome to spin up a sandboxed shell with file access in a
| webpage.
| ericmsimons wrote:
| You can actually do this with WebContainers today :) Try it out
| here: https://stackblitz.com/fork/node
|
| Full WASI support in WebContainer is landing in the next 1-2
| months.
| gameswithgo wrote:
| why do you want to spin up a shell with file access in a
| webpage?
| Spivak wrote:
| So you can open up your local project directory in your
| browser-based IDE and have it work like you expect.
| nynx wrote:
| My wish was actually to be able to spin up a shell locally
| on a github repo that pulls stuff over lazily.
| philipyoungg wrote:
| Does this mean we can use sqlite natively on the browser now?
| ericmsimons wrote:
| Yes. One of our engineers has gotten sqlite to run natively in
| WebContainer. Will be releasing as OSS in the next few weeks!
| philipyoungg wrote:
| That's pure orgasm. Thank you for this!
| chx wrote:
| note https://news.ycombinator.com/item?id=27016630
| skilesare wrote:
| I'd be super interested in seeing how much of this is really
| wasmified. I'd love to see if this could get running in a DFINITY
| Canister.
| lxe wrote:
| Wow. How? Node.JS needs a "full-blown" OS to compile and run...
| right? And that's not something you could emulate efficiently
| using wasm? Right?...?
| brabel wrote:
| node.js, as any other native Linux/Windows/Mac application,
| talks to the OS via a system API. You can emulate that API
| using WASM, mapping I/O to browser APIs, which is why they
| mention network is implemented via service workers, for
| example. File I/O can be mapped to IndexDB... Threads can also
| be mapped to service workers, I guess... and so on.
|
| emscripten[1] did this a long time ago for C, which is how a
| bunch of native applications have already been ported to run on
| the browser.
|
| webcontainers[2] seem to do a similar thing but focused on
| exposing the browser API to the native apps in a way that
| integrates well with the JS environment.
|
| [1] https://emscripten.org/
|
| [2] https://github.com/stackblitz/webcontainer-core
| ericmsimons wrote:
| Great question :) We have some additional technical info in our
| core WG repo: https://github.com/stackblitz/webcontainer-core
|
| We also did an hour long podcast a few months back that goes
| into pretty deep detail: https://www.youtube.com/watch?v=5F9qH-
| ea5Qk
| bellyfullofbac wrote:
| People have made Linux run on the browser, so... Although I
| don't think this is what they did here.
|
| Man, the yet another layer they've made between code and the
| CPU makes me uncomfortable. Imagine finding a bug and going
| through 20 layers to troubleshoot it.
|
| Also:
| https://www.theregister.com/2017/03/23/cursor_devours_cpu_cy...
| dheera wrote:
| Can we please call it NodeJS and stop calling it Node.js? It's
| not a .js file, and it's not written _in JavaScript_.
| emteycz wrote:
| 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.
| dheera wrote:
| 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 the sort)
| emteycz wrote:
| I agree it's not a great name - but IMHO using names
| incorrectly is even worse than bad naming.
| codingdave wrote:
| If you are going to get this pedantic, then why not also
| include *.com as bad, because that was a file type in DOS.
| throwawaycuriou wrote:
| JavaScript is not a scripting language for Java.
| frankenst1 wrote:
| I assume you still can't use UDP or bind to TCP sockets that are
| accessible outside of the browser?
| bestest wrote:
| 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
| ericmsimons wrote:
| Hi all- CEO of StackBlitz/author of this blog post here. Happy to
| answer any questions! (Also, thanks for posting this bpierre!)
| miohtama wrote:
| How much of this is JavaScript specific and how much could be
| expanded to "any" programming language?
| bpierre wrote:
| You're welcome :)
|
| Any plan to work towards supporting Firefox & other browsers?
| worik wrote:
| Why do this at all?
|
| With all the security and design problems of Node.js, when
| there are actually secure and reliable ways (harder ways, yes.
| Security and reliability are hard) to do all of this. Why?
| apignotti wrote:
| Hi, CTO of LeaningTech here. Congratulations for the highly
| polished demo. I think you might find interesting this one we
| did months ago: https://repl.leaningtech.com/?nodejs
| skybrian wrote:
| Could you point us to an introduction to how operating system
| concepts get mapped to browser concepts?
|
| It sounds like each native binary gets compiled to a
| WebAssembly binary, but how do they communicate? How are the
| network and file system implemented? Are parts of the file
| system persistent? How does a system call work?
| ericmsimons wrote:
| Great questions- we have some additional technical info in
| our core WG repo: https://github.com/stackblitz/webcontainer-
| core
|
| We also did an hour long podcast a few months back that goes
| into pretty deep detail:
| https://www.youtube.com/watch?v=5F9qH-ea5Qk
| waheoo wrote:
| That isn't a blog post. That's an ad.
|
| Can you link to the blog post where you actually discuss
| literally any of the technical stack in any depth further than
| one sentence of wow more pizzaz much fast.
| stephenbuilds wrote:
| 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?
| nailer wrote:
| > "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.
| drew-y wrote:
| 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?
| bouh wrote:
| 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 ?
| simonw wrote:
| Is this all open source?
|
| I'm fascinated in learning more about how you run a web server
| with this - the article says "WebContainers include a
| virtualized TCP network stack that's mapped to your browser's
| ServiceWorker API" but I'd love to understand a bit more about
| how that works.
|
| Since this is all done with WebAssembly are you planning on
| targeting other stacks such as Python? The amount of time I
| lose helping other people getting their Python development
| environments to work remains horrifying.
| ericmsimons wrote:
| We'll be open sourcing core parts of WebContainer as we move
| towards GA. We have some additional technical info in our
| core WG repo: https://github.com/stackblitz/webcontainer-core
|
| We also did an hour long podcast a few months back that goes
| into pretty deep detail:
| https://www.youtube.com/watch?v=5F9qH-ea5Qk
| yuri91 wrote:
| Is node/v8 compiled to Wasm entirely, or are you using the
| browser's JS engine with polyfills for node's APIs? Or
| something in between?
| huggyfee wrote:
| I'm trying to get my head around how the networking of it works.
| Is local.webcontainer.io being overridden somehow on the browser
| like a hosts file might do? Trying to figure out how I'm hitting
| that URL from another tab
| 1023bytes wrote:
| Must be some sort of tunneling, because it works outside the
| browser too
| goatcheese13 wrote:
| There is a service worker registered on the domain name, for
| example https://nextjs-agaw8i--3000.local.webcontainer.io/,
| then when you visit this URL in another tab it basically shares
| the service worker from the stackblitz tab.
| brundolf wrote:
| "Your scientists", etc
| worik wrote:
| This is a really bad idea.
|
| Building on the really good work of the WASM folks, running
| Node.js, with all its design problems, over the top of it.
|
| I am forever astounded anew by the hubris and naivety of the
| Node.js crew. It is a example of "It is easier to write than
| read, easier to talk than listen, easier to build than design"
| dfabulich wrote:
| You didn't say anything substantial here about why it's a bad
| idea. "Design problems." What design problems do you have in
| mind?
| SahAssar wrote:
| What about this is "native"? The page says it is "running
| natively" but also says "All code execution happens inside the
| browser's security sandbox".
|
| Is wasm in a browser somehow considered native now?
| easton wrote:
| I interpreted it as "native to the browser", which is a bit
| silly when you think about it, but makes sense when opposed to
| "running remotely".
| wongarsu wrote:
| Isn't the opposite to "running remotely" "running locally"?
| Meanwhile if pressed for the opposite of "running native" I
| would answer "running virtualized".
| [deleted]
| hn8788 wrote:
| The web devs where I work have started calling pretty much
| everything "native" as long as it interacts with the host in
| some way since people assume it means fast.
| syrusakbary wrote:
| I think very few people will realize the systemic effects that a
| demo like this entails. Very, very good work StackBlitz team!
| ericmsimons wrote:
| Thank you! Our entire team has definitely averaged 3hrs of
| sleep every night the past week to make this launch happen :)
| Incredible how much work goes into launching something like
| this.
| anton96 wrote:
| If their base is node, that implies we could start to see many
| electron.js app being ported to the browser
| devoutsalsa wrote:
| ELI5... why would you want to run an Electon app in the
| browser? Isn't that just a website at that point?
|
| EDIT: Upon closer inspection, it looks like this is an online
| IDE meant to mimic a desktop environment. I don't know if
| there's any demand for that, but sure, why not. I'm sure
| someone will come up w/ a reason to run WebAssembly in a
| jQuery plugin, too.
| Ajedi32 wrote:
| Backwards compatibility with existing Electron apps I
| guess? Otherwise yeah, a native PWA would be better.
| mlok wrote:
| I guess that running in the browser it doesn't need to be
| installed on the machine.
|
| Or a desktop-only Electron App would be usable from a
| mobile phone browser etc.
| hagg3n wrote:
| Funny you say that. I'm usually really skeptical of the next
| big thing but I felt differently about this, just can't put my
| finger on it.
| ericmsimons wrote:
| This really means a lot. I'm glad our work & writing came
| across genuine.
| brabel wrote:
| 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 "only works in Chromium-based browser"
| message on the next.js demo, where the preview should be -
| despite Mozzila being one of the main WASM backers and Firefox
| having arguably the best WASM engine).
| jrockway wrote:
| 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 needs that". (I was
| surprised how poorly tree-shaking works in practice, and how
| even "light" frameworks like Svelte ship a huge runtime to
| every user, unrelated to what features the code actually uses.)
|
| Meanwhile, WebAssembly suffers from there not being a good
| programming language that compiles to it natively. I think the
| Go support is great, but there's no library support for
| building the webapps that people get paid to build (React,
| Apollo, etc. all exist for a reason, however much you hate that
| reason). AssemblyScript was supposed to be this language, but
| it's just a Typescript-inspired programming language, it's not
| Typescript and the npm ecosystem.
|
| I don't know what the details of this implementation are, but
| the direction I'd like to see web development move is having a
| statically typed language that compiles to VM bytecode. This
| sounds like the first step for removing Javascript as a
| Typescript intermediary. Once that happens, then modern
| programming language features can be bolted on, people can add
| good compiler optimizations that result in minimal bytes output
| for users to download, the module system can be made stricter
| (like "go mod"), etc. Javascript is just a little bit more
| dynamic than anyone really wants, and it makes the
| build/deployment tooling complicated and, frankly, kind of bad.
| uncomputation wrote:
| > the direction I'd like to see web development move is
| having a statically typed language that compiles to VM
| bytecode.
|
| Java... you want Java. And so the cycle continues!
| slver wrote:
| 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).
| dfabulich wrote:
| > _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.
| slver wrote:
| > WASM can't even talk to the DOM API directly
|
| For now. It's planned.
| bryanrasmussen wrote:
| >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.
| emteycz wrote:
| 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.
| dfabulich wrote:
| 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
| slver wrote:
| I believe it still counts as a polyfill, even if it doesn't
| do what it says on the can (but it has compatible
| interface, so your app runs).
| kevingadd wrote:
| 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.
| pantelisk wrote:
| 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.
| oolonthegreat wrote:
| totally lost newbie here: but what is the difference between
| running javascript on the browser and running node.js on the
| browser?
| asmos7 wrote:
| basically node exposes all these other APIs like reading a file
| from disk. Browser also has APIs like detecting when the page
| is fully loaded that wouldn't be available on Node. What
| JavaScript syntax is supported can also vary between Node and
| browsers.
| des1nderlase wrote:
| WASM cannot magically load from disk, there is browser
| protection, right?
| Ajedi32 wrote:
| It can't access the file system, but it _could_ implement
| an API that emulates a file system inside the browser
| sandbox. Presumably that 's what they're doing here.
| Epskampie wrote:
| 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.
| ridiculous_fish wrote:
| 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.
| [deleted]
| oolonthegreat wrote:
| yeah that's what I gathered: javascript already runs on the
| browser, then we got node.js because people liked javascript
| and wanted to run it natively, and then finally we got this
| which allows us to run node.js on the browser again? it looks
| to me like we've gone full circle with extra overhead :D but
| I guess people have reasons to run node.js on the browser and
| not javascript so idk
| mindblock wrote:
| I guess the idea is to access some Apis that are not
| present in the browser, like fs. This was mentioned in a
| question to StackBlitzs CEO, but he seems to be an AI that
| just pastes the same text over and over again.
| sigmonsays wrote:
| Are any demo applications created? What is memory usage like for
| a simple application?
| ericmsimons wrote:
| Yep- if you go to https://stackblitz.com you can start a
| Next.js, GraphQL, etc dev environment in one click.
| waheoo wrote:
| ... in chrome.
| wongarsu wrote:
| You are right. In Firefox I get "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."
| holtalanm wrote:
| I'm not sure what the complaint is here. Isn't it something
| like 90% of the browser market is chromium-based, now that
| edge is on the bandwagon?
|
| Supporting chrome/chromium doesn't seem like a bad place to
| start with a prototype with that kind of potential
| adoption.
| benatkin wrote:
| Yawn.
|
| It isn't open source. It has a name, WebContainers, that implies
| it's based on the web, but it's designed around Node.js which
| isn't built on browser technologies as much as something like
| Skypack or Deno.
|
| It also seems like it's going to be a memory, disk, and CPU hog,
| and that it's going to be pretty complex. I like where Skypack is
| headed and this seems like the opposite direction.
|
| It's pretty cool but it seems like they're trying to create a lot
| of hype around it.
| holtalanm wrote:
| > I like where Skypack is headed and this seems like the
| opposite direction.
|
| I did a quick google search because I had never heard of
| Skypack.
|
| Skypack seems to be a far cry away from what WebContainers is
| claiming to do. Like, they're completely different products. I
| guess I don't understand why you're even comparing the two.
| NotEvil wrote:
| I think he means deno+skypack
| testingm wrote:
| Soothe your heart
| waheoo wrote:
| Title needs fixing. This is chrome only.
| ericmsimons wrote:
| For now. 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.
| Ajedi32 wrote:
| Wow, the PWA is really impressive. Honestly it's starting to get
| hard to tell the difference between this and Electron-based
| editors like VS Code. I'm really excited for integration with the
| File System Access API; that's the final puzzle piece I'd need to
| use something like this for serious work.
| aberger wrote:
| You can checkout www.StackBlitz.com/local and give it a try!
| Still in Alpha, but should generally work for you :)
| rodolphoarruda wrote:
| So it's 8 dollars for the astronaut plan. That's what I pay
| for robux to my kids, per week. It's jaw dropping to me how
| such advanced tech is made available at a single digit price.
| Thanks for sharing.
| codazoda wrote:
| Me too and I was surprised to find that Chrome lists this as
| "ready" or "released" (I don't recall the exact term). I tried
| the example web based editor and found that the file system
| access API worked in Firefox too.
|
| I'm working on a note taking project right now that I think
| would be great as a web app, but I'd like to store the result
| in a flat text file and the file system access API looks like
| it will let me do exactly that.
| k__ wrote:
| I will certainly try this, but besides the debugger connection it
| seems more like a PR stunt, to be honest.
| theflyinghorse wrote:
| Does this mean we can now have a SOA in the browser? True
| separation of concerns: Render code deal with writing to DOM,
| when data is needed it calls a node API proxy server which in
| tern interfaces with REST/grpc/graphql servers, then there's also
| auth service, and also a local (literally local) cache service.
| All in the browser. Damn.
| arodyginc wrote:
| Isn't it awful? Now each smart ass web developer will start
| sending down scripts with nodejs to enable 'rich' user experience
| educaysean wrote:
| Oh no! The user experience must surely not be enriched! Damn
| those smart ass web developers who aren't like the rest of us
| that care about code quality and engineering principles!
| nyadesu wrote:
| I think that wouldn't be a problem, as long as people get used
| to containerize what they write
| beebeepka wrote:
| Well, it's called WebContainers. One would hope everything is
| containerised
| throwaway284534 wrote:
| 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 few native file system issues I encountered that
| this would be perfect for!
| tesnirnat wrote:
| How did you end up doing this? Do you mind sharing?
| Tommek wrote:
| Yes web developing is so hard...
|
| sudo apt install apache2 php libapache2-mod-php; vim
| /var/www/html/index.php
| ttt0 wrote:
| I was kinda hoping it was something crazy like nodejs with v8
| engine compiled to wasm lol
| ericmsimons wrote:
| Did you read the post? You might be pleasantly surprised :)
| ridiculous_fish wrote:
| Can you please go into more detail as to what exactly is
| being compiled to wasm? The post does not describe it. In
| particular there seems to be a lot of confusion about whether
| the JS engine itself is running in wasm or not.
| Spivak wrote:
| The future is going to be wild. You could bundle V8 compiled to
| WASM with a graphics toolkit that uses a syscall like interface
| to access a canvas backed by WebGPU?
|
| At that point you could replace the browser with ZINE (Zine is
| not Electron) and run webapps natively just how WINE works.
| beebeepka wrote:
| I am definitely going to try this first thing tomorrow
| atc wrote:
| No.
| apignotti wrote:
| 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 V8 and its JIT engine. Of course fully
| client side.
| lsb wrote:
| > We are working on CheerpX, but it's not yet available
| generally. If you are curious and want to know more, stay
| tuned, or get in touch!
|
| How close is CheerpX to getting (for example) an app that uses
| a PyTorch model running in the browser? :)
| apignotti wrote:
| Not an expert on PyTorch in particular, the python + native
| (if any) components would work right now. If GPU acceleration
| is required some way to bridge into WebGL or (much better)
| WebGPU would need to be engineered, certainly doable but not
| existing right now.
| lsb wrote:
| Except for figuring out Pytorch's blas, the rest should be
| pretty straightforward to use CPU-only, I'd love to use
| that to (even pay to) compile some side projects to wasm
| apps in the browser :)
| zamadatix wrote:
| It looks like the difference is you went for full x86 system
| call level emulation to handle existing binaries whereas
| stackblitz decided to build a container for things like Node
| compiled directly to WASM with no static assumptions of a base
| system. The latter approach with 1 less level of indirection
| should be much more efficient, as is evident by startup times
| of the 2 demos. Not to mention the ability to hook into things
| above the syscall level.
| ampeter wrote:
| > 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?
| lucasmullens wrote:
| > Faster than your local environment. Builds complete up to 20%
| faster and package installs complete >= 5x faster than yarn/npm.
|
| How? Isn't this using npm?
| ericmsimons wrote:
| It's using a custom npm client we've built called Turbo. You
| can read more about the v1 version of Turbo here:
| https://medium.com/stackblitz-blog/introducing-turbo-5x-fast...
|
| We haven't released any more info on Turbo v2 yet but will
| soon.
| sakekasi wrote:
| This is super cool! I think pairing this with the upcoming native
| support for modules and a CDN like skypack could lead to a truly
| powerful browser development experience.
|
| No bundlers and a full IDE? Maybe this could even mean that
| there's a chance for a some of the 'just fiddle with the page'
| experience to come back to the web! (/rainbows and unicorns)
___________________________________________________________________
(page generated 2021-05-20 23:01 UTC)