From the article, it looks like the optimization effort wouldn't go to XUL.
> Nobody was realistically touching XUL layout code if they could avoid it. Part of it was just a matter of priority (we’d rather make the web faster for example).
We're hitting the same situation with Javascript, which in theory should be slower than most static languages, yet the sheer amount of work and optimizations done to its engines make it faster in real world tests.
Basically benchmarks like these:
https://medium.com/deno-the-complete-reference/deno-v-s-go-h...
https://programming-language-benchmarks.vercel.app/typescrip...
To note, the first link has a follow-up with Go properly getting faster than deno when fitted with a better http server. Which is kinda my point: the tooling available and level of optimizations can easily have more impact than the language's inherent speed.
Er...citation needed?
All the benchmarks I have seen, particularly real-world, show it to be significantly slower than static languages.
For example:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
See also:
https://sealedabstract.com/rants/why-mobile-web-apps-are-slo...
Abstracted code is bloody slow by its very nature, but devs of the 21st century love abstraction so we get software that run like drunk walruses on 16-core processors with hundreds of gigabytes of RAM.
In the worst case, a feature test would be a cache miss, requiring a read from main memory. That's somewhere in the ballpark of 50ns. So, you could test 1000 different flags, every single one being a cache miss, and you'd still be 100x faster than what humans can generally perceive. In reality, almost all of those reads will be cache hits unless you're doing something pathalogical, so you're probably talking on the order of 100ns for the whole lot.
For example wxwidgets apps do tend to feel non native on some platforms (especially Mac), but they're not slow. I remember GTK+ when it used to run on Windows about 20 years ago wasn't terrible. I think OpenStep on NT was pretty good -- iTunes on Windows seemed to be doing a similar thing, too.
It's the wrong abstraction that makes it suffer.
Around 1996 I tested on Linux a Java app that rendered everything in Java using IFC from Netscape. The speed of its UI was on pair with a native app using Motif toolkit despite the usage of images.
The dichotomy is also too vague a concept to be anywhere useful as a proxy for performance. This very thread is a good example. I don't see how XUL is more "native" than HTML is, but some see otherwise.
The only reliable way to reason about performance is to look at what the code is actually doing.
... and having the chrome performance depend on that infrastructure is significant incentive to do that caching and other pipeline cleanups.
(At the very least, having one fewer UI toolkits to maintain will let Mozilla engineers focus their efforts).
And for something like the browser chrome, the cache could even be serialized during compilation and loaded in to prime it when Firefox launches.
It's possible to build a slow CSS engine and it's possible to build a fast CSS engine.
It was then roughly flat through 2020 despite slowdowns from Spectre mitigations.
Pretty much all the “bloat” you’re probably complaining about happened in this 6 year span - flexbox, grid, CSS animations, ES2015+, etc. and the browser got faster.
This would run in parallel with the existing one and would trigger based on some meta tag or something, kind of like I understood asm.js did.
Maybe also pair it with some work on the JS engine to limit the JS engine significantly for such documents by only allowing a low number of JS operations pr user input. We already have something similar (although admittedly imperfect) today for audio were a web page can only play media as a response to a user action I think.
Would this be for every website? No, strictly opt in, but if it succeeded those who did would have significantly better performance.
And with time, maybe we'd see people asking themselves: why isn't this news site available as htmlcore? And maybe it becomes a competitive advantage.
But back to rendering Firefox: Such a limited, high performance form of html could maybe also be a better way to run Firefox UI? If necessary with whitelisting of certain parts that would need to run JS without the limitations I mentioned above?
You mean native widgets on whichever system?
Probably not possible; you still need to do all the computations of CSS and layout before drawing an actual widget on the screen.
The reason that HTML elements are rendered slower than native might be due to all the processing that has to go on to figure out what each widget should look like and where on the screen it must be placed for each frame that is rendered @ (say) 60fps.
And the reason you have to continually do it for each frame is because it may change due to CSS animation, or javascript which adds/removes new widgets, or javascript which changes the CSS for that element, or the widget might be reparented or removed, or a user event might cause different properties to trigger on the widget (changing the actual width, changing the opacity/color, etc).
And of course, the renderer then has to propagate the changes down to child widgets for all properties that are inherited, and propagate all events upwards, for all events that a generated.
Native widgets are generally quite customisable as well, but it rarely happens at runtime and so they perform better because each widget is not continuously changing its properties at runtime.
XUL was not used for forms in the html frame.
<div style="overflow:hidden">
<input type="text" />
</div>
display: -moz-box;
The box model will no longer function once the patches that this blog post describes make it into a release, but XUL elements themselves are still around.
It is. Because you don't draw rectangles in HTM/CSS, it's not low-level enough for that.
You have a system that was designed to display one page of text in one pass that has complex contradictory layout rules grafted on top of it. So now if you even look at it funny it needs to re-layout and re-draw the entire page.
There's a reason why you still can't animate height:auto
/s
This is going to sound odd, but I've started to notice odd things starting to arrive I never ordered. Stuff like treatises on Colonialism, Ethics books, Books on Management Theory, and Theory of Labor Value.
Honestly, I'm starting to wonder if this an HTML CSS layout generator or some sort of malware. I think I'm going to shut it down. Oh yeah, I had to write this bug report on a different network than I hosted that system on because I kept getting null handler buttons popping under the mouse but over the Submit button any time I tried to click Submit.
Y'all might've actually created SkyNet. And I think it's justifiably pissed.
XHTML 2.0 and even 1.1 was a very good opportunity to throw all that away.
https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
Certain versions of HTML thus declared, incorrectly formed doctypes, or more often the absence of the doctype declaration altogether, would tell most rendering engines to enter Quirks Mode and render the page with backwards compatibility as the highest priority.
Um, we still do that. It's just that the doctype for HTML 5 is very short and doesn't mention the version number explicitly. (It's `<!DOCTYPE html>`.)
W3C dropped the ball with XHTML 2.0 though, which, rather than just simplifying syntax, attempted to innovate using wildly unproven features such as XForms.
HTML 5 eliminated vendors big (MS) and small (Opera). I guess unless we want to assume Opera were digging their own grave by actively engaging in HTML5 and WHATWG, we have to conclude HTML parsing wasn't the hard part next to the complexity of CSS layout (with the boom of responsive layout in the smartphone era) and competitive JS performance vs Chrome's v8 engine.
As someone who was around the WHATWG from relatively on, and worked at Opera over the period when it moved to Chromium, I'd strongly suggest that HTML5 was a _massive_ win for Opera: instead of spending countless person hours reverse-engineering other browsers to be compatible with existing web content, things like HTML parsing become "implement what the spec says" (which also implicitly made it match other browsers). Many of the new features in the HTML5 spec of that period were things that either were already basically supported (in SVG especially) or were relatively minor additions; I don't think they played a significant role either.
There's a good reason why Opera was heavily invested in the WHATWG, and it's the fact that by having a spec implemented cross-browser defining how to parse HTML and how cross-page navigation works you eliminate one of the biggest competitive advantages more major browsers have: web compatibility, both through legacy content targetting the browser specifically and also web developers being more likely to test in those browsers. (And to be clear—this would've been true for any form of error handling, including XML-style draconian error handling; but the long-tail of existing content needed to be supported, so even if major sites had migrated to XML you still needed to define how to handle the legacy content.)
The downfall of Presto is arguably mostly one of mismanagement and wrong priorities decisions being made; I don't think Presto was unsaveable, and I don't think the Presto team was so significantly under-resourced it couldn't compete.