Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.
> Because after seeing WebUSB and WebGPU I think my personal limit has been reached.
Sure, but where do you draw the line really? For me, having WebUSB and WebMIDI for example is useful, I want to be able to interact with synths over MIDI in the browser, or be able to access other accessories. I also love the idea of GPU access, so my personal limit has not been reached.
Multiply this by every vendor, developer and user of every browser who contributes to the specifications, and you end up with probably 1000 different directions everyone wants to move in. How do you decide which is the right direction?
Right now, the choice you have is which browser you use. If you don't want WebUSB or WebGPU or anything else "new and fancy", choose a browser that doesn't implement those things.
Browsers are just “standardised” OS at this point. Really, what is the difference? It seems to me that people basically wants a 1 to 1 mapping between every OS feature to browsers. I wouldn’t be surprised if this standard will fall apart in the next decade once Chrome runs everything. That is to say Chrome is the standard. I am already seeing websites drop support for Firefox and won’t even load using it.
The difference is that it is not a "standardized" OS interface. Rather it's a complex layer on top of operating systems offering dumbed down and less performant versions of what is available all of which is interfaced by a dynamic and not so performant language.
If it was something like a modern POSIX I don't think you'd have much complaining. But it's a lot heavier than that.
In the context of this thread it is enough to compare Web 3D capabilities and tooling, and how lacking they are when compared against with the native conterparts.
I'm not sure if these are examples of dropped support, but I run into issues on websites that prevent me from doing something I really need to do:
- I could not unsubscribe from amazon prime yesterday using firefox. The page where you select the option was not rendering correctly. It was white for half the page vertically and the link/button I need to press was absent.
- about 6 months ago I could not sign into apple id on apples site on firefox. (or something like this, I forget exactly what I was trying to do).
- about 6 months ago I could not sign into nintendo's site to cancel a subscription.
So it's not super frequent, but every few months there are important things I can't do in firefox.
In my experience, problems like that are almost always a matter of cookie/cache sticking around when it shouldn't or plugin interference. The only sites I ever have have blocking trouble with in FF are shitty web interfaces for local device configuration, old automatically generated webpages like from MS Access or some other super old enterprise abomination. I worked on a team of web developers that generally developed using FF and then tested heavily in chrome-- everything from simple pages augmented with JS to complex SPAs-- and the differences were pretty minimal.
Yeah that could possibly be it. If I run into again I could try clearing caches. And also wanted to mention that since firefox is what I use daily, of course I will mainly see issues there.
If I used chrome daily perhaps I would see the opposite (broken on chrome, works on firefox).
I get the same feel from DuckDuckGo. I use it, till it doesn't work, then switch to google when it doesn't. Of course google would perform better, as I only use it for the cases where DDG fails.
Yeah, with one exception it has always been dark reader that caused a page to render wrong in Firefox. The exception was some misconfigured oauth stuff that didn't work.
It's sad that there are specific browser-oriented websites (and development processes, obviously) instead of the standards-oriented ones.
(Sure, it's Chrome-oriented ones. We've seen similar previously with IE, by the way.)
We have standards for the web. Real ones: the docs, which are discussed and approved in the industry. We have them for a long time!
So if some browser does not comply to the standards, it's really not the best strategy to adapt a site to the browser instead of the standards.
We are in the situation when (effectively) one company (Google/Alphabet) can lead anything to the whole market, step by step (even when changes contradict the web standards that are in place). The market is not the browsers market, of coyrse, but the internet ads through browsers control, which brings the most money to Google. By projecting its power to each and any aspect of it, Google ensures the uninterrupted market control for years ahead. So Google will continue to do. In the long run, we need to rely on standards instead of specific browsers. Otherwise it's just the monopoly of Google and web tech "market" is just their own backyard. That will bite us all hard.
Having a standard is not even possible technically when you have 1 player that is too good. Due to Hyrum’s Law, any small divergence from the spec will be observed and relied on. Why would you work against the spec which is nebulous, when you could be testing against 99% of what your user use?
It's not too good. It's just wealthiest. Because it holds ads market monopoly. Because it happens to be the popular search engine at the same time.
But it's not the best. Firefox is on par (I know they get some (most?) payments from Alphabet). And people were using Firefox/Netscape browser long before Google existed.
Even if Chrome were the standard, there would still be variety due to plugins. A lot of sites have glitches in Chrome too, if you install the wrong plugins or turn stuff like third-party cookies off.
I'm not sure I trust people who say something doesn't work in Firefox, unless they tried it in a fresh profile with default settings.
I wonder if you could just duct tape a kernel to a modern browser and boot right into it. Ok, well, I know you can do that, but I wonder if you could get people to use it.
You'd need some tinkering to open a new browser window per monitor, couple of routes on 127.0.0.1 for config.
I want to be able to interact with synths over MIDI in the browser
Help me understand why this is. Is it because there aren't native programs for the platform you're using? Is it to allow plug-ins or other abilities that wouldn't otherwise be available? Is it so that you can sync up with other musicians and play together in a way that wouldn't be possible without a browser?
choose a browser that doesn't implement those things.
The way feature creep have been going lately, in about six months that will mean Lynx.
Because it's really cool to try out experimental instruments other poeple have made by simply opening a webpage, without having to execute untrusted native code that could have bad consequences.
I'm interested if this is true. It seems like the js sandbox is pretty well implemented now in most cases. Webgl had some problems at first leaking host data, but the willingness to sacrifice performance for security seems pretty ingrained in these consortiums?
You oversaw the untrusted part, this is the only reason I prefer web over native really. If there was a way to run native apps with that level of isolation, I would prefer native.
Unfortunately, none of those are cross-platform... Closest we get to something similar to the web is either the JVM or APE (Actually Portable Executable) but then those are generally not as isolated as the alternatives you mentioned, sadly.
> Help me understand why this is. Is it because there aren't native programs for the platform you're using?
Easier to create, easier to share and run. Mainly easier to create because the ones I'm sharing small MIDI sequencer experiments with are also web developers, so we just send each other links where we can run stuff direction from, and we can help each other out as we all use the same technology. Really easy to understand what the other is doing too, as you just open up the source of the page and that's it.
I've played around with other languages/runtimes for doing the same thing, but nothing is as fast to implement as with JavaScript, probably mostly due to familiarity.
I'm not going to argue against these features, but I find that last argument you raise to be a rather dull and useless one. Yeah, I'll just go ahead and pick from one of the hundreds of competing implementations to find one that doesn't. Oh, wait, they don't exist.
It's like saying "if you don't like the laws(/taxes/whatever) where you live, go somewhere else" and acting as if I can just hop on over to Mars. I can't.
That is exactly what they are saying. Having control over your relative experience is the only thing people want.
As we all spend most of our time inside of browser interfaces its not a surprise we see app, features and interfaces move to that process portal to. (Online IDEs, Cloud, Photo editing, etc.) Sure you can use your solution but in general, as always, its whats most efficient for the masses.
WebUSB was actually useful to me not long ago. I installed Home Assistant and its ESPHome[1] companion, and ESPHome had support for using WebUSB to upload the firmware to a blank ESP8266 I had. I didn't have to install or set up anything on my Windows machine, and the whole process was very quick and convenient.
It seems clear to me that the main issue here is that a lot of programs aren't closely tied to the hardware or the OS. Building them to be so is an annoyance for both users and developers. As Scott McNealy said, you don't need to know how to operate a nuclear power plant to turn on the lights, and most users just want to get stuff done.
That we have three major operating systems still going relatively strong is evidence that there are differences that matters to people. But for a lot of applications those differences don't. The WebXYZ stuff thus increases usability a lot by simultaneously solving the cross-platform compatibility issues and distribution.
In my ESPHome example above literally opened the website, plugged in the USB cable to my device, clicked a button on the web page and the job was done.
So while I don't really like that the same web browser is used to surf other web sites, given that these WebXYZ components present additional security risks and fingerprinting opportunities, I can't deny that they're useful.
I had a similar pleasant experience with a Wooting 60HE keyboard I purchased recently. Updated my keyboard’s firmware and settings right in Chrome! So much nicer than downloading icky gaming peripheral software. I’ve been told a lot of that stuff is borderline spyware.
Excited to try it out with some ESPHome projects too now.
The issue of the Web's lack of distinction between document viewing features and being an application platform (with access to system resources and private data) is decades old. Unfortunately, the question has been academic for decades as well: before the advent of HTML5, proprietary browser plugins gave Web sites the same abilities (ActiveX and Flash being notable, as were their security vulnerabilities). Flash was ubiquitous circa 1998-2008; your typical user would always have it installed. Nor did the typical (non-techie) user know that the Web was not originally intended to be an application platform, or the implications of it being used as such.
Free yourself from the notion that a web browser purely browses The Web.
It's nowadays also a cross-platform insta-deployment GUI application runtime environment with mostly bad native OS integration and performance characteristics (both ~improving, there's even native filesystem access now).
> Free yourself from the notion that a web browser purely browses The Web.
Free yourself from the notion that a web browser should do anything more than browsing the web. native applications have existed for decades, no reason to bloat the scope of a browser.
Hmm, RGamma describes reality: it is a fact that web browsers don't purely browse The Web, has been for decades now, and there is zero indication this is going to change.
You seem to demand that people ignore this reality, because you don't like it. This is not helpful.
I don't like this reality either, but despite that I find your statement also factually incorrect: "native applications have existed for decades, no reason to bloat the scope of a browser".
Of course there are reasons, otherwise people/companies won't do it, and users won't use bloated browser that give them no benefits.
I agree that downsides outweigh the upsides, but the upsides are obvious and immediate while the downsides are long-term and mostly subtle...
> Of course there are reasons, otherwise people/companies won't do it, and users won't use bloated browser that give them no benefits.
The reason is of course control. Things running in the browser gives Google control. That's why they push for everything running there. Want to compete with Google? Tough luck, no tracking for you while they give themselves IDs built into the browser. Do something Google doesn't like? Maybe your site isn't "safe" enough according to Google and won't be shown to users. Invested in your webapp but want to integrate something novel? Guess who gets to decide if you can?
One big reason is that installing the software is one click (on the link) and it works every time. With native software, on phones you have to open the App Store, search for an app and usually wait to download hundreds of megabytes before anything happens. On personal computers it's much worse.
Seeing a semi-technical acquaintance use in-browser software for daily productive work hurts my programmer's soul. It's alright for some light things, like vacation planning, but remote desktop or an IDE...
Then there's that other scourge of Electron-like apps with gigantic memory budgets and all. I have resigned to throwing more hardware at it when I can't guarantee a lighter replacement (i.e. in a work setting):
All my productive systems have 32GB RAM and 8+ threads now and with browser, Teams, Outlook, IDE and dev containers the air's getting thin again :/
I think I would rather have a bloated (but reasonably fast and featureful) browser, than clog my computer with native apps for every app out there. Most of the apps doesnt need much power anyway.
I really dont want to see a repeat of phone apps for every company I interact with.
Most "apps" including "webapps" shouldn't be interactive programs to begin with but a web of documents you can explore using a tool made to your specifications and noone elses.
Why does it bother you that browsers have many features? At this point browsers are essentially a cross-platform VM and it really seems like this trend will only accentuate in the future.
Those are the main reasons. And seeing how browsers are essentially designed to run other peoples code with minimal to no vetting processes, I consider this a serious issue.
So how is this any different if we don’t have a browser? People still want to visit “websites” which in your world is even worse. Because now every website is a distinct application (yikes!). The problem is that people are willing to run arbitrary code in the first place.
How many times have _you_ as a developer, run arbitrary scripts from the internet? Blindly accepts packages that you have not vetted?
I would be very different if browsers were tools to view documents though. I am not saying that browsers don't have a purpose. I just question that browsers should answer the question about what their scope is with a loud "yes!"
Thanks for sharing, that's interesting angle that I did not consider. So essentially the argument goes that more "surface area" == more vulnerabilities? While that makes perfect sense, don't you feel like the pressure for more feature comes from somewhere? By analogy, dynamic languages like JS/Python make the job of people writing the compiler much, much harder. But, on the whole and despite all their flaws, it is true that they increased productivity by a lot.
because I want limited scope tools. if I want something on the GPU, I can just write a native tool. I dont need the browser to do anything beyond web browsing.
Whatever features browsers have, it does not prevent you from writing native tools.
But browsers don't limit themselves to serving your needs only, and they are not in the business of promoting your approach to computing among their users. Why would they?
Yes, the browsers evolved very much beyond this original purpose.
Again, it did not happen without any reason, it happened for a reason.
The purposes the modern browsers serve apparently are more important to their users than that original purpose!
Indeed, I believe there are obscure browsers that don't support any of this new stuff, and are only good for rendering plain old HTML. They remain obscure for the obvious reason: they cannot be used for what most people use the browsers most of the time.
WebPSU - this will allow your browser to directly access your computer's power supply. simply plug your appliances into your browser and they can use the same power that your computer has access to.
Who's the royal we here? It's great that you have personal limits. But why should "we" care about those?
Seems like a perfectly reasonable new feature to me. I'm actually looking forward to people using this to build some cool stuff. Why should that not be a thing?
WebGPU in browser isn't really interesting to me. But I do like WebGPU in native applications, as we are yet again in scenario where Windows prefers DX, OSX their own Metal and Vulkan is yet again mostly linux only player, and popular WebGPU implementations have backends to all of these (+ more).
Windows supports Vulkan just fine. People use DX because of Xbox and tooling - the existence of yet another API won't change that. And neither will WebGL be better on macOS than MolenVK.
Yes until it doesn't or vulkan implementation is considered as second class citizen. Been there seen that. The other thing is that webgpu is slightly higher-level so you do not have to go into extremes with memory handling and synchronization as in vulkan. So unless you absolutely need to squeeze everything out, webgpu gives nice balance.
Yep. I just read through the entirety of this guide specifically to better understand Mach, which uses Google's WebGPU implementation for everything graphics-related.
I think of the browser as another kind of OS, and as Microsoft keeps making their OS worse the browser is a nice reprieve. The more that goes into the browser the more I can ditch Microsoft and hopefully be rid of it all together.
Though ironically maybe given that the browser can do so much is the reason that Microsoft has to focus on ‘value add’ crap instead of just a rock solid OS. Which sets up a self reinforcing cycle. Microsoft should recognize that this was intentional move by Google and not take the bait.
I think one of the main drivers of new browser features is ChromeOS. Manufacturers are selling a lot of Chromebooks, especially to schools, and because ChromeOS is primarily a conduit for running Chrome, the best way to add features to Chromebooks is by adding to the browser. From Google's point of view, anything ChromeOS needs is a candidate for a new browser feature.
the more important question is whether the browser's surface area for bugs and perhaps security vulnerabilities are worth the marginal increase in features that most people might not use!
It's not like native OS features don't have security vulnerabilities. At least all the major browser have at some major portion of their implementations that are open source projects. So if you're stuck working on Windows or MacOS, at least you can know that Web browsers aren't limited to one vendor finding and fixing those defects.
Why exactly would programs running in web browsers not want the ability to access the most powerful piece of hardware in a users machine? WGPU unlocks an enormous amount of space for userland programs to explore.
I agree there have been some questionable 'advancements' in the web spec recently (web workers as a solution to multithreading, for example, were hilariously inadequate for quite a while), but as far as I can tell WGPU is a solid effort to unlock browsers as an actually interactive platform, instead of the fairly static image/text display devices they are today.
Maybe our visions of what browsers could or 'should' be are different
At least for me a browser should be an interactive document viewer. Not CAD, not file conversion, not writing OS images to an SD card, not generating GCode. Ingesting HTML, CSS, and JS and turning it into an interactive view of that XML document nothing more, nothing less.
I tend to feel that way mainly towards new features that are very similar to ones that already exist. eg. WebGPU being a more advanced form of WebGL. Yes they work differently, but they generally solve the same problem.
Eventually I'd like to see WebGL deprecated, and perhaps an extension released to reimplement it. Or it could be adapted to translate calls to WebGPU, rather than having a completely separate implementation.
Is that realistic? No, of course not. Browser vendors take backwards compatibility pretty seriously, and WebGL is used on a ton of websites. Still, that'd be my preferred solution for avoiding said feature creep.
The OS runs on hardware, what do you think is below the OS you're running?
Even excluding VMs, there are a lot of OSes running in a modern computer. Some chips have their own. BIOSes and Secure Enclave, networking chips, and probably a dozen more.
Try to understand the context of more than one comment at a time if you can. This person said "it's turtles all the way down" because there are two layers, the browser and the OS, which is ridiculous.
