The fact that this software is so complex is the problem imo. The focus at this point should be on cleanup and simplification instead of feature bloat. Every design decision should consider "what can we delete?"

Complex software is what customers want. A rendering engine for clean, valid XHTML could be very simple. But everyone wants to be able to see web pages created by technically incompetent designers with "tag soup" HTML. There's no point in complaining, that's just the reality of the modern web.

The complexity in modern browser engines has nothing to do with parsing invalid HTML and everything to do with the vast, absurd feature set of the modern web platform, and the complex interactions between the components.

Yeah, if you were to design HTML, CSS, and JS from the ground up today they'd likely look very different.

The bigger issue is backwards compatibility; the web has bent over backwards to maintain it, which is a blessing and a curse. On the one hand it makes the feature set absurd, but on the other hand the web is (relatively) easy to archive since format interpreters for it are widespread, and pages can be built and then forgotten about because they still work.

> Yeah, if you were to design HTML, CSS, and JS from the ground up today they'd likely look very different.

I'd like to see that experiment done.

This is sort of what Flutter claims to be.

Flutter is a GUI toolkit, it's a different use case entirely with some small overlap (flutter can run on the web or could be used to build the front-end for a new browser)

I think he's referring to the fact that Flutter was started as a project, by some of Google's browser and web standards people, to see what the could come up with if they designed a browser from scratch with the knowledge we have today.

This is talked about in a few videos and articles by it's creators.

WASM does seem to be on the road to eventually being a better JS.

I wish WASM was AST based instead of stack based architecture.

What does that statement mean? As far as i know stack VS AST is Apple VS. Oranges. If you meant a register based architecture that would make sense. I don't know is wasm code is verifiable, in which case it's trivial to rewrite it to a register like architecture (like dalvik does for jvm bytecode).

I think we can drop all non-flexbox layout without any degradation in functionality.

You mean grid? I'm suspect you can emulate most if not all of flexbox in grid, but definitely not vice-versa.

> A rendering engine for clean, valid XHTML could be very simple. But everyone wants to be able to see web pages created by technically incompetent designers with "tag soup" HTML.

The HTML5 parsing algorithm is not _that_ hard:

https://www.w3.org/TR/2011/WD-html5-20110113/parsing.html

Do you really think that the complexity of a full XML implementation of the half dozen specs required to implement XHTML would really be that significant a savings compared to the actual features browser developers actually spend their time on?

You're correct that complex software is what people want but that's complex as in an advanced document layout system with advanced language support, rich media, forms, etc. rather than the format those features are implemented in.

That algorithm - for what it is, namely pretty basic tree construction - is absurdly complicated. Did you actually read and grok all that stuff about the stack of open elements, and how all kinds of elements have special gotcha clauses? How you can't nest stuff like `<div>`s in `<p>`s, even in descendants - except in those weird corner cases where you can? And let's not forget that the page you linked to is only one of a few pages you need to parse html; stuff like tokenization also has a bunch of weird, legacy modes, and so on. It's pretty crazy; worse than quite a few programming languages, and they have a conceptually much, much more complex domain. Worst perhaps isn't just the sheer size, it's the haphazard inconsistency. If you don't know all the exceptions, it's hard to predict which part will be exceptional.

Seriously, XML is arguably bad, but html5 is absurdly horrible. The only reason it's acceptable is because it's so widely used that parsers are huge shared projects and most bugs are shallow.

I guess it's all a matter of perspective: sure, you might argue, hey, the spec isn't hundreds of pages, so it's humanly comprehensible. But from my perspective that's a really low bar, and it clears it just barely.

It matters too, because these weird quirks have often hidden things like performance issues, misparses, and security issues due to incorrect normalization.

Again, it's not like there's no work to implement it but … do you think that's more or less complexity than implementing CSS Grids, text layout systems for complex scripts, building a high-performance JavaScript engine, etc.? The browser teams are not shy about saying when they think changes are important for security, performance, or reliability so I'd consider it an indicator that it's not a huge part of their ongoing efforts.

Browser do much more than just HTML5 parsing.

https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_...

Yes, that was my point? Even if it was plausible to switch to XHTML, that’s a small and rather insignificant part of browser code bases.

"Complex software is what customers want."

I think I disagree. Most of my customers don't even want software. They want to watch a movie, or read something, or make some data transform, or something else that is their actual goal.

Complex software is what we make in order to enable them to achieve their goal; perhaps if we were smarter and better, we'd be able to make simple software that enabled their goals.

Much of the complexity isn’t about HTML rendering, but instead about security and device optimizations.

Examples?

Or perhaps more useful: domains / classes of such issues?

I suspect a lot is:

- XHR

- JS generally

- Cookies

A heatmap of problem areas might be interesting.

Update: that's sort of here:

https://www.cvedetails.com/vulnerabilities-by-types.php

I think you hit on the big ones, but also issues around file system access, secure+performant+efficient use of memory across a lot of devices, and complying with an ever-changing landscape of external standards.

Great link!

That would be incompatible with the mantra 'don't break the web', I'm afraid.

There will probably never be another complete new web browser developed from scratch. Browsers are already being supplanted by native mobile apps, wearable devices, voice interfaces, and (just starting) AR / VR. Browser use is still growing worldwide but the trend is toward slower growth. No one will invest hundreds of person years to build a product in a market with declining growth and entrenched competition.

doubtful claim, with all the operating systems being brewed as insurance policy against google pulling a google on android. they will all have their browser too.

Modern browser engines are reasonably portable. When a new OS arrives the developers will just port Firefox or Chromium to it.

Haiku had a port of Mozilla and Web+ is Webkit based, and it still doesn’t have a port of Chromium or Firefox.

I don't get it. Firefox works great, maybe better

Firefox is built on a similar level of effort. Brendan Eich is talking about the effort required for a company to develop a new, full-featured browser engine to complete with Firefox and Chromium.

It may be true that starting from scratch would be impractical, but it might be practical to take Firefox/Chromium and make deep changes, to the point that it's effectively another browser.

Mozilla themselves have been doing this with Firefox. They've been replacing C++ by Rust (with the Servo rendering-engine project). They've replaced the JavaScript JIT more than once, if I recall correctly.

We've already seen WebKit give rise to two divergent major browsers: Chrome and Safari.

The problem is keeping pace with the upstream: it's not that it's impossible but that it's very expensive — when Google forked WebKit they dedicated a large and very talented (i.e. expensive) engineering team to the project. The same could be done again but you're looking at companies like Microsoft, not startups.

The resources needed to maintain a Gecko-based or Blink-based browser will depend on the amount of customisation. Vivaldi/Opera/Brave are doing fine, but they make relatively shallow changes over Chromium.

I just discovered Goanna on Wikipedia, a fork of the Gecko engine, presumably with relatively thin resources. Don't know how well it compares to mainstream engines though. [0]

I suppose the short version is that the workload is a function of the goals.

[0] https://en.wikipedia.org/wiki/Goanna_(software)

That’s the point: if you’re not customizing Blink, you’re not changing the huge influence which Google has over de facto web standards. If you want to make more than simple customizations you need a significant commitment just to keep pace with the upstream – Microsoft can afford that, Samsung can, etc. but it’s not clear that Brave or Opera can.

Mozilla is rebuilding much of an engine with Servo and related (e.g. the CSS bits that are now actually integrated into FF) projects. I can really see them replacing more and more of FF with Rust in the future, because Mozilla really seem to be doubling down on trust, in all forms. For example, they recently announced that the UI is web component based - which means that using Servo for the window chrome is in the realm of possibility.

Edit: at that point I wouldn't really consider it "FF of yore." A rewrite is really a new product.

Firefox has been using Gecko for chrome since before it was even called Firefox. It's pretty much the reason why the Google browser has the name that it does. Anyone contributing to Firefox leading up to the birth of Chrome, including major contributors on Google payroll, dealt with chrome:// documents (or bindings, or scripts, or...) on a daily basis.

Yeah, but that was via XUL, not via web standards.

That's orthogonal to the comment I was responding to.

Your response to my comment isn't only orthogonal, it isn't even in the same realm of what I was talking about. I was referring to "the window chrome." I never once mentioned "Chrome."

The comment you called out is directly related to what I was talking about, it is not orthogonal.

You can't rewrite history. SahAssar's comment moved the goalposts away from being about the browser engine and towards whether XUL was standardized. Whereas your comment is undeniably about using the browser engine to handle the Firefox UI—which yes, I grasped—although you seem not to have grasped my (incredibly straightforward) response to it, which contained an aside about how Chrome got its name.

I'll repeat myself: Firefox is already using the browser engine for its own UI, and that's been the case—I'll repeat again—since before it was even called Firefox.

I'm not sure what you are trying to say, but the parent comment said

> they recently announced that the UI is web component based - which means that using Servo for the window chrome is in the realm of possibility

IMO some of the key words there are "web component" and "Servo":

1. IIRC you can't render XUL strictly with web components or anything that would be called "web", since that usually refers to web standards or something you would use from a webpage but not included as a standard (non-standardized extensions, flash, silverlight and so on).

2. Regarding the Servo part, I don't think that Servo ever included XUL support at all. Servo isn't used wholesale as the rendering engine in firefox, but the parent comment talks about the possibility to use it and web standards for the browser chrome.

I feel like you are responding to a comment that never was and then responding to a comment on that comment by saying the original comment was something you thought it was, but it wasn't.

Funny, I feel the exact same way.

> IIRC you can't render XUL strictly with web components or anything that would be called "web"

> use [Servo] and web standards for the browser chrome.

Geez, this is excruciating.

If you want to use web standards for the browser chrome, this is not a new development. Because Gecko supports web standards. And Gecko has been used for the browser UI for years. There is nothing particular to Servo here. There's nothing particular to Rust.

Using standardized web tech for the "window chrome" is not "in the realm of possibility". It is possible. Full stop. It has never not been the case.

I'll happily "loose" this whatever this discussion is if I'm wrong (but the "win" reference is now removed from your comment) but the basic idea is:

1. Servo supports many web standards, not XUL

2. The firefox UI used to be built in XUL

3. The firefox UI is now not built on XUL, but rather on web standards

This means that the firefox UI can now be rendered by servo or similar components.

That's basically the parent comment. If you disagree with any of those facts that's an interesting discussion, but I think you think that somebody said that the firefox UI could not be built on gecko previously, which nobody said.

So what we're dealing with here is Mitch Hedberg's "I used to do drugs" bit, only you're not joking.

Android put Chrome over the top.

Firefox worked great for a few months after the big fuss over Quantum coming out and then went right back to just being a browser for enthusiasts and privacy activists. And that's after that whole dumb advertising push they did with billboards reading scary stuff like "Big Browser is watching."

If anything, Firefox is a good example of why it's probably better for aspiring browser competitors to start off by just spinning off from Chromium like Brave did. Not that Brave is perfect either, especially not on desktops, but the saved resources let them focus on finding ways to surpass the competition like improving the mobile ui.

Turning Firefox into a Chrome copycat* with built-in blocklists and Tor Browser Bundle features certainly didn't make it gain more users. Mozilla should've left Brave occupy that space. Brave, Pale Moon and Vivaldi deserve praise.

* References:

1. https://www.dedoimedo.com/computers/firefox-suckfest.html

2. https://www.dedoimedo.com/computers/firefox-disable-australi...

3. https://www.dedoimedo.com/computers/firefox-directory-tiles....

[Edit (fixing link)]: 4. https://www.dedoimedo.com/computers/firefox-addons-future.ht...

The thing costing Firefox users is the billion-dollar advertising push and heavy promotion on Google properties. That won’t be changed by trying to satisfy a small number of critics who are not exactly jumping to contribute significant effort to the project, whereas the Mozilla team inevitably has solid answers about maintenance costs bashing their decisions.

Well, apparently IE has a thousand developers for a few years, so it should still be possible for a megacorp.