One legitimately great thing about LLMs is that it makes it feasible to add these kind of tracing instrumentations temporarily for profiling and then throw them away so they never reach source control let alone production.
I can get an LLM to trace my incomprehensible Tokio application which was also written by an LLM, which is why I don't understand its behavior. Truly the future we were promised.
I guess you should adopt RFCs or ADRs to help clarify the Tokio application, like this https://github.com/brunoarueira/thoth-mesh/tree/main/docs/ad.... This project is vibe coded, but I had put the effort to create issues, roadmap and ADRs, so later I can understand the project without going deep on the code!
There's a huge push for this from the big companies adopting Rust. Google has been developing https://github.com/google/crubit. The older cbdingen is still usable if more limited (it's what Firefox uses for some pretty involved interop).
> how is an actual html, css and javascript specification implemented at the code level? are we painting an empty canvas or is it more complicated
It's more complicated, but conceptually it's painting into an empty canvas
> how is backward compatibility implemented?
> what test cases do you consider for making something like this? how do you determine if you have handled all the outliers or not?
The ~2 million Web Platform Tests https://github.com/web-platform-tests/wpt. They also handle most of the backwards compatibility. The rest is engine developers manually comparing against each other's engines.
> is all the code written in c++ or is it rust these days?
There's still a lot of C++, but new code is increasingly Rust. To what degree varies by engine: Servo (and Blitz) are almost entirely Rust. Ladybird was 100% C++ in February, but is now 25% Rust. Firefox has significant and actively developed core components in Rust, but isn't actively converting more core modules. Chromium doesn't have any core components in Rust yet, but has invested heavily in converting foundational dependencies like FreeType and HarfBuzz to Rust. Safari is the outlier, I believe it doesn't use any Rust yet.
> how many people in a team do you need and how long would it take to write a browser engine from scratch
I've heard estimates that Chrome has a team of >1000, Firefox 500-800, Safari 100-200, Servo / Ladybird are more like 5-10. I've been building Blitz by myself for ~3 years. Something like 3-5 years is probably a minimum if you're truly building from scratch unless you have a really large team backing it, and depending on your success criteria.
> how is mobile vs desktop handled at the browser engine code level?
There are actually surprisingly few differences beyond touch input and screen size handling.
I'm more surprised how cheap it is in browsers because I know it's not that easy - they are really really good at it. Pure text rendering is therefore rarely an issue.
For those interested in how the alternative browsers are doing, I just put up an alternative to https://wpt.fyi (displays the WPT test results of each browser) which is IMO easier to navigate, and shows Servo / Ladybird by default:
So Ladybird is catching up with the other pretty fast! Although it's worth noting that it still has a bunch of extra work to do with regard to performance.
(my engine Blitz whose website this is on scores 42.2% for specifically the `css` subset, compared to 50.3% for Servo and 72.3% Ladybird)
(the results above exclude the `encoding` suite, because that's 1 million test ~50% of the whole suite, that doesn't really measure rendering capability).
I love WPT (I even have a bookmark comparing all of these browsers as well as Flow[0] that I check regularly).
But this is absolutely NOT how this site is meant to be used. For example, Ladybird jumped from about 30% to over 70% when it added a bunch of unicode logic. Secondly, these tests aren't all even officially agreed upon standards. Some are specific to Chrome features that are still in the draft stages for W3C. Many tests are written by the developers of the engines themselves. Chrome, having a larger team, will naturally contribute many more tests relevant to whatever feature they're prioritizing
> But this is absolutely NOT how this site is meant to be used. For example, Ladybird jumped from about 30% to over 70% when it added a bunch of unicode logic.
That's true, but you can dive into specific categories to get a more accurate picture and also see which sets of tests are only implemented by Chrome.
FYI I was able to vibe code "enough JavaScript to run the css part of WPT" in about a week. Might not work so well if you don't have a DOM or incremental rendering though, but could be worth looking into.
thanks, i was already looking at this. Most of my skipped tests are reftests with script tag inside, and big part of that script just builds the dom. Thats doable without a real js runtime.
Blackboard is definitely a really strong contender for the worst software I've ever had to use. When I was in uni, I went so far as to write an alternative that scraped the content from blackboard and published it on a site that I could actually browse sensibly.
They were paying exorbitant amounts of money for the license too.
Applications like Blackboard exist because of the genre of "Checkboxware."
A University must comply with Laws and Regulations X, Y, Z, P, D and Q and a host of other regulations the University never heard of and Blackboard went through the process to "comply" with those checkboxes. So, if you deploy Blackboard, you tick all the checkboxes automatically.
The fact that Blackboard was a garbage content management system and a terrible grade recording system was irrelevant--because the "better" systems wouldn't check the boxes.
(I say this as someone who, as a lecturer, had to manage the account logins, mailing list, and Subversion source control system for an entire class. I only ever put grades that needed to be "secure" into Blackboard. I did all that because I HATED Blackboard that badly, but it was a LOT of work. And I probably wouldn't have passed any significant security audit; although my accessibility ratings should have been excellent since everything was plain text and plain HTML)
It's not really regulation-driven. It's just what happens when the people buying software and the people using it are different. This is the standard problem of enterprise software is marketed to the IT department (which cares about cost, box-checking, vendor relationships, lock-in risk, bureaucratic turf wars, headcount preservation, SLAs, etc) with little or no regard for responsiveness to end user needs.
It is definitely true though that enterprise software for nonprofits (like education) sucks even harder than usual, because nonprofit IT departments don't even have the profit motive to align IT department and end user interests.
Users don't choose their university by how good that university's software is (just as we don't choose apartment complexes and power companies this way). This gives university IT no incentive to deploy software that doesn't suck.
Banks and cellphones also used to work this way, until they suddenly didn't, which was quite a shock to the existing players in the market.
Part of it is also that universities mostly already tried building their own bespoke software in the 90s using 90s era technology and development practices, and got bitten by ending up with legacy software that they couldn't afford to maintain.
reply