[rstefanic]

> Our next major challenge: We are dealing with 21 million lines of code.

I think I just fail to understand the true complexity of a browser, but how is Firefox 21 million lines of code? How can a browser be 21 million lines of code? That just seems so large for what a browser does.

[kryptiskt]

A browser lays out text and graphics (for any script in any locale), does GPU accelerated 3D rendering, handles network communication, plays video, plays audio, provides accessibility, parses a bunch of languages, compiles a couple of languages to machine code run in a security sandbox (and has a separate optimizing compiler), provides database storage, implements a plugin system, provides support for 25 years of legacy standards. And a bunch of more things.

[ken]

It also reimplements all of those things itself from scratch because their priority is on cross-platform parity, not efficiency.

Every time I see someone working on a FF bug I’m cc’d on, I marvel at how many files they have to touch to get anything done. One key binding missing, because they’re not using the system text field? Hundreds of lines of diffs, spread across a dozen source files.

[jdlshore]

I think you’re underestimating what browsers do. They have an incredibly performant and highly-tuned VM, an extremely flexible and powerful layout engine, a comprehensive set of media players, and that’s not even talking about networking, security, and UI.

[mrmonkeyman]

This seems to scream "separate me!". Why is it acceptable to put all this responsibility into one giant ugly ball? We desperately need separate layout engines, parsers, renderers, etc. Assemble-your-own-browser.

[snazz]

Because the entire advantage of the web from the perspective of the end user (as opposed to desktop applications) is that you can expect it to work the same everywhere. If everything were separated, it wouldn't make a difference, because Chrome and MobileSafari will continue shipping one integrated stack, even if they're forced to open up APIs for modularity.

What tangible advantage would this have? Having competing browsers seems possible, but since end-users wouldn't be choosing individual browser components anyway, it wouldn't actually improve anything.

[aspenmayer]

It sounds like a good idea to be implemented by a technical user, and a solution looking for a problem to every other kind of user. I thought dependency hell was bad but this sounds like a further circle of such hell. I like that I can tell a user to just update their browser and OS and be confident that most users will handle the operation thereof. I know how to tell a non-technical user how to update their web browser in words they can understand. I’m going to have to write a new script for how to explain the scope of the limitations of using a web browser as a compiled application versus the proposed modular architecture just so they can tell me they don’t want or need that.

Choice matters. Sometimes you have to make a choice on behalf of your users. I think that’s what the industry as a whole has done here. Nothing is preventing people from rolling their own modular web browser. Maybe things like Beaker Browser and TOR Browser are versions of that same idea but approached from a specific use case.

Thanks for this comment. I think your idea is good but not for the same reasons that a web browser suite is a good idea for most non-technical users.

https://beakerbrowser.com

[thinkharderdev]

It doesn't seem that crazy to me. Calling them web browsers is kind of anachronistic at this point. Just the JS engine itself seems like it would be massively complex. It's a VM with a JIT compiler which I can only imagine is quite cumbersome to implement securely

[vkou]

Having worked on codebases that are more than 10 million LOC, I'm surprised that Firefox's functionality fits into such a small amount of code.

[NikolaeVarius]

What doesn't a browser do these days.

[gen220]

Email! For now ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html

[snazz]

It does effectively. With Gmail at least, there's an option to register Chrome as the mailto handler. Anytime you click on a mailto link anywhere on your computer, it will open Chrome to the compose window in Gmail. And Gmail works offline, so it's not really any different from having a traditional email client built into your browser.

[2fifty3]

remember Opera and Seamonkey (and Lotus Notes) back when the all-in-one email/browser/cal/notes application concept was still kicking

[rhinoceraptor]

> all-in-one email/browser/cal/notes application concept

You mean Emacs? All it needs is a good editor :)

[spyridonas]

Chrome is 25M, so they are close. Yeah i think its too much as well.

[the_arun]

Seems like modern day browsers are not just HTTP Client, they are close to an Operating System. But still surprised by size of LOC.

[aschatten]

Modern day browsers are essentially VM with rich customizable GUI.

[skohan]

This is something I really deplore about the state of modern software development. Taken collectively, it's mind-boggling the amount of waste there is in terms of memory and CPU (i.e. energy) usage by running a huge portion of consumer software in the browser. We could achieve the same result so much cheaper, with better performance and UX, by putting a serious effort into a set of standards for handling code from an arbitrary source securely.

[Epskampie]

> a set of standards for handling code from an arbitrary source securely

That is what html+js is. Why do you presume a different standard would be more efficient in the end?

[skohan]

HTML+ECMAScript keeps the developer at quite a distance from the hardware, and it imposes all kinds of limitations which don't have to exist.

The web is good enough for pure content delivery, but for more advanced interactive applications, the limitations are a huge waste. For instance, I have a computer at home with a 12-core, 24-thread processor, but web applications are basically single-threaded with some very limited support for web workers. I'm also limited to basically one language, which is garbage collected, so performance and memory usage are significantly worse than they could be. And as far as graphics, you're limited to WebGL which is ages behind the state of the art in terms of graphics APIs.

Basically there is a whole universe of tools out there for software development, but if you want to target web you're limited to a handful of poorly performing, hacky options.

For my work, we use several web applications to collaborate. As someone who works on highly optimized user-facing software, it's frustrating to understand how poor these web applications perform given the potential of modern hardware.

The reason we use them is because you can send anyone a link, and they're into the software in one click. There's no reason we couldn't have the same experience for native software, where when you click the link your computer downloads a native binary and runs it in a sandboxed environment against a standardized system API. It would take a lot of careful work and planning, but there's no technical reason it couldn't exist, and it would be so much better for developers and users.

[Epskampie]

But if it were to run on every platform and processor the binary would have to be written to some VM, which would slow it down a bit. That’s webassembly, which is coming up.

Also, there would have to be some GUI framework that works well across all devices, phone to desktop. That alone would be massive undertaking.

I agree there is no technical reason, but once you consider all limitations and let some time pass in the end you might up with something similar to what we have now. For example you might standardize on a current graphics API, but in a few years: guess what, you have an outdated API like webGL now.

[skohan]

> But if it were to run on every platform and processor the binary would have to be written to some VM

Not necessarily. You could have different binaries for different architectures. All you need is a consistent system interface with a well-specified ABI, and the client would just have to request the binary for their architecture.

> That’s webassembly, which is coming up.

Web assembly still has the limitations of running inside the browser. It's still single-threaded, and also the file size is pretty large compared to a binary.

> Also, there would have to be some GUI framework that works well across all devices, phone to desktop.

If you had a consistent system interface, you'd only have to do it once.

> For example you might standardize on a current graphics API

I mean Vulkan is basically this. And graphics API's are converging not diverging: modern graphics API's are all structured in a very similar way, since they're all just wrappers around the low level functionality of the GPU at this point.

I'm not saying it would be easy, but the reasons we don't have it have more to do with the fact that it would be difficult to get buy-in from OS vendors than it has to do with the technical problems involved. From a technical perspective, we could easily do way better than modern web.

[random32840]

JS is generally very fast because these monolithic VMs have had so much money poured into them that their optimisation process is unparalleled. V8 can sometimes get performance on par with C. "Overhead" is arguable, JS may be garbage in a lot of ways but modern JS is quite efficient.

[skohan]

sometimes is the key word there. It's amazing what kind of performance can be reached with JS given the monumental amount of effort which has gone into optimizing it, but there are structural reasons JS hsa a performance ceiling. JIT compilation can't change the fact that it's a highly dynamic, weakly typed language which is garbage collected. You might be able to find examples where a JIT compiled block of JS code performs comparably to a similar block of C code, but there are design patterns available in languages like C/C++ and Rust which aren't even expressible in JS which allow an extremely high level of optimization using careful memory management techniques.

Also web is basically a single-threaded runtime environment. For the foreseeable future, increased parallelism is the main way we can expect to get increased computing performance, and it's basically not available on the web.

[why_only_15]

The biggest thing you would probably be sacrificing is development time for every engineer involved. The html/css/js stacks have had unimaginable amounts of manpower invested, more so than any UI stack in history. This has made them much easier to learn and manipulate. Throwing away all of that would be a very hard sell.

[skohan]

I agree there would be an adoption problem for something new. But if there were a viable alternative, and people managed to build killer apps on it might be possible to draw adoption over time as people got to experience the superior performance.

[oreally]

This LOC count is going to be a huge problem in the future, and you'll see it as the bug count climbs. It'll be hard for people to understand how the system works and hard for them to ramp up. You'll see the slow decline if there's ever a point in which their funding is reduced and employees have to be laid off.