If we take into consideration that both firefox and chromium use skia graphics library then there are only two companies apple and google.
Chromium and the Browser Monoculture Problem
71–80 of 128 posts
Re: Chromium and the Browser Monoculture Problem
#72The problem with browsers is they are so complex people can't build alternative implementations and keep them perfectly compatible. We need concise well-engineered and precisely-defined web standards a small team can implement in reasonable time. Many people would build competing browsers if there were yet we have what we have and no choice but to stick with the Google engine.
Sure. And then Google will start extending that standard, then sites will start depending on those extensions, and any browser that refuses or is unable to implement them will be extinguished/irrelevant.
The only reason to extend the standard if you can't implement required functionality with acceptable performance within this standard. That is the weak point for web platform: JavaScript is too slow and does not have access to drivers, you can't implement GPU-accelerated H.264 video codec within browser, so you have to implement it with C++ in browser. That means that proposed standard should be Turing-complete, provide C++ level of performance and native access to required hardware, while keeping browser-level safety and isolation. That is hard thing, but I believe, it could be solved using modern virtualization techniques with some advancements from OS and hardware to better virtualize GPU, USB, etc.
Re: Chromium and the Browser Monoculture Problem
#73Earlier quoted context omitted.
> extremely complex applications like office suites and 3D games Who really needs that in the browser? Native apps are consistently better in every single aspect - more powerful, more privacy-respecting, more eco-friendly, etc. Except native apps are vanishing - a month ago I wanted to fire-up SketchUp on my old Mac, only to find out that the casual 3D scene is now using 100% webapps. The reason we have these abomina…
>>Who really needs that in the browser? Enterprise IT departments, for one. IT people hate having to install, maintain, update and troubleshoot desktop applications, for obvious reasons. It’s orders of magnitude easier to simply install the app on a web server and have users run it in their web browsers.
As an IT guy, I disagree, because too many times I've seen things that use a web interface break for esoteric reasons made possible by the ridiculous number of layers involved. Applications people use for work are pretty easy to deal with by comparison, we just bake them into the image and update them only when we need to for a feature or fix. Even then it's usually just a matter of overwriting the application install directory, which we can do remotely, or at the worst running a silent MSI install, again remotely.
Re: Chromium and the Browser Monoculture Problem
#74Some random thoughts:
- IE vs Chrome dominance is comparable but not equal. One was closed source and stagnant, the other open and constantly evolving.
- “What if we all contribute to the same code base” ignores that not all priorities are aligned. Apple is a lot more focused on user experience and battery life while Google is all about moving the platform forward, see Web Worker conundrum for example.
- Browser are a lot more complicated now than they used to be, so creating anew from scratch is harder. But the Web is also a lot better documented (edge cases specified) and with more open implementations to get inspiration from.
Re: Chromium and the Browser Monoculture Problem
#75This would be a fine idea if Google didn't control the Chromium source code. The changes Google is making for webRequest v3 manifests will land in the Chromium repo. The changes Google makes for adding non-standard features happen in the Chromium repo. You can see them all here[1]. You can even sign in with your Google account and comment/review any CL you wish, but that doesn't mean Google listens.
Re: Chromium and the Browser Monoculture Problem
#76If we take into consideration that both firefox and chromium use skia graphics library then there are only two companies apple and google.
Does Firefox still use Skia with Webrender?
Re: Chromium and the Browser Monoculture Problem
#77> we're talking Chromium, the underlying browser engine. As it stands, Chromium is the basis for a variety of browsers, not just Google's flagship. From what I can tell (as a non-expert on Chromium's source, so please correct me), the Googley stuff that makes privacy advocates nervous is independent from the core Chromium browser engine This might be just me being pedantic, but I thought it might be worth mentioning.…
And this is why dropping back to the WebKit that Blink came from is not a terrible strategy, especially since it underpins the best integrated (battery life etc.) browser for MacOS and only browser engine on iPad and iPhone.
I’d like to see the privacy conscious “user agency” browser builders pivot back to WebKit.
Re: Chromium and the Browser Monoculture Problem
#78The big difference is that IE6 was a PITA to develop against while Chrome is a breeze. Developers wouldn't have hated the IE6 monoculture if it was as fast as Chrome and had developer tools and features as nice as it.
I think you are looking at the later stage of IE's life when it was already dominant.
When IE first caught on it was extremely fast and pleasant to use compared to Netscape (also netscape wasn't originally free). If you only cared about IE it was actually a complete breeze to develop for using proprietary stuff like ActiveX (ignoring the fact that ActiveX was a bad idea for various reasons).
Lots of websites started showing banners saying that they were optimized IE, because people were primary targeting IE when they made new websites, in part because it was such a breeze to develop for. IE had lots of HTML/javascript features that made things much easier than other browsers at the time.
It's important to realize that IE only became difficult to deal with once 1) Microsoft essentially stopped trying to improve it after they won all the market share and 2) people needed to make web pages that worked on other browsers. At this point people wanted to use newer features that IE didn't support, but needing to support IE 6 necessitated either abandoning more modern features or using all sorts of hacks/polyfills to work around IE's quirks.
Re: Chromium and the Browser Monoculture Problem
#79> we're talking Chromium, the underlying browser engine. As it stands, Chromium is the basis for a variety of browsers, not just Google's flagship. From what I can tell (as a non-expert on Chromium's source, so please correct me), the Googley stuff that makes privacy advocates nervous is independent from the core Chromium browser engine This might be just me being pedantic, but I thought it might be worth mentioning.…
Edge basically takes the entire chromium product including the //chrome layer, but we have removed or disabled most/all of the Google service integrations
And “Edge” and “Chrome” both ship on iOS using WebKit.
Re: Chromium and the Browser Monoculture Problem
#80Earlier quoted context omitted.
> any browser with noticeable (maybe 3-5%) market share causes these problems. No. When Web devs test in multiple browsers and find that something doesn't work in one of them, they will usually pick an alternative solution that does work in all of them, avoiding the bug in the buggy browser, thus avoiding a situation where their site depends on that bug continuing to exist. It doesn't always work out as well as that,…
> extremely complex applications like office suites and 3D games Who really needs that in the browser? Native apps are consistently better in every single aspect - more powerful, more privacy-respecting, more eco-friendly, etc. Except native apps are vanishing - a month ago I wanted to fire-up SketchUp on my old Mac, only to find out that the casual 3D scene is now using 100% webapps. The reason we have these abomina…
I generally dislike installing software. If there's a webapp that does something I want to do, a native app doing the same thing would have to be much much better to make up for the convenience of using a webapp