Hacker News Reader

Comment by kalenx | Hacker News Reader

Sorry, but a team of 50 persons in total to support a project as complex as Firefox is not reasonable speculation at all.

View on HN

Is it? I feel that people vastly overestimate the actual number of competent programmers (not managers, CxOs, etc) many projects need.

Consider that even here on HN we have one person who wrote their own HTML5 renderer, JS-like scripting language, CSS, etc from scratch (csmile). How do you figure that to go from that to what is needed to make a browser that renders sites properly you need to add more than 49 additional programmers?

Can you link the HTML/CSS engine you mentioned?

Its not just about the code though. Somehow that code needs to keep up with the latest standards and magically be delivered to my client device. To think that a project as complex as the Firefox ecosystem can be maintained with less than 50 engineers doesn't match my experience working on large product teams.

Here's my estimate:

* A dozen build engineers to support development and builds for X client platforms

* A dozen engineers for the Javascript VM

* Dozens of engineers to support ongoing javascript and CSS standards

* A dozen engineers or more to support the firefox core

* Dedicated teams for Android, MacOS, Windows and Linux targets

* Dozens of Team/Programme/Project managers to _enable_ devs to do their best. These folks aren't optional.

* UX designers

* Graphical design artists

* Technical writers

You work on large teams, so your estimates are for large teams. Smaller teams work faster and can get more done with less. Basic "Mythical Man Month" stuff.

I'm not saying you're wrong. Just that you might not be right.

All these "dozens" are exactly what i mean with people overestimating what is needed. You throw "dozen" around like crumbs on pigeons.

> * A dozen engineers for the Javascript VM

> * Dozens of engineers to support ongoing javascript and CSS standards

Fabrice Bellard is a single person who in his free time has made a full modern JavaScript engine. Key parts: single person, free time.

I call bullshit that you need "dozens of engineers" to make a JavaScript engine - what you need to good engineers (and to ensure they stay around).

Sciter doesn't even come close to a fraction of what Gecko or WebKit offers or does, and it still took the author many years to get to that point, so I'm not sure what you're trying to get at. The "JS-like engine" is an excellent example. It turns out, you need an actual JS engine to run real websites, not a "JS-like" engine. The difference between 80% and 100% of that problem is massive, and it also turns out running that fast is a ridiculously complex project on its own. (And, unsurprisingly, the recent Sciter FOSS Kickstarter announced that it would pivot to QuickJS instead. It might be educational to think about why they would do that.)

This doesn't even get into things like translations, technical writing (manuals, help pages, etc), infrastructure needed to actually deliver updates and downloads, collaboration on web standards, etc.

> Sciter doesn't even come close to a fraction of what Gecko or WebKit offers or does

It is close enough to show that a web engine can be made by a single person even if it doesn't fully adhere to the standards and its functionality is certainly not less than 1/49th of what you'd need to go there.

> The "JS-like engine" is an excellent example. It turns out, you need an actual JS engine to run real websites, not a "JS-like" engine.

Fabrice Bellard has written (among many other things) a full modern JavaScript interpreter, again showing you do not need a "dozen" people (like another commented mentioned) to make such an interpreter.

Yeah, as someone who wrote a good chunk of a CSS layout engine (Servo) I can confidently say that this comment demonstrates a huge lack of appreciation of what the scale of work involved is.

Reply on news.ycombinator.com