WebContainers are now supported in Firefox on desktop and Android
blog.stackblitz.com
blog.stackblitz.com
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...
Hi, WebContainers does not depend on WebDriver BiDi. We did mention our interest in this new standard getting more momentum in other blog post (which might be the source of your statement?).
You keep calling it a standard.
The "working group" is some people on Discord. Your blog post calls it "our in-browser operating system" which is a far cry from a standard. You "team up with browser vendors directly", yet not through web standards bodies, but through some "bytecode alliance" that aims to build outside the browser. Also, unsurpisingly, zero links anywhere to an actual standards text or even to a specification of these web containers.
Fair enough, we should correct our mention of WebDriver BiDi to "tentative standard". BTW, not sure if you hold some grudge against WebDriver BiDi in particular, we were merely saying "gee, I sure hope something better than WebDriver comes along, b/c E2E testing kinda sucks".
> Your blog post calls it "our in-browser operating system" which is a far cry from a standard. You "team up with browser vendors directly", yet not through web standards bodies, but through some "bytecode alliance" that aims to build outside the browser. Also, unsurpisingly, zero links anywhere to an actual standards text or even to a specification of these web containers.
I am not sure what your objection is. We have a product, we're describing our efforts to port it to a new browser engine.
WebDriver BiDi is on the standards track, that's true: https://w3c.github.io/webdriver-bidi/
That being said, I agree that the blog post made it sound like WebContainers is some kind of standard, and I also found that to be confusing.
The underlying technologies and the tooling that you've been building on top of it are great. I was merely pointing out the confusing or perhaps misleading writing style of this announcement.
see a pattern there?
What? Where can I read about this?
- incredibly easy to setup (only a browser is needed) and use everywhere. Even management compatible.
- can be automated easily with ansible and/or docker
- remote pairing without a third-party cloud in between
- plug-ins just work even when being used remotely
- headless chrome can be proxied to the webview of vscode (a real browser running remotely in your browser)
Almost everything mentioned can be done with the tools you suggested BUT IMO it is not as smooth then just using vscode. This is coming from an arch (using arch BTW) / i3 guy.
If your objection is that it's inefficient and sometimes leads to bad quality output, I'd agree. But it's the option with the least friction so people gravitate towards it, we might as well make it work better.
I suppose while it has your attention, please vote for that feature https://connect.mozilla.org/t5/ideas/bring-back-pwa-progress...
I don't like the way web apps tie in with the pervasive tracking on the web, and the way they don't fit in well into the native UI and waste resources.
But it is indeed weird to remove the choice altogether.
One recent example, I pay for Spotify, but recently I started to pay for YouTube Premium to get rid of ads in the native mobile app, and it comes with YouTube Music.
I try YouTube Music and seems fine, was thinking to ditch Spotify and save that money, but YT Music do not have a desktop app like Spotify, on desktop is just trough https://music.youtube.com and has PWA features like "install", notifications and stuff.
I'm used to have that Spotify icon on my desktop and open the app, and being a Firefox user, with YT Music I can't have that experience, I can add a shortcut to my desktop, but it opens as a tab with all my other stuff opened. I don't like it. I guess I will stick with Spotify because of that.
In Chrome desktop, which supports PWA, you can install music.youtube.com, will add a desktop icon, opens in a individual window without tab/address bar etc. Is awesome. But is Chrome.
I'm considering use YT Music with Ungoogled Chromium to get the PWA features.
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
> That's the only reason I have Chrome installed, since I like to have different apps in different windows, and keep my browser tabs for websites.
I'd do the same thing, but Firefox is the browser I'd like to share data with. That's where my cookies, add-ons and user scripts live.
Chrome: Menu -> More Tools -> Create Shortcut -> Check "Open as Window"
Edge: Menu -> Apps -> Install this site as an app
PWAs are my main use for Chromium.
It's absolutely the future, Firefox just isn't in that future.
> PWAs are my main use for Chromium
Mozilla already lost big when everyone decided to use Chromium for Electron-style apps and now they're actively running into losing big again.
Malicious apps will never trick users into granting access to folders they shouldn’t, whereupon they won’t have their files exfiltrated, encrypted, and held to ransom.
IIRC that's actually possible on Linux, but a big pain and, like most command line switches, pretty undocumented.
But yeah, Firefox generally sucks for this use case and it's insane. It would be borderline trivial to implement, immensely useful and they've actually gone backwards on this type of stuff in many instances.
The browser is essentially an overlay operating system.
Kind of a crap one though.
Web assembly could be the basis for something that could break out of the browser.
Throw in "when Web Assembly can interact with the DOM and browser APIs" and you have the most powerful cross-language, cross-platform UI toolkit in existence.
It'll mark the year of the Linux desktop... probably, maybe - please.
https://web.dev/learn/pwa/windows
Can't say that it makes me happy.
What we have now really is a tragedy of the commons situation.
edit: Google maps (or equivalent) is a true game-changer that has a lot of value and one of the very few websites with actual value from javascript. But, we could just use Google Earth as a separate application for it. Just as we did in the early days when google maps on the web was a poor fit.
Very small price to pay.
I feel like when everyone says “this should be a native app” their imagined app is absolutely flawless and integrates seamlessly on every OS. But reality has rarely matched that ideal.
Today I'd use applications such as Slack and Spotify as posterchilds for bad applications. That they are built with web tech is not a coincidence.
I'm not a huge fan of a lot of web apps either but there doesn't seem to be a whole lot of introspection on the part of native app proponents. They're faster, they consume less memory, yet overwhelmingly people choose to make apps using web technologies. Why isn't anyone interested in exploring why native failed to offer what these people wanted?
For years I've been hearing about better frameworks and better tools for web development, but then when I open a website on the go, there are very often issues with rendering ot performance not to mention that a simple website consumes a large portion of my data bandwidth. This also happens with native apps but more often with web apps.
- are instantly usable just by following a link
- people can share with others, without needing to install anything, by just sending a link
- work equally well on all major mobile, desktop and tablet platforms
- don't require any sort of app store or gatekeeper to distribute or use
This isn't developers not caring about the user. These are huge UX advantages, and there's no way to get them all other than building on the web.
Depends on the size of the web app and by data bandwith
>- people can share with others, without needing to install anything, by just sending a link
true, as long as the web page still exists.
>- work equally well on all major mobile, desktop and tablet platforms
I wish, most of the time web apps are either optimized for mobile phone, tablet or desktop not all three of them.
>- don't require any sort of app store or gatekeeper to distribute or use
The app can therefore change without your knowledge and execute malicious code the next time it is called.
https://medium.com/hackernoon/im-harvesting-credit-card-numb...
Not to mention that the web app is gone when the site no longer exists.
This. I'm fed-up of "mobile first". I know why it's done, more website hits are from phones than desktop/laptop systems. But "first" is supposed to mean that something comes after; an awful lot of projects aren't "mobile first", they're simply designed for mobile.
I hate smartphones. I can't use them. I can't read the screen properly, and my fingers all turn to thumbs when I try to interact with them. I own one, so that I can call a taxi when I'm out, and so I can receive SMS messages. And some government services require a mobile number. But I have no data plan, and my smartphone normally just sits on my desk.
I haven't looked into this in detail, but I did started out programming in QBasic, used Delphi for over 20 years on Windows, and done cross-platform (all three) with WxWidgets and Qt, and I have given this some idle thought over the last few years.
I'm sure the truth is multi-faceted, but I feel it's primarily a combination of smartphones, lack of good cross-platform UI toolkits with low barrier to entry and the rise of SaaS.
Existing programs were not a good fit for smartphones. You couldn't easily take your existing C++ product and just recompile it. Simultaneously, smartphones required drastically simpler UIs, simple enough that a web page could be sufficient.
While cross-platform applications were possible with toolkits like WxWidgets and Qt, for most non-trivial programs you'd still end up with a ton of special cases needing handling. In one project we had one developer tweaking the OSX build, changing fonts and layouts to make it look and behave "proper" on that platform. It was better with Qt, but not perfect.
Also, these toolkits require a lot of ceremony to get going. Making a basic web page and adding some rudimentary javascript is quite easy, it's interactive and it's visual, which is great for learning. It's way more exciting to program something visual than mess around on a command prompt. I know many who became programmers through this route, people who otherwise hadn't thought about becoming programmers. Many of these have not moved much beyond the frontend.
Most people though don't really want to deal with computers. They want to use them, but not have to mess with them. Figuring out how to install and maintain applications, keeping track of security updates and all that jazz. This goes for individuals as well as companies. Thus the rise of SaaS.
Now, where I currently work we provide a hybrid SaaS-ish model for a Win32 desktop application. Customers provide the metal or VM, and we install and maintain the server software and client applications. However most customers don't really want to host servers in-house, and for us it's a pain to deal with all the various IT departments and their peculiarities. So both want to move to a proper SaaS, where the servers are hosted by us. Customers also want to be able to use Mac's.
This means we need a proper frontend/backend split regardless. No more direct connection to the database server. With that in mind, if you have a not-too-complex application, maybe a web page frontend is easier for both developer and user?
Now for our case, we have a complex CRUD application, so it's not so clear-cut. But if you have a relatively simple application with a handful of controls, then the choice seems to be much easier to me.
Of course, I could be totally wrong...
The web and browsers like many languages, are not something any one person or group can authoritatively prescribe.
The W3C follows the browsers, not the other way around.
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.
this is why the browser is winning. Javascript doesn't have access to your operating system. we finally have a way to allow arbitrary code run safely.
we then extended this to webassembly. this is how we're going to fix everything. the operating system is going to melt away and webassembly runtimes will rise. the end game is when webassembly runtimes run natively on hardware, and control is finally returned back to the end user.
Unless you mean that we'll have webassembly packaged in nice little .exes or .apks or some other app bundle so we can at least download them?
Due to phishing, it seems like most people do need security software, but not necessarily provided by the OS vendor. It could be from a plugin.
The biggest issues are lack of resources and lack of standardization. What organizations have the people to do all these things, besides the OS vendors?
We are getting it. Firefox needs a DE. If the iframe security improves just a little bit, it can even be a 3rd party DE.
And yes, at some point I hope people do flatten it. People already tried a few times, but it was too soon.
As a result, OSes are able to offer a lot of features and simplicity that would be impossible or painfully difficult otherwise.
You can see that as the fault of OS vendors, and in many ways I agree, but it's also their strength and the source of their advantages.
If OSes were to provide all of that, they'd end up looking a lot like web browsers. So I think it's mostly a matter of allowing web browsers to be web browsers and operating systems to be operating systems, even if that means that web browsers become a type of operating system themselves—a type with many added constraints.
The OS vendors are at least working on it from their side. Sandboxing, UI toolkits, and accessibility are improving. I'm just guessing that the optimal endpoint is going to be some distance from the optimal endpoint of web browsers, because the underlying constraints are different.
And some of extra layers are being removed: consider WASI, for instance.
You're not wrong!
In 1995, Marc Andreessen said [Netscape will soon reduce Windows to] "a poorly-debugged set of device drivers".
What matters is user, in this case developer experience.
Having reproducible environments shareable with a link is a statement to how far we are heading with web technologies and what can be achieved.
The browser is the last lingua franca of computing we have, and that's a reason for cherishing such advances, not bring back 40 years old debates of different OSs having different APIs and capabilities.
I dunno why people started saying "OS within an OS" just cause Chromium is multi-process.
Look into how Chromebooks work.
Go take a real serious look at what would be involved in implementing a web browser from scratch that would be compatible with Chrome and Firefox.
Now that compare that to the Genesis protocol.
The web platform is an overlay operating system.
Why would they be fighting against HTML & CSS? The best path is to embrace HTML & CSS from the OS level, that will provide the "flattening" you are looking for.
Kind of. It’s more that you're missing an important point. Software developers don’t want to be isolated to a platform.
I am writing my own higher level operating system in Typescript. In runs in the browser with a localhost Node instance or with Tauri. I provide a run time configuration for Electron but I cannot officially support Electron because it provide no support for SHA3. This means my application can almost equally anywhere that runs Node or Tauri.
The goal of this OS I’m writing is to solve for decentralization. I cannot do that if I am centrally tied to a single lower level OS. I don’t need identity management or DNS. I just need a network and a collision-free tiered identity scheme.
Look into web assembly.
There is an opportunity with web assembly to break out of the browser and do the overlay operating system better. Amazingly, most developers seem to not realize this, and have decided that web assembly will only need to run in the terminal or something. So either momentum or entrenched interests or stupidity will probably prevent the web assembly environments from standardizing on UI or device drivers etc.
Microsoft had not been needed for a long time.
The problem now is that a vast number of people know web (html, css, javascript) etc and they have little knowledge of UI libraries at the OS or library level.
The argument that it is difficult to create a cross platform UI is not a good one.
Delphi solved that a long time ago.
With Canvas you finally have the basic rudimentary structure needed to make sense.
Being doing desktop development since 1990 and Webdev since 1998.
If anything I guess it is the failure of the Year of Desktop Linux, that made many startups adopt Electron, because that is the only way for them to target the Linux "desktop" with low effort.
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.
What does a web container actually "contain"?
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.
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).
You effectively download the entire browser on demand.
Fairly sure no one would agree on what that binary at the bottom looks like though. :(
Isn't this impossible with CORS disabled by default in browsers? How do we work around this
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?
Awesome. Been waiting for this
This is a product, that has before now only supported Chrome, adding Firefox support.