WebContainers are now supported in Firefox on desktop and Android
blog.stackblitz.comFYI 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...
> 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.
> The "working group" is some people on Discord
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.
I guess I didn't understand what exactly you were talking about when talking about "this new standard": WebDriver BiDi or WebContainers.
WebDriver BiDi is on the standards track, that's true: https://w3c.github.io/webdriver-bidi/
I see, it seems we misread each other.
Just a regular day on HN
I think "this new standard" was referring to WebDriver BiDi, not WebContainers, so you might be misreading them.
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.
Poor choice of words on my end, apologies.
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
see a pattern there?
> MSFT is adding engineering to Ubuntu to embed private data and keys at boot time
What? Where can I read about this?
YNews to start
"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.
You're talking about PWAs, right? It's still bizarre to be that the feature was dropped. PWAs are the top idea on their feedback site as well.
I suppose while it has your attention, please vote for that feature https://connect.mozilla.org/t5/ideas/bring-back-pwa-progress...
Crazy that they removed it. It works well on Firefox for Android, and it used to work fine in Firefox desktop too.
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?
The reasoning was that their implementation was buggy, and added tech debt, and they didn't think that PWAs on Desktop were useful.
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.
I had no idea this was removed. Ugh that's really distressing.
Terrible disappointment for this. I can't give up this feature so I can't go Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1682593
Can't find a lot of info about this. Is it desktop support only that's been dropped?
I believe so.
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.
It seems like Big Corps are afraid of PWA. Apple made a lot to make it harder to make a web app in ios safari; not talking about PWA.
Well, the recent EU regulations are certainly going to force a change in Apple's behaviour.
This is probably the most insane thing Mozilla has done in recent times, and they have done a lot of insane things.
> 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.
I think it would be better to have chromium or brave installed of chromium, since you use FireFox.
You could use different Firefox profiles for this...
But the icon in the task bar would always be the Firefox one. PWAs solve all the problems here.
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 just open multiple browser windows...
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.
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
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.
100% of the web apps I currently use in the browser don't need these APIs to function (Twitter, Tidal, HN, YouTube, whatever really).
Can PWAs use multiple windows, native menu bars or context menus, etc? I would not call those APIs "low level."
Depends if the browser is based on Chrome, thus an extension of ChromeOS, or not.
https://web.dev/learn/pwa/windows
You’re right, and I actually think the web would benefit greatly from a native context menu API!
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.
The benefit to me as a user is that I don't need to basically give access to my full computer to an app I may not trust.
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.
.Net MAUI?
Firefox command line has multiple options for passing a URL.
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.
They did that awhile ago. It's called ChromeOS.
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.
This can be done today:
Chrome: Menu -> More Tools -> Create Shortcut -> Check "Open as Window"
Edge: Menu -> Apps -> Install this site as an app
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.
PWAs are my main use for Chromium.
> but the Mozilla team doesn't see a future in installing web apps apparently.
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.
All applications and all malware. You don't want web apps to get write access to your HDD.
Web apps run in the browser sandbox. They don't generally have access to the filesystem.
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.
Parent writes about all applications to be web based, all appliactions without access to the filesystem are hardly possible.
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.
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.
Very small price to pay.
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.
It was still orders of magnitude better than the web version so not sure what the argument is?
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.
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?
You don't. And that is not a problem worth sacrificing the web for.
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.
Is it that cumbersome to install an application?
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!
Not having to install something does not even start to be "the most empowering thing we've ever invented" in my book.
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.
Other than the web, how can I make apps that…
- 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.
>- are instantly usable just by following a link
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.
> 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.
Of course, I could be totally wrong...
It hasn’t been a document browser for at least 2 decades though.
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 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.
You're not wrong!
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?
This is a problem that has already been solved. Look into PWA
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
> one day Microsoft is going to wake up to find they're not needed anymore.
In 1995, Marc Andreessen said [Netscape will soon reduce Windows to] "a poorly-debugged set of device drivers".
Interesting. It looks like this day is almost here.
I think you're seeing too much into this.
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.
Eventually we will have invented mainframes with X thin clients.
It's more like a distributed Unix installation with a shared central /usr.
> Am I wrong?
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.
But you ARE tied to the web platform, which IS an OS. Just kind of a crap one.
Look into web assembly.
It's not an OS within an OS. Browsers aren't fully responsible for abstracting hardware, providing a filesystem, and doing low-level network stuff.
I dunno why people started saying "OS within an OS" just cause Chromium is multi-process.
There are hundreds of APIs in the web platform including USB, gamepad, low-level graphics.
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.
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.
Microsoft had not been needed for a long time.
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.
Regarding 1., Forms, WPF, Qt, VCL, FireMonkey,.....
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
It's not even about OS, or GUI toolkits.
Damn, I thought that this would be about firefox android finally getting multi-account container support.
Glad I wasn't the only one having that thought. This is cool, but I'm bummed because my expectations were about multi-account containers on Android.
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"?
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).
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.
This is not a Mozilla/Firefox blogpost, nor is it about features being added to Firefox.
This is a product, that has before now only supported Chrome, adding Firefox support.