Hacker News new | past | comments | ask | show | jobs | submit login

I think this is just too many people. No matter how you spin this it’s just too many. Do Google or Microsoft have half as many working on their browsers? I’d be very surprised if they do. It should also be interesting to look back and find out how many people Netscape employed at its peak. I would love to know the distribution of those 1.2k people ( engineers, marketing, whatever ). Of course, it’s likely that I am too naive or clueless.



There isn't public information on this, but in the past I have heard that Chrome had a lot more engineers than Firefox (though it's a bit difficult to make direct comparisons because of scope differences). I suspect that's still true. I also heard the same thing about Edge at one point, but I suspect that may not be true now.

Comparisons with the past are meaningless because browsers are far more complex (and performant, and secure, and versatile, etc) than they used to be.

And sorry, but your gut estimates are not likely to be that accurate if you don't work in this area.


> There isn't public information on this, but in the past I have heard that Chrome had a lot more engineers than Firefox (though it's a bit difficult to make direct comparisons because of scope differences). I suspect that's still true. I also heard the same thing about Edge at one point, but I suspect that may not be true now.

Scope differences make it incredibly hard.

Plenty of people on the Blink team work on things like Skia, which neither the WebKit nor EdgeHTML teams have equivalents of (because they just leverage OS-specific APIs), or on their HTTP/TLS stack (again, neither WebKit nor EdgeHTML teams have equivalents of), etc.

Gecko is somewhere in a middle-ground; they rely on third party libraries (including Skia—does that make that part of the Chrome team Blink/Gecko developers?) but not quite as much as WebKit and EdgeHTML do.

Core web stuff? The Blink team is larger, yes, but by how much is a hard question.

FWIW, I believe the Gecko team is nowadays larger than the EdgeHTML team, but they're certainly close in size. (And close to the size of the old Presto team, which admittedly had a scope closer to that of the Blink team.)


Gecko also has its own infra/productivity/etc folks, whereas I bet these folks are from a much larger shared team at the big companies


The Chrome team has a lot of its own infra due to policy that a lot of Chromium stuff be public (its bug tracker system now code.google.com is dead and its CI infra are all done by the Chrome infra team).

I imagine to some limited degree it's true for WebKit (though I suspect they don't have anyone whose sole job is infra) given Apple don't have any general public bugtracker or CI system, and totally untrue for Edge.


I never worked on a browser, though I did implement the HTML5 spec, twice, and I wrote a JS engine(compiler, runtime). I know that it was a lot easier because I could count on infromation and other advances that were available to me, and anyone else really, at the time, the kind of resources and information I probably wouildn't have had access to it("whats javascript?") 20+ years earlier.

Browsers have evolved - because standards did, and expections along with them, but in the past they too were quite complex(see also Netscape's play: browsers, email, usenet client etc, suit) and again, it was harder then that it is nowadays to build such systems.


Which part of the HTML5 spec, though? A parser? Or the whole thing, including DOM APIs and all the features like media elements and so on?

Even an HTML5 parser is harder than it looks to implement to the level needed for a browser. You have to build a proper DOM, you have to be secure against all kinds of fuzzing, you have to implement off-main-thread parsing and speculative readahead for performance, you have integrate it correctly the HTML5 event loop for document.write() etc, you have to support innerHTML and so on.

Likewise building a JS engine is impressive, but I do not believe a Web-compatible competitive-performance JS engine can be built by any single person.


I feel like there's a tendency to put browser developers on a pedestal. Browsers are large and complicated, and no, a single person cannot write a browser competitive with Chrome from scratch. On the other hand, a single person can probably write a browser competitive with Dillo, if they are sufficiently motivated. Browser developers are just as competent and incompetent as other professional native programmers. There are several HTML5 parsers out there. JS engines are also relatively abundant, especially if you will settle for an interpreter. You can build such things yourself, too, if you have the time and want to hone your skills.


There's a huge amount of fairly boring work to write a DOM implementation (if you want half the APIs the web expects to work with the right semantics, you can't use an existing library), and layout is incredibly hard to get right (especially in a web compatible way). I think it's totally doable for a single person to do HTML + CSS2.1, with no scripting support, especially if you're happy to leverage existing libraries.

The big difference with most existing browser developers is the majority know a lot of the web platform inside out—but that's mostly a matter of having worked on an implementation for a long time and having to worry about edge-cases and interactions no web developer would ever think of. There's certainly a few who have achieved a huge amount for individual developers—but that's not a trait unique to the browser sphere.


The parser. Once for properly parsing HTML content, for a search engine, and the other for a framework used for saving pages (For an Instapaper like service). So it wasn't a big deal, but in both cases, a DOM was constructed and operations were executed against the DOM.

Nothing about that or the JS engine is impressive really. That was my point, more or less. Of course, there's a difference between building something that works, and something that works exceptionally works etc etc(all the stuff on top of that), but all told, I still don't think building a browser justifies assembling such a huge org, even if there is no reliance on third-party technologies.


Implementing an HTML parser is not hard—the spec is a book of instructions on what to do.

Implementing a fast HTML parser that will produce a fast DOM is a little harder.

Tying it in with a fast CSS engine is harder still.

Tying it in with a JavaScript engine is a bit more work as well.

Implementing layout is moderately fiendishly difficult to do and get right.

And it just gets harder the more of the web platform you add, and the more it has to be fast.


HTML5 parsing is maybe 1% of the HTML5 spec.


However many people Netscape employed is irrelevant, browsers now are very different in complexity and security than browsers in the Netscape era.


On the flip-side though, the tools, expertise/skills and means for building browsers some 25+ years ago don't match what's available today.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: