|
|
|
|
|
by maxbond
1369 days ago
|
|
> [I]f "large project" is what gets you into (various) troubles, then you should avoid doing this. This makes perfect sense and I do agree. But I also wonder what you would say to someone writing, say, an operating system or a browser? Projects that are inherently large and where the stakes of errors are high. I do think you need great safety and abstractions to raise your complexity ceiling to the level of these projects, if that's what you've set out to do. |
|
Browser are the typical case of a project/product that became bloated over time; they began as relatively simple document downloader and viewer, but now they are also application downloader and execution environments. This causes all kind of problems for users and implementors. The answer is somewhat eye-rolling: we should go back to Flashplayer times (with something better than FlashPlayer though). Let browsers handle HTML/CSS, and delegate everything else (PDF, big media files,...) to dedicated applications chosen by the end user. One can still do that, indeed, except it has become more and more difficult - even for simple text-and-images documents - because websites are abusing Javascript capabilities.
"we have to handle complexity better" is the common way of thinking, and I think it is wrong as a first reaction. Trying to lower the complexity first is better.