A list of recent hostile moves by Google's Chrome team • Hacker News Board

Re: A list of recent hostile moves by Google's Chrome team

#441

Post by tclancy » Thu, Aug 03, 2023, 2:46 PM UTC

arp242 wrote: post #206

mrtksn wrote: post #73

Earlier quoted context omitted.

> I'm curious what "its own vision" was The JS and CSS and HTML box model worked differently, the websites were displayed correctly only on IE or only on other browsers. People put text that says "best viewed in Internet Explorer 6" at the bottom of the page or straight out blocked users from displaying the page in other browsers and encouraged them to download IE - just the same thing we have with Chrome today when…

The IE block model was better though, and everyone is using it today with box-sizing: border-box. I still maintain that the pragmatic and sensible thing to do was to just modify the standard – "best viewed in IE" was a self-inflicted wound. Also remember the context: Netscape was just as gung-ho with standards as IE and everyone was kind of figuring out what did and didn't work on the fly. To just ossify a standard a…

Sure, and the XMLHttpResponse idea led to everything we have today. But lots of other things didn't work. document.all wasn't any better than Netscape's document.tags but they kept at it until they finally got around to supporting standards. They had major long-term bugs in how margins were figured. The layout model struggled if you used absolute positioning between two elements that were not positioned. Those are just the scars I still have, there were plenty more.

Re: A list of recent hostile moves by Google's Chrome team

#442

Post by tclancy » Thu, Aug 03, 2023, 2:47 PM UTC

oblio wrote: post #81

mrtksn wrote: post #73

Earlier quoted context omitted.

> I'm curious what "its own vision" was The JS and CSS and HTML box model worked differently, the websites were displayed correctly only on IE or only on other browsers. People put text that says "best viewed in Internet Explorer 6" at the bottom of the page or straight out blocked users from displaying the page in other browsers and encouraged them to download IE - just the same thing we have with Chrome today when…

As crazy as that sounds, IE had a better development team until IE6 basically killed off its competition. It was more stable than equivalent browsers, it had more features, I think it was even developed faster than competitors. Which sounds a lot like Chrome, except closed source. Those considering how big and cumbersome browsers are... does open source that matter that much in the grand scheme of things? Just browse…

Kind of sounds like EA Sports Madden.

Re: A list of recent hostile moves by Google's Chrome team

#443

Post by goku12 » Thu, Aug 03, 2023, 2:47 PM UTC

gorhill wrote: post #324

goku12 wrote: post #247

Earlier quoted context omitted.

The solution for the current web browser situation isn't another competitor. There will probably never be another big competitor. The reason is that merit isn't the primary reason how Chrome won the majority market share. There was a twitter thread that I have been trying to dig up ever since the WEI debates began. It was from a Firefox developer who explained how Chrome managed to get its users. Many Google websites…

> a twitter thread that I have been trying to dig up https://twitter.com/johnath/status/1116871245021220875

Thanks a lot for this link! And for making web tolerable with uBlock!

Re: A list of recent hostile moves by Google's Chrome team

#444

Post by andrewla » Thu, Aug 03, 2023, 2:49 PM UTC

webstrand wrote: post #404

andrewla wrote: post #374

Earlier quoted context omitted.

> It's 2023, Safari and Firefox have been very good for a while. This has not been my experience. Every once in a while I try to make the switch (to Firefox because I'm not generally a mac user, but I use safari on iOS and I'm basically resigned to its limitations) Slow rendering is for sure a problem. Buggy rendering is very common -- maybe the site, or maybe the browser, who knows, but anecdotally I've had a lot of…

I do a bunch of CSS work, and I've found more bugs in Chrome's rendering than in Firefox's, Lots of half-pixel errors. What kind of rendering issues are you seeing in Firefox? If you do a lot of web development, I strongly recommend getting familiar with Firefox's containers. You can set up SOCKS proxies for each individual container so you can easily pretend your dev server is running on the production server's doma…

I'm sure that Chrome's rendering is buggy as hell, but people design websites to work with the bugs; so they design them to work with Chrome, and in Firefox they look wrong unless they make the effort to work with both browsers.

I'm not a web developer; when I have to do web development I use Chrome because that's what we target and anything else is an afterthought (or is work taken on by more specialized frontend developers).

I tried ungoogled-chromium, but on upgrades it would frequently crash or fail to start so I gave up.

Brave maybe is worth a try; the cryptocurrency tie-in was enough to make me reluctant even to give it a try. I want my user agent to be as agnostic as humanly possible with regards to presenting data from web pages -- that's why I hate the auto-login feature and the "view search results" feature; I want my browser to render content and do only the minimum possible work in reacting to that content.

Re: A list of recent hostile moves by Google's Chrome team

#445

Post by galad87 » Thu, Aug 03, 2023, 2:50 PM UTC

brucethemoose2 wrote: post #440

izacus wrote: post #362

Earlier quoted context omitted.

Safari already implements Manifest V3 (it never had anything else to block ads) and DRM. So what the heck are you talking about? Safari is leading the charge on all those hostile changes. (Not to mention all the other ways how they undermine the web, like refusing to properly support PWAs and forcing you to go through Apple reviewed process for apps.) This strange narative how Safari (the only browser you're ever all…

It also doesn't support AV1 or AVIF. A cynical part of me thinks Safari supported JPEG-XL for pure tribal warfare, as its the "anti" AVIF. That would be so petty...

Safari already supports AVIF.

Re: A list of recent hostile moves by Google's Chrome team

#446

Post by titzer » Thu, Aug 03, 2023, 2:50 PM UTC

I don't understand the JPEG XL frackus, but that's partly because I think the Web platform should not continue being an enormous ball of mud, with everything built into the browser with no layering.

Make a Wasm module (use SIMD and threads if you want) that can decode the format and render to an immutable canvas and then let the browser engine manage the pixels after that. Wasm is close enough to native speed now that it no longer makes sense to bake this into the native browser binary anymore.

Re: A list of recent hostile moves by Google's Chrome team

#447

Post by tapoxi » Thu, Aug 03, 2023, 2:51 PM UTC

hliyan wrote: post #207

sph wrote: post #142

What is the excuse of all people reading this thread in agreement and still using Chrome? As I mentioned elsewhere, this is preaching to the choir. A choir of Chrome users. Google wouldn't be so dominant if tech people like us would stop making lazy excuses to continue its hegemony. In Dante's Divina Commedia , there is a circle of hell for those too lazy to take a stance [1]. If it were written today, it would inclu…

For a Mac M1 user who wants a lightweight browser, what would you recommend: 1. Safari (with this, I have trouble with some websites, particularly Google ones) 2. Firefox (good, but has been a memory hog in the past) 3. Brave (like that it's Chromium, but I worry about the odd features like crypto) 4. Edge (I just downloaded it. leaning toward this choice)

I've fallen in love with Arc https://arc.net/

It's Chromium-based with a custom UI (in SwiftUI). It's very clean and Mac-native.

Re: A list of recent hostile moves by Google's Chrome team

#448

Post by velcrovan » Thu, Aug 03, 2023, 2:53 PM UTC

izacus wrote: post #367

mrtksn wrote: post #332

Earlier quoted context omitted.

Apple probably have similar motives to MS when it comes to crippling the browser and enforcing its own rendering engine in iOS and that is to protects its app market. However, Apple did not attempt to divide the web then use its dominant position to make all the content only compatible with their stuff. With the IE situation, you couldn't just download Firefox and live happy thereafter because every website was made…

> However, Apple did not attempt to divide the web then use its dominant position to make all the content only compatible with their stuff. Of course they didn't, because they outright want to kill the web so all your content is locked into Apple reviewed and taxed apps. Why would they divide the web when their goal is to make sure it's not a viable platform for their newest devices?

> their goal is to make sure it's not a viable platform for their newest devices?

If that is the case, why does Apple continue to add functionality and features for web apps on Mac OS and iOS?

https://developer.apple.com/videos/play/wwdc2023/10120/

Re: A list of recent hostile moves by Google's Chrome team

#449

Post by wzdd » Thu, Aug 03, 2023, 2:54 PM UTC

insanitybit wrote: post #260

sph wrote: post #142

What is the excuse of all people reading this thread in agreement and still using Chrome? As I mentioned elsewhere, this is preaching to the choir. A choir of Chrome users. Google wouldn't be so dominant if tech people like us would stop making lazy excuses to continue its hegemony. In Dante's Divina Commedia , there is a circle of hell for those too lazy to take a stance [1]. If it were written today, it would inclu…

Manifest v3 has been delayed and was/is pretty legitimate, I don't think most people really know wtf they're talking about when it comes to v3. JPEGXL doesn't exactly seem like that big of a deal and is now being developed again - sounds fine, Chrome went "seems like no one wants this" and then people said "we want this" and now it's being worked on. WEI isn't even properly proposed yet, it's so early. So these 3 thi…

I rely mostly on the discussion around the implications for ublock origin when looking at manifest v3, because gorhill seems to be engaging with it in good faith.

Browsing the issue about it (https://github.com/uBlockOrigin/uBlock-issues/issues/338), it seems that manifest v3 blocks quite a lot of stuff out of the box. The fundamental issue seems to be that by mv3 prevents you from running arbitrary code to do filtering. This is concerning because it means that if sites / ad networks start coming up with ways to serve ads which can't be blocked by DeclarativeNetRequest (the issue lists a few), then ublock origin won't be able to block those ads. The way it's framed in the issue is "DNR is an obstacle to innovation."

There is currently a workaround in "ublock origin lite" (the mv3-compliant version) which lets you opt into regular ublock-origin-style filtering on a per-site basis. Even if this workaround isn't removed, it still means ... opting in to full filtering on a per-site basis, and acknowledging a browser warning each time.

MV3 clearly puts control of how ad-blocking works back into the hands of the company who supplies the browser and makes its money by serving ads.

Re: A list of recent hostile moves by Google's Chrome team

#450

Post by j1elo » Thu, Aug 03, 2023, 2:55 PM UTC

LinuxBender wrote: post #350

j1elo wrote: post #315

Firefox had been underperforming during part of its life, but deep internal improvements meant those days are over. There is a huge difference in memory and CPU usage between older Firefox and the one we have today. Sadly, lots of people still think that Firefox never changed. I did a quick memory usage test, just for having my personal anecdote and some numbers to show. The result was that Firefox uses an average of…

An additional test that may be worth trying out is BrowserBench [1] Varies heavily by computer specs. My daily driver is an ancient PC running Linux still fast enough for me but my newer mini-PC's leave this old thing in the dust regardless of what browser I use. [1] - https://browserbench.org/Speedometer2.1/

Did that test with the same Ubuntu and Firefox install mentioned in my post (https://news.ycombinator.com/item?id=36985276)

Results:

* Firefox 115: 120

* Firefox without uBlock: 130

* Firefox without any addon: 135

* Chromium 114: 135

* Chromium without uBlock (only addon installed): 150

* Edge 109: 122

Which means that all are in the same ballpark. I feel this test is more about CPU. It is also constantly (re)loading contents from browserbench.org, which tells me that the test itself might be very sensible to (and thus invalidated by) the network conditions at the moment of the test. Should be easy and would be much more reliable to preload all assets, and then do the benchmark.

EDIT: Adding values without uBlock Origin and without all extensions. We can see how having to parse all pages to check if there are elements to block, has its toll in CPU usage in the benchmark. For real-world cases of less CPU-intensive web browsing, blocking unwanted elements is immensely worth it.