Hacker News Reader

I agree with what you're saying that it's not exactly what we're seeing which makes it not as simple.

However, I've seen this play out in many a big companies where there's a big mess going on. Answer is always similar pointing to -> "clearly it's not simple" and that's kind of the whole point. They made it not simple. 3k ENGINEERS, my sweet dude. THREE THOUSAND. By any and all account that's half as much as current chrome team or in total if you account for open source contributors as well. If robot is to believed that's also a headcount of windows and macos core teams. What is even going on, I don't even..

Taxes, compliance, regulatory bodies, logistics multiplied by X countries X products has an amazing way to bog you down. If you have money and problems money solves (eg you could hire more people to do something) you do not have a problem (except for people on the internet making arguments from personal inexperience)

> If you have money and problems money solves (eg you could hire more people to do something) you do not have a problem

If you have money there's a greater chance that someone in that X by X matrix might see you as a juicy target to go after so your expensive handling of every item in that matrix needed to be better still.

I get that, I truly do since I see it all and every day. We're talking engineering hands here though. Presumably programmers and infrastructure and SRE.

I think there is something like Parkinson's Law: "Work expands so as to fill the time available for its completion."

This is more like the engineering team scales to match your budget.

It is why successful companies, when starting out and getting to their defining project completion state have significantly less engineers then 10 years later when they are massively more successful.

The cost of having the engineers is nothing compared to the profits, so why not hire more so you can defend your position. Are 80% of them needed to keep the system going, I think Elon showed that you can prune most of them away and the system will keep humming along (ignoring some initial problems). The trouble is bureaucracy, lack of technical knowledge at the top, and the hazy difficulty of identifying what is needed is really difficult, and if you mess it up, you could ruin a billion dollar business to save a hundred million dollars in salaries.

That is the crux of it. You can't know who to cut, and even if you are really good at it, you will still create problems and create ill will. Elon was pretty successful, but it did have some momentary problems. If his negative cult of personality didn't get in the way, it would have been better off.

Twitter is an empty shell though. Yes it technically works, that’s about that.

I certainly wouldn’t go anywhere near Twitter these days, but the question is how much of that is to do with engineering failures and how much is to do with the overall change of culture and moderation practices that Musk has introduced.

Very much this. If you have 3000 engineers (and all the associated non-engineering roles that inevitably come with that) then you have guaranteed that no problem will ever be easy to solve. Possibly you might be able to solve some extremely difficult problems that you couldn’t solve with fewer engineers.

> When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations.

It also was reusing the WebKit browser engine, work on which started in the 20th century (as KHTML)

As to Shopify needing zillion of engineers: does their backend query seller APIs? If so, I expect many of their engineers work on keeping that working.

And Chrome doesn't even need to support millions (billions) of users on a single, coherent "system". There's no scaling, it's just people running it on their computers and phones.

I suspect the vast majority of Shopify engineers never touch the core Shopify experience, but work on the long tail of invisible things that are nevertheless considered important. I'm talking along the lines of "direct integration with bank X for UPI in India to save 0.3% on payment costs in scenario Y."

And, importantly, this was 2008.

Most of the modern software tooling you have today wasn't available back then, from great IDE's to popular libraries, writing software in 2008 was a different beast compared to today.

Tja, besides LLMs I can't really see the major improvement todays IDEs and language combination brings over Eclipse+Java. Great docs, good autocomplete, good compiler feedback.

Yes, IntelliJ 8 was out in 2008. From my experience most of the progress since then has been keeping up with language and library updates.

When Visual Studio (not VSCode) incorporated a time travel debugger, that felt like a major advance in an IDE. I don’t remember exactly when that was, but I think it was around 2013.

I am still a little stunned by the rapid adoption of VSCode over IntelliJ and the original Visual Studio. Maybe being free was the important part, but I still chafe at the idea that we should configure our tools using JSON instead of just, you know, buttons and checkboxes.

Of course, VSCode and its ilk are jam packed with AI stuff I don’t not want, so it is mostly back to a fancy text editor for me.

Sounds like you're describing the shit show that is web development

Wasn’t Chrome mostly a wrapper on Webkit, though? You had to add the engineers who worked on Safari and KHTML before to the count..

DevOps and infrastructure, Security. Internal tools is correct, but speed, video quality as well as sound seems so easy. Google is responsible for many compression algorithms and standards - byproducts so to say. And they are top notch.

I have insights into the matters, and a lot goes into behind the scene optimization. Some specialists in the pre-AI phase were tasked to do nothing else but optimize build tools but in the sense of tweaking every millisecond out of it. This guy saved Google Billions over the years.

Others work in compiler building etc.

There are a couple of hints in the books by Google engineers but I am regularily blown away during meetings what really highly inspiring things are there to discover as well as presented.

Another factor: Google is spread around the globe. Regulation, law. Believe me, having over a billion users per app is mindblowing.

And it is 24/7/365. And support. And research.

Google is a company I admire. Technical provess at its finest.

And it was a fork.

5% is insanely generous for the YouTube example.

Rubbish. Most of the stuff you’re listing is handled by OS and frameworks themselves, you don’t need hundreds of SE to handle RTL or a11y. I work in one of those companies, most people just regurgitate existing shit into another form of shit and collect salary (not complaining, as I’m one of them, but let’s be honest).

This is plain wrong. For a browser, a11y doesn't just get handled by the OS automatically. In general, claiming a11y is easy or will be done by someone else is bordering on evil.

The original Edge had to switch over to Chromium because it was hard to build a compliant accessible browser from scratch and this is Microsoft we are talking about.

> ...this is Microsoft we are talking about.

Exactly!

More seriously, it not just about building a compliant web browser engine, it is about tracking the dominant browser engine which introduces their own "standards" along the way too.

Microsoft could have easily continued to invest in maintaining their browser engine, but it would have to be comparable to what Google is doing, and yet they'd always be perceived as "behind" due to non-dominant position they have.

I'd say strategically they do not want to invest in tech that's not winning (in marketshare), so when they are not dominant, they'll instead adopt and extend (not just web browsers, look at WSL too).

The didn't had to, MS Browser team was incompetent from the beginning of internet

Oh the memories. Took them forever to introduce something as simple as tabs that virtually all other competitors had since years.

File explorer was the same, only recently it got tabs.

https://news.ycombinator.com/item?id=18697824

> one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up

> build a compliant accessible browser from scratch

Which is not something even Google ever succeeded. They had a significant head start due to Webkit being open source.

We live in a time now where libraries are free and plentiful and pretty good. It is easy to forget that this was not the case for the vast majority of time that computers have existed.

Chrome’s original design definitely predates our current rich ecosystem. Plus, V8 and Chrome’s performance profile are demanding enough that there would be a pretty high bar for those dependencies anyway.

> We live in a time now where libraries are free and plentiful and pretty good.

Specifically what are you talking about here? Chrome is c++ I thought?

Chrome was invented in 2008. Abseil[1] didn't exist publicly until 2017, derived partly from Chromium.

HarfBuzz wasn't ported to C++ until 2010. I don't know the entire constellation of libs Chrome would use if it was designed in C++ today, but I bet a lot of them didn't exist before Chrome or were even created partly as a downstream byproduct of Chromium.

In other ecosystems: if Chrome were designed in Rust in 2008, there would be no crates.io to pull from. There would be no NPM, since Node followed V8/Chrome's invention in 2009. Maven Central had ~50K packages in 2009[2], which was a lot back then. In 2026, Maven Central hosts over 3 million.

[1]: https://github.com/abseil/abseil-cpp

[2]: https://mvnrepository.com/repos/central

I think you've come from an npm world because c++ still doesn't have a great library ecosystem if thats what you mean.

> In other ecosystems: if Chrome were designed in Rust in 2008, there would be no crates.io to pull from. There would be no NPM, since Node followed V8/Chrome's invention in 2009. Maven Central had ~50K packages in 2009[2], which was a lot back then. In 2026, Maven Central hosts over 3 million.

Yeah, this is all web development stuff.... Doesn't apply to c++

A browser isn't drawing its content using OS frameworks, so A11Y is a major undertaking. Much more so because A11Y for web content specifically is a bit of a different beast than native widgets, and the amount of stuff you have on the web these days means that you have to pay a lot more attention to performance.

Okay, since it might’ve been confusing from my comment: I meant mobile apps, not Chrome or browser. Mobile frameworks abstract all of this.