"Create and develop full web applications inside your browser tab". You know what would be even better? If we could add an icon for this app to the desktop and run it as standalone application, while using the same browser engine installation. We are practically at that point where OS needs only web browser installed and all applications could be web based.
Instead of building fast native application delivery and sandboxing we're taking the longer way around and reinventing OSes inside a document (!) browser.
Can't say that it makes me happy.
I feel weird about what's happening in the browser.
I can't put my finger on it, but something seems off...
We're moving towards an operating system on top of an operating system (browser)...
And now, node.js and other runtimes, in the browser, on top of that.
I'm hoping we can flatten this at some point...
It seems like the core problem is that:
1. Operating system vendors have failed to provide UI SDKs that beat HTML & CSS (plus browser APIs for modification of that HTML and CSS).
2. Operating system vendors have failed to have such a UI SDK work cross-platform across operating systems.
3. Operating system vendor UI SDKs do not allow UI to be bootstrapped dynamically (e.g. retrieved dynamically over the web) and built-up in code via APIs as simple as browser APIs.
4. A failure in open distribution and discovery of apps.
Am I wrong?
Is this direction in computing a failure of OS vendors to get together and solve this problem?
This seems like a source of sudden disruption some day...
I feel like one day Microsoft is going to wake up to find they're not needed anymore.
Damn, I thought that this would be about firefox android finally getting multi-account container support.
hi HN, there's a companion technical post by yours truly which might be more appropriate/technically dense for your taste:
https://blog.stackblitz.com/posts/supporting-firefox/
(I'm also sad that Multi-Account Containers are not a thing in Firefox for Android).
Disclaimer: I (obviously) work for StackBlitz.
Very confusing to name this "webcontainers". Considering Firefox already have their own containers.
I don't think I understand what this is actually doing. It's being pitched as some kind of new way to develop Javascript inside the browser, but VS Code is already available in the browser?
What does a web container actually "contain"?
So let me get this straight.
We had JS in the browser and people want it on the OS, so we got node. Now we're taking node from the OS level and putting in the browser?
Its like a story told by a madman.
Really like stackblitz.That said, I happen to be working on it at the moment (in FF104) and have been having a bunch of issues (as of very recently).
Biggest one is that I had to disable Enhanced Tracking Protection to get the preview to work. Only a new relic analytics script was listed in the panel, but reading further I found ETP probably still presents other gotchas for their container setup (see below).
More of an annoyance, but I'm also getting "Service workers are disabled by Firefox on this page[...]" message logged persistently to the console, with a link[1] that goes some way to explaining the ETP issue above. Everything still works. In fact, the log appears to be associated with a firebase service worker, as the subsequent message (every time) is an error due to a firebase long poll getting blocked for CORP header issues.
I'd add that it was working perfectly last week, possibly prior to a browser update. They seem to be somewhat aware of the issue (see [1] and per instructions printed to the non-working preview panel).
A more misleading title could not have been devised. Edit: typo.
What I want is to flip this. Let the base of everything be a webcontainer. Like MS/Apple/Ubuntu all agree on a binary base that can run webcontainers. Then Firefox/Chrome/Edge even run on this beast.
You effectively download the entire browser on demand.
Fairly sure no one would agree on what that binary at the bottom looks like though. :(
This great, but how would we handle dynamic calls to other servers that are part of my web-app? Maybe a NPM package that needs to downloaded from an external registry or an authentication service that needs to speak to Auth0?
Isn't this impossible with CORS disabled by default in browsers? How do we work around this
So in essence instead of having the browser talk to a server somewhere, it can now download a server, and start talking to that.
The browser then no longer needs to "go to the server", the server will come to the browser.
Is that correct? What would be some use-cases for it?
So when can I start building on top of webcontainers myself? You seem to be present it as some sort of new browser api, or a library, but from the looks of it it's only the proprietary technology that underpins the stackblitz product.
> Debug Node.js applications natively using Firefox DevTools
Awesome. Been waiting for this
I wish people wouldn’t conflate operating system with a run-time environment, desktop, or IDE. Especially here of all places.
Firefox, may I tell you what the free Web really needs? A docker-like environment for websites. The environment can arbitrarily override anything, from JS built-ins to CSS rules, and do that in such a way that the underlying website would never know about the shim layer. A useful bonus would be limiting CPU time spent by the website. The former can be marketed as a privacy feature and the latter as comvating global warming.
FYI WebContainers are not a web standard, but this article sure does try its best to make it sound like one. Pretty off-putting and not at all necessary for such a great product as Stackblitz.
Firefox has added support for some webdriver APIs[1] that this proprietary "WebContainers" product depends on. That is all.
[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...