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.
> Firefox has added support for some webdriver APIs[1] that this proprietary "WebContainers" product depends on
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?).
> We did mention our interest in this new standard getting more momentum
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.
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.
no, there is more going on than that. MSFT is adding engineering to Ubuntu to embed private data and keys at boot time; Firefox and libssl are shipped as SNAPD containers; it is not possible to turn off remote updates in Ubuntu
"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.
Mozilla seems to stray further and further every day. Some stuff is great, but like we still can't install whatever extensions we want on Firefox android without deeply jumping into dev features.
I currently use the Lynket browser (which can leverage Chrome Custom Tabs to present each Firefox tab as an Android app per tab) and shortcuts to web links to get most of the feel of a PWA. Would recommend it if you're interested. :)
What the hell? When did this happen? PWAs are some of the most exciting developments in web development. Did they give any reasoning about this decision anywhere?
Yeah, I agree. I will love PWA support on Firefox desktop.
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.
This is what most people who want a 'desktop' YTM use these days, it's mainly a webwrapper but has some decent extensions built in to make it easier to use. https://github.com/th-ch/youtube-music
I'm not a fan of PWAs, even despite being a fringe OS user for which many applications aren't available (FreeBSD). So while technically I would benefit from them, I don't use any.
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.
Firefox recently removed support for SSB (Site Specific Browser) and PWA (Progressive Web Apps). 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've tried a lot of things. Every option I'm aware of sucks. Even using multiple profiles (which would mostly break the reasons to want to use the same browser) is not really supported (lots of issues with window switching on both Linux and macOS).
I don't need or want the browser chrome like tabs and toolbars on those windows, and I usually pin them in the taskbar using their own icons. Makes alt-tab nicer too. I don't use it myself, but PWAs can also register as file handlers and be used to open files like any other installed program, which would be handy for image editors and similar.
Electron exists entirely because the web platform does not have access to lower level APIs. When the web incorporates these features (e.g. FileSystem Access), PWAs will replace electron.
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.
What is the benefit of everything being web based over setting up automatic building of traditional packages for existing OS or building containerized packages EG flatpak.
Because creating cross platform apps has always been really difficult. And creating web pages that work cross platform is less difficult.
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.
It always depends on the use case. A good example for an application being better because it is web-based is vscode. With code-server the possibilities are almost endless.
This was revolutionary for me as a developer.
That's remote development, and you don't need a web-based UI to do it. There's also JetBrains IDEs, any terminal editor over SSH, and probably plenty of other editors I haven't looked into.
Yes and no. There are some differences which make vscode superior to tmux/screen, ssh/fuse or rdp/vnc/nomachine based solutions.
- 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.
My opinion, I tried to make a quick side project, not for money,just to help someone. So the idea is what is the tool that takes me less of my free time and works for doing the job, fuck look and feel I need buttons and test only, I am also on Linux but the app needs to be cross platform and I will not buy Apple shit or Windows to do this, I done the project in Electron , I don't love it, I think is kind of a shit architecture, a duck-taped thing but it does the job for me.(also I personally prefer GC languages over c/c++ and Python syntax is not for me).
But if you pay me tons of money I would build you native apps, on my free time and money I will use a shitty toolkit that does the work it suppose to do. IF Microsoft would not be an evil and stupid company maybe we could all have been now making cross platform C# apps but the bastards really wanted it to be Windows only, nice job MS.
But none of them allow you to open the url in a new window, with minimal chrome, where clicking on a link opens in your main browser instead of a new tab in the current window. And you can't customize the appId so the window manager treats as another firefox window, not a separate app.
> And you can't customize the appId so the window manager treats as another firefox window, not a separate app
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.
I think the point is that you can't do it on Firefox anymore. You used to be able to, but the (partially incomplete) feature was removed instead rather than developed into an easy to use feature. The feature still works on Android, but the Mozilla team doesn't see a future in installing web apps apparently.
This uses the file system API, which users can use to grant read and write access to entire folders.
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.
Instead of building fast native application delivery and sandboxing we're taking the longer way around and reinventing OSes inside a document (!) browser.
Blame the OS vendors. There's no money in making an OS secure enough to run arbitrary portable code from a decentralized marketplace in a sandbox. All the money is in monopolizing app distribution, forcing use of their proprietary SDKs and APIs, and deleting any app they feel like "for your protection" (and also some other reasons but don't mind those...).
Blame web developers. There's no money in making web pages simple enough to be delivered to the client as fully functional hypertext without running arbitrary code. All the money is in stalking users across the app, forcing them to watch ads and navigate paywalls, and denying service to any ad blocker they feel like "for their survival" (and also some other reasons).
Oh, come on. Don't pretend like there are zero web apps with useful functionality. Or would you prefer Google Maps shut down and we all go back to Yahoo Maps where we click an arrow button that reloads the entire page with a new map tile displayed?
Oh yes. Not the slightest hyperbole. That would be amazing.
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.
But Google Earth was a terrible app with inconsistent UI! To my mind it’s one of the posterchildren of why making crossplatform native apps often ends up a total mess.
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.
Let’s take Google Docs as an example. A word processor where you can collaboratively edit a file with someone simply by sharing a link, without requiring anyone to install an application. How do you do this without the web and JavaScript?
That experience is one of the most empowering things we’ve ever invented. To me, “sacrificing the web” would be giving that up for your vision of purity.
Compared to just clicking a link and immediately having it working, yes. Installing software also has much bigger security implications than just visiting a website. And that’s if the application even works on my OS!
This is a total non sequitur in the context of the question implied by the top level comment, which is about why native app platforms haven't fixed some crucial issues that the web solved a long time ago.
Another way of looking at it is that we're inventing an app sandbox at the web browser level.
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?
Because many developers don't care about the user and UX.
They care only about themselves
It's easier for them to develop and easier to put trackers inside to monetize their work.
Bloated pages, crappy performance, battery draining? Who cares.
> I wish, most of the time web apps are either optimized for mobile phone, tablet or desktop not all three of them.
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.
Just wanted to call out point 4 — native apps can absolutely change without your knowledge and execute malicious code as well. And the potential risk is higher for native apps (on desktop, at least) — the browser sandbox is another advantage of web apps!
I don’t think this qualifies as introspection. You’re genuinely saying the only reason no one makes cross platform native apps is because the developers are lazy? You can’t think of anything else that turns people away?
There is no real cross platform, either the apps are native and take advantage of all the benefits or they are cross-platform and only represent what is possible on all systems, usually with poor performance and more space consumption.
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.
> Why isn't anyone interested in exploring why native failed to offer what these people wanted?
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.
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.
OSes do not need to allow the safe execution of arbitrary code downloaded from an ever-changing external server. OSes don't need to support dynamically downloadable code, updates, and plugins. OSes don't need to provide any level of accessibility to applications that don't bother to provide their own. OSes can get away with not providing any distribution or discovery mechanisms, let alone open ones.
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.
its all about security. the operating systems weren't designed for security. they were created pre-internet where you compiled all the code you ran on your operating system. its an unfixable architecture due to the nature of the API.
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.
Won't it be the opposite, control will fall further from the end user? All code is served from some remote endpoint, which you're unable to load if your device doesn't attest (like Android safety net) or some other arbitrary reason. That plus browsers are already too complex to replicate.
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?
I don't know what they meant, but in principle, I don't see why WebAssembly apps can't be downloaded, since browsers do it? (Ideally they should be signed, but using a more distributed scheme, like DNS.)
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?
By control, you mean browsers that consistently enable functionality to take away privacy. The same permissions you're referring to can already be managed using FlatPak, Snaps, etc
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.
Wouldn't you like some OS that you can install everywhere, without Microsoft getting in the way, and have a lot of applications, all sandboxed with segregated data?
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.
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.
The OS vendors don't really want the overlay operating system (i.e. browsers) to be better. Because that might make their OSs obsolete.
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.
In my opinion most UI stacks beat HTML+CSS.
Which is a truly horrible way to start to begin with.
HTML was never intended to be abused for that purpose.
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.
You can't make all graphics canvas based. Too much of a performance hog. It's not ready because who wants constantly spinning fans. No, reducing FPS is not enough because it makes things choppy
> Operating system vendors have failed to provide UI SDKs that beat HTML & CSS (plus browser APIs for modification of that HTML and CSS).
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.
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.
I rather have something completely new to replace the web. It's actually stupid to fix something when 100000s of different places depend on the bad behavior. Especially when one of them is the author of the most popular browser
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?
VSC in the browser effectively connects to some VM via web sockets and computation happens remotely. This I think leverages your own computer to do computation.
It only works remotely in Firefox, in Chrome (with its arguably questionable filesystem API). Plus, running the files in WASM is also what happens in these containers.
It’s running Node and NPM and some other stuff as well, which makes it more like a full dev environment than just an editor. It only runs JavaScript though (I think).
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).
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 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.
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.
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...