I don't like Google, but Chrome is a better browser - especially if you're frontend dev. I'd love for Firefox to be better but it's way slower and its developer console is no match for Chrome's.

Strictly from a frontend dev perspective, sure, also just because popularity alone - but why would you not have a separate personal and development browser? I definitely wouldn't want to mix the two - various comfort extensions mingle with DOM and rendering, and reverse I also don't need analytics/dev extensions clutter/slow down non-dev reading experience.

I vouched for you as I don't think you should be down voted for having an option as a developer.

I don't know why others are disagreeing (I assume this is why they down vote), but I am not fond of your statement because it hits a sore spot for me with web devs and users: you like it because it's convenient for you as a web dev. Chrome is anything but better for me as a user.

I've written something like this before but my frustration with web dev and websites in general is that my understanding is that web devs have an unrealistic expectation for how users use their sites and optimize for a use pattern that doesn't match reality.

I might spend a few minutes on any sight for any given day; typically I'm on a Mac so of course I want safari for the battery life benefits. When I encounter a site that is using some chrome only API or tooling and no longer works, I have a decision to make: do I really want to install another browser to view something I might not even look at more than a few minutes just because the site uses a call only chrome supports? Or do I just want to skip it?

So far, the second option has been my choice every time as I just have not found a site that warrants a dedicated browser to view.

For devs the decision is for their convenience, and because web dev doesn't explain its decision, I just have to live with the consequences. This means that a site that works perfectly fine one day,even sometimes a few minutes ago, suddenly stops working because of a behind the scenes change and I have no idea what the issue is, why a change was made, and for who's benefit.

I am not aiming this post at you specifically, it's just such a perspective I find is unique to web dev and to software with rolling updates, but even the latter has release notes. Web dev is weirdly accountable to none of it's audience, and even worse, many web devs choose to argue against the users choice in browser instead of responding and fixing the issues with specific browsers. I'm not even talking about Fringe browsers, just the major ones (FF, safari,Chrome). Even mobile FF gets broken on some sites that try to use chrome only optimizations

Chrome for users is NOT a guaranteed best option. It lacks battery optimizations on most machines, it doesn't support ublock origin, it is incredibly invasive.

The main frustration i have is that if a site does optimize for chrome, it forces a decision that for me is always the same result: will I install chrome just for this site and give up the benefits of other browsers/pay the Google privacy price?

For me that answer is "No", with gusto.

Again this isn't targeted at you, but I really want to ensure web devs see the user side here and the choice they're asking users to make when they optimize for chrome without considering the experience of other browsers.

I'm struck by your use of the phrase chrome only API. As a safari user, that's a term that comes to you naturally.

As a web developer, I feel like there aren't that many chrome only APIs, but there are a lot of web standards safari doesn't support.

I wonder if our two categorisations have a large intersection.

There is definitely many Chrome-only features. Vendor prefixing before standardization is quite common in CSS land. And each browser makes a choice whether to implement certain JS APIs.

Moreover, Chrome is pushing many new APIs faster than any other vendors can implement. Due to governance changes over the past 20 years at W3C, Google and other user-hostile industry behemoths now more or less control W3C and can push many new specs to be "standardized". But not all APIs are created equal: for example Firefox dropped Battery API support because its only usecase was user tracking, so you can essentially say Battery API is Chrome-only despite being being a standard.

Also, although slightly unrelated, as a long-time Firefox user, i know that for some obscure reasons some websites don't work in Firefox, and that Google apps sites are known to act slower when presented with a Firefox user agent. I'm also old enough to remember that when Chrome came out (oh, i miss you pre-Chrome web) Google *paid* website operators to include Chrome advertisement and to make their demos only work via Chrome (once again, via user-agent filtering not via actual features of Chrome that would not be available on other browsers).

I can appreciate that, but my counter is simple:

It worked before, and I have no idea why changes need to be made that aren't universally supported; as a user there is no benefit for me that I'm aware of, and no site to my knowledge deigns to tell me otherwise

That's my point; it worked, then it didn't, and the argument is "get a different browser" (usually they say better). But the question is why did this change need to happen in the first place? Why do I need to change when it's clear that the functionality __IS__ possible with my browser.

It's not about what my browser of choice does or does not support, it's that I'm being told I need to change browsers for functionality that worked perfectly before, and I have no idea why, and instead of being told why, I'm told how awful my browser of choice is despite the benefits it has that I use it for.

I'm sure there's a reason for such changes, or at least I hope there is. But I've never seen a site that ever explained __why__ this was such an essential change that breaking compatibility was an acceptable cost; I'm just told my browser sucks, which isn't compelling.

Edit: to add, I want to stress that it's not a choice for users between browsers that support certain developer features and web features; it's a choice between which browser you spend the majority of your time in for __all__ sites at all times.

When 99.9% of the sites you use daily or weekly work without issue and just one you visit decides to make a breaking change to do the same thing that worked before, it's a very hard sell for me to accept that the browser I'm using is in the wrong. I balancey choice against the benefits my browser of choice does give, the costs of installing another browser, and how much time I really spend on the given site. I know I'm a minority in that I don't use chrome, but the entire issue is unrelated to that; it's about making breaking changes and not explaining any good reason for it, and instead just blaming the browser. If there was even some explanation, at least we could have a discussion on the value of the change.

But missing that, I just see "it worked, not it doesn't, and the functionality is the same. What is the benefit for me as a user?"

> I feel like there aren't that many chrome only APIs, but there are a lot of web standards safari doesn't support.

It may be a de jure standard, but that doesn't sound like a de facto standard.

I agree with you on everything you wrote, thanks for taking time to explain it.

The situation is not great, it's true that for regular users Chrome is basically spyware and battery drain.

I've been waiting for Mozilla to create a better webdev console (or even copy Chrome's) and I'd move instantly.

I do use more than just Chrome (ungoogled Chromium, Edge, Firefox) and I also experience the "regular user" problem when a site is fine in Chrome but not in Firefox so I'm split between two worlds as well, and believe me - I feel your frustration.

You're very welcome. Vouching again as I have no idea why you got down voted.

I really do feel bad that your post was a vaulting point for me to rant, but I do get why a developer would want such things.

I'm not a web dev, so for me, it's just about the user experience and privacy (which as the article shows, no major browser does well out of box).

I'm not Meaning to be hostile towards web dev, but for my company's product, we try to be very transparent about breaking changes. Most software is. Linus even was specific about "don't break userspace".

Thus it's a sore spot for me that web dev bucks the trend here and the answer as to "why" is really not clear for me. Rolling update software is equally guilty here but at least you usually get patch notes...it's still bad in my opinion, but at least you get some idea what's going on.

Funny enough I have to reach for Firefox when debugging some frontends because Chrome devtools don't always keep the payload. FF does.

Ugh, yes. Firefox's dev console is such a pain.

Not only is it painfully slow compared to Chromium, but it sometimes will break on "phantom" breakpoints which cannot be seen or removed, which completely roadblock further work until the browser is restarted.

What's better about chrome's console?

You could have googled and hated better. Why bother trolling if you won't even give it 40 seconds of using search engines?

I'm thinking of an alternative title: "Developer works for free for decades, gets cancelled promptly."

No, it's not ugly. It's necessary. And we don't need any additional tooling around it or yet another thing that "fixes" what doesn't need to be fixed.

If you control domain.com and api.domain.com, then you can create a proxy that glues the two to the same domain, getting rid of any CORS annoyances forever. And you use the tech that exists. The whole problem takes less than 1 minute to type, test, deploy and there's no need for yet another big thing invented to solve a small problem that occurs due to ignorance of self-proclaimed "developers".

Yes it is ugly. How many learners have been stumpped by CORS errors over the years?

But it's also necessary.

I think it has some ugliness to it, but the idea behind it is necessary. The restrictions it places on front-end scripts are currently very challenging to work around, particularly if you're trying to implement a strict CORS policy on an existing website.

It's difficult enough to implement that it probably won't be implemented on the majority of the web - and maybe that's okay.

> And we don't need any additional tooling around it or yet another thing that "fixes" what doesn't need to be fixed

This is what CORS is though.

> I mean, C is probably the simplest tool to write fast software with

The simplicity is the hard part. Fishing for compliments by "pretending" it's so trivial to you shows immaturity.

The author definitely knows what he's talking about. Perhaps it's you who's doesn't?

I did not mean it is 'simple' to write fast C code, but that it is 'simpler'.

Simpler in the amount of knowledge you need to have to write the fast program.

I mean just compare "C the programming language" with Stroustrup's "C++ the programming language". It took me years to understand even a fundamental thing as move semantics. When programming fast C++ you need to be able to see what is moved properly and optimized in the way you want. How classes are inlined into the code etc. What container do malloc on construction, what containers are cheap empty, and so on and on.

There is no such knowledge needed for C.

From what you wrote, it appears you don't know the meaning of "reasonably", "decent", "exception" and that you set your mind to disagreeing with the author before even fully comprehending the post.

"reasonably", "decent", "exception" are contradictory to "speed".

They aren't. But make yourself believe the fairy tale.

- Works 5 years on something he hates - No proof (links, anything) that prove what he's stating - Quits and supports the other vendor, knowing there's internet quarrel between <insert-db-name> vs <insert-other-db-name>, nice going there. Real grown up. - Leaves to work for largest spyware company on the planet

This sounds like one of those people everyone on HN say to avoid in job environment.

Pretty sure most folks with relation database experience outside of MySQL already knew. It's just jarring to hear it from someone who was "on the inside".

MySQL is a 26 year old database engine. 26 years.

MySQL (not MariaDB) started enforcing CHECK constraints only 2.5 years ago in v8.0.16. Before that it would parse them (to make migrations from other DBs easier) but not actually use them.

Or the fact that DDL changes weren't transactional, so a goof up halfway through leaves your schema in an indeterminate state.

How making a temporary table for intermediate transaction state/materialization? (Since after all MySQL doesn't support materialized views.) Oh! You wanted to use that temp table more than once in the same query through joins? Too bad. So sad. One use per, sadly. Just create a temp_stuff_2 table and re-run the original query. MariaDB finally fixed that 5 years ago, but still an issue in MySQL today.

His comments about it not being a state-of-the-art product are well founded and well publicized. https://www.sql-workbench.eu/dbms_comparison.html

If MySQL works for you, use it. But I compare it to something like the original Bourne Shell. It works. It's seemingly everywhere. If all you need is something simple, it can work well. And only folks who haven't used anything else ever think it's anything close to the best out there.

Out of curiosity, how come you dared to make this comment without ensuring you've got all your facts straight?

No, it isn't security through obscurity. Yes, it protects and it protects a lot.

Thank you for contributing to lack of knowledge, do keep up.

This is just not an option for so many very legitimate use cases. Building client-side apps that aggregate and display information from multiple web services hosting on domains totally outside of my control is valuable.

Yes, but in those cases, you aren't the one worrying about cors. The services you use are.