[HN Gopher] Chat with Andreas Kling about Ladybird and developin...
___________________________________________________________________
Chat with Andreas Kling about Ladybird and developing a browser
engine
Author : samwillis
Score : 139 points
Date : 2023-07-06 18:18 UTC (4 hours ago)
(HTM) web link (www.igalia.com)
(TXT) w3m dump (www.igalia.com)
| MatthiasPortzel wrote:
| Just yesterday I was thinking about Ladybird, and I claimed that
| it was a fool's errand, for reasons I'll explain in a bit. What I
| didn't know is if Kling recognized what he was doing, and was
| just not taking it very seriously, or if he was way over his head
| and was kind of oblivious.
|
| I enjoyed reading this interview because it makes it very clear
| that Kling has a lot of experience doing this, and understands
| that's it's difficult, and is doing it because he enjoys it.
|
| The reason I don't think Ladybird will ever really get to the
| point where it can render an arbitrary site perfectly, is based
| on my experience as a web developer. I haven't been doing web
| development for very long, but there have been a couple times in
| the last couple of years where I've stumbled upon browser layout
| bugs where Chrome/Firefox/Safari render something different.
| These are normally not issues where a browser completely misses
| something (ie, every browser supports flexbox these days).
| Rather, there are edge-case bugs that appear just by combining
| simple web components in simple ways. Chrome and Firefox handle a
| table with percentage height differently. Or a margin on a child
| which is larger than the parent's width. And these are bugs that
| have existed for years. And for every edge-case like that where
| Chrome and Firefox differ, there are 10 more where the behavior
| is unintuitive or not defined by the spec but Firefox and Chrome
| have standardized.
|
| But maybe, since Ladybird doesn't have an existing buggy
| implementation, they'll be able to implement the spec properly
| quickly the first time. I think that's an interesting perspective
| that Kling brings up in this interview.
|
| The other thing I want to comment on is that it's really hard to
| tell how much progress they're making.
|
| > We've taken a very vertical slice approach to adding
| functionality to the browser... We tend to find a webpage that we
| want to improve for whatever reason. Maybe it's cool to get the
| New York Times to render, and then we just spend a bunch of time
| fixing as many issues as we can for that site... And that might
| not be the most structured approach to it, but it has been very,
| very good at keeping people motivated and excited and engaged in
| the work
|
| This means that Ladybird "supports" a ton of features. They
| support flexbox! They support grid! But pretty much all of these
| features are only partial implementations. Kling says in the
| interview they support svg, and then later explains that they're
| going to have to re-write the text-rendering system to get text-
| on-curves working. Well, to me, "supports svg" means "we have
| implemented the entire svg specification." When Kling is using it
| to mean "we have some portion of svg's work. We don't crash when
| we see an svg element." I'm not saying Kling's definition is
| wrong, but it's another factor that makes it difficult to judge
| where the project is.
|
| To start to wrap up this (long) comment, let me restate the four
| claims I'm making. (This is not the conclusion, this is the
| summary before the conclusion, hang on.)
|
| * Ladybird is developed differently in two ways: vertical slices,
| and being implemented from scratch in modern times.
|
| * there are people who are misled by the vertical-slices and
| Kling's use of "support" to believe that Ladybird development is
| a lot farther along than it is.
|
| * There are people like me who think that Ladybird will never
| complete with existing browser engines (we also have a hard time
| judging Ladybird's progress for the reasons stated above).
|
| * These same reasons may allow Ladybird to reach compatibility
| with other browsers.
|
| I have a lot of respect for Kling, and I think it's cool that
| they've been able to accomplish so much "for the fun of it". As
| mentioned in the interview, this will have short-term positive
| impact even if it never matches Chrome. If it wasn't clear from
| how long this was, I'm actually really enthusiastic about the
| project, and I'll be looking at ways to contribute in the future.
| seti0Cha wrote:
| You should check out his browser hacking videos. It's pretty
| shocking how much they have already and how fast it's
| improving. I have no doubt they will eventually be able render
| the vast majority of websites correctly. The real question is
| whether they will ever be able to make it performant enough
| that people who don't care about browser hacking will choose to
| use it. That's where a lot of the engineering hours in browsers
| goes.
| _gabe_ wrote:
| > The reason I don't think Ladybird will ever really get to the
| point where it can render an arbitrary site perfectly, is based
| on my experience as a web developer. I haven't been doing web
| development for very long, but there have been a couple times
| in the last couple of years where I've stumbled upon browser
| layout bugs where Chrome/Firefox/Safari render something
| different.
|
| So what does perfect even mean in this context? Who's right,
| Chrome, Firefox, or Safari?
|
| I 100% believe Ladybird will eventually be able to render
| arbitrary sites in an acceptable format at some point
| (potentially within the next year or two). It's pretty
| remarkable how many sites look very close to acceptable
| already. Any weird edge cases where Ladybird renders stuff
| differently from a big browser won't mean it's rendering the
| site "imperfectly"; just like how when Firefox and Chrome do
| different things, it doesn't mean either one is "correct".
| samwillis wrote:
| This is a really insightful conversation, it's so interesting how
| much success they have had by "just"* translating the html/css
| specification directly to code. The "debugging" of the docs that
| this is achieving is so valuable. Other larger browsers are going
| to also gain so much from all this insight.
|
| Well worth a listen!
|
| Slight aside, Andreas has had a bunch of donations and sponsors
| in the last month (over 300k), and just today announced he has
| hired a full time dev to help on the browser engin:
|
| https://twitter.com/awesomekling/status/1676896595936198657
|
| > _Thrilled to announce that I 've hired @KalenikW to work full
| time on @ladybirdbrowser_
|
| > _Alex has been with the project since last year, and already
| done great work on CSS layout, testing infra, and more. Lately he
| 's digging into JS performance and making great progress!_
|
| * massive understatement
| olliej wrote:
| It's really important - and people seem to be unwilling to
| recognize - the huge amount of work done by browser vendors
| 10-15 years ago to actually make the specs usable for the
| purpose of implementing a browser (the whatwg work and es3.1
| were all about actually building out correct and complete.
|
| The w3c specs, and similar era es specs could not be used to
| implement a browser, and a lot of the browser engineering work
| of the time was basically trying to find site breakage and then
| reverse engineering whatever gecko and/or trident did. It meant
| things that today might take just a few hours to implement by
| following the spec could take weeks. At one point I spent a
| month working out what the correct behaviour and sequence of
| events should be fired when pressing keys on a keyboard because
| what the specs said both under specified what should happen,
| and also was just wrong in some edge cases. It was a truly
| miserable era, and the people who seem hellbent on bashing
| whatwg and what not for some perceived slight remain absurd to
| me.
| ahartmetz wrote:
| That's interesting. The people working on these specs seem to
| be doing an idealistic work even though their employers'
| interests are more to keep their moats from having the, more
| or less, two only "HTML engines" viable on the modern web. Is
| it really idealism or are there interests at play that I
| don't know about? Is that stuff too low level to be used as a
| competitive advantage?
| zgluck wrote:
| Around 2004-2007 most of the key web specification writers
| (From WHATWG; Hixie, etc, etc)
|
| a) were employed by Opera Software
|
| b) were surprisingly young (often around or even below the
| age of 18)
|
| Then Google poached most of these people (from their
| partner; Opera had by then invented the placed browser
| search engine business model for them; allegedly Google is
| paying Apple $15B/yr these days.)
|
| A few years later the scope of the web started growing in
| an insane manner, spearheaded by Google.
|
| This later period was also the same time that the web got
| deeply javascriptified and largely turned from documents
| into apps that you download and execute. Before that it had
| been documents with sprinkles of javascript.
| placesalt wrote:
| Wasn't one of the lessons of The Mythical Man Month that
| building from a spec produced good software? That was talking
| about System/360, my recollection is that most of the effort
| went into creating a very detailed and internally consistent
| specification/manual for the system. Implementation followed
| the spec, and the results were long-lasting and solid.
| bch wrote:
| It's also "conventional wisdom" that (especially?) with the
| web, there's The Way It Should Work, and then there's The Way
| It Actually Works, which is all the quirks, etc.
|
| I've not completed an entire server or browser, so not
| speaking from implementation experience, just the word on the
| street.
|
| Is that stale information now?
| favorited wrote:
| > Andreas has had a bunch of donations and sponsors in the last
| month
|
| I believe that Igalia was the source of $100k of that! Awesome
| that they, as an open source browser consultancy, can give back
| to projects like Ladybird.
| ushakov wrote:
| What would be their incentive to shell out 100k like this?
| Appreciation?
| rstat1 wrote:
| Of the 3 announced, 2 of them were anonymous and the 3rd was
| Shopify.
| favorited wrote:
| Oops, that's embarrassing. I must have been thinking of
| sponsorship for Web Engine Hackfest...
| DylanSp wrote:
| There's an Eric Lippert post from a few years back about
| working on the C# compiler, where he followed a similar spec-
| guided approach, with simpler benefits for both making the code
| clear and making sure the spec was reasonable:
|
| > [...] I wrote all the conversion logic in Roslyn, and I did
| so for the most part by carefully following the specification.
| This had two purposes; first, to be sure that I was
| implementing the actual specification, and second, as yet
| another chance to ensure that the specification made sense. For
| much of the conversion code I have methods where each method
| implements one line of the specification, for this reason.
|
| https://ericlippert.com/2015/05/26/a-different-copy-paste-er...
| placesalt wrote:
| (Irrelevant post, but this was a missed opportunity for an
| article with the title "Kling on Ladybird")
| [deleted]
| zgluck wrote:
| > Google throws hundreds of engineers at this [building Chrome]
| and they have full-time people working on it around the clock.
|
| It was many hundreds already about a decade ago. I haven't done
| any recent research (the Chromium Git repo is where you'd get the
| source data to analyze), but I assume it's in the (several?)
| thousands now.
|
| Edit (ran into some problem replying to the comment below):
|
| An in-depth analysis performed today would need to consider that
| some of the active chromium.org committers are working on non-
| browser-related things like Chrome OS.
|
| That said, I'm assuming 75+% of active chromium.org committers
| don't work on those non-browser parts. I also consider the Chrome
| Web Store a part of the browser - but I can't imagine that
| needing lots of _developers_ in comparison to these large
| numbers, even when you start thinking about the abuse aspects.
|
| Having said that, it should be easy to filter out those by just
| discarding certain directories.
| mike_hearn wrote:
| Last time I looked the 7 day active committers was about 750.
| So with holidays, people who don't commit for a week, PMs and
| other management etc, my guess is around ~1000 people, maybe a
| bit more. I doubt it's several thousand. Maybe if you include
| ChromeOS?
| zgluck wrote:
| Thanks! That is still a lot to compete with, but it's not
| that much larger than what they had a decade ago.
|
| And loads of them were certainly working on mostly homegrown
| web standards that went nowhere.
|
| I think Kling and his growing crew has a shot here.
| kevingadd wrote:
| The way lots of things are integrated into "Chrome" as an
| organization and a product definitely means a lot more people
| touch something you can call "Chrome" now. Chrome OS, Chrome
| Web Store, etc.
| andrewstuart wrote:
| Chrome and Firefox are absolutely gargantuan in terms of their
| functionality and also the decades of fine tuning.
|
| Building a new browser seems akin to building a Saturn V rocket.
|
| To be practical at all you'd have to lop gigantic trunks of
| functionality off it.
| samwillis wrote:
| I'm not sure I agree with this metaphor but it's too tempting
| not to propose:
|
| Labybird/LibWeb is to Chrome/Blink as Saturn V is to SpaceX
| Starship...
|
| Not sure where that puts Andreas, hence my hesitation.
| jklinger410 wrote:
| An observation shared by many.
| amadeuspagel wrote:
| [flagged]
| pipeline_peak wrote:
| [flagged]
| SalmoShalazar wrote:
| Are you saying this with conviction? There are 2 full time
| people working on this and hundreds of volunteers. I think
| it's going to become a "functional" web browser within the
| next year or two.
| dizhn wrote:
| What happened here? I don't get either of these two comments.
| pipeline_peak wrote:
| OP pointed out the irony in saying there's no better time
| to build a browser when the spec documentation is more
| advanced.
|
| I took that as it's more difficult because the specs are
| more advanced. Andreas might've meant there's more
| information provided by browser documentation.
|
| If that's the case, I disagree because Google practically
| leads by their own standard through usershare. so they're
| free to move the goal post.
| seti0Cha wrote:
| I think Andreas' point is that although there are more
| specs and they contain more details, they are far less
| ambiguous so that a careful reading allows one to achieve
| correct functionality without guesswork. Since he's
| worked on browsers for many years, I'm inclined to
| believe him.
|
| Also, if you watch his browser hacking videos, you can
| actually see this play out live. He finds a layout
| problem, searches for the relevant spec, and reads
| through until he finds which detail was missed. He then
| literally copies that spec chunk into the code, then
| conforms the code to it. I find it fascinating to watch
| and I think justifies his claim.
|
| As for Google moving the goal posts, if you read through
| the interview, you can see he's not interested in
| following bleeding edge, he's interested in the
| solidified parts of the spec that people actually use
| today.
| foobarbaz123456 wrote:
| [dead]
| Vinnl wrote:
| I'm looking forward to the Servo-Ladybird browser wars.
___________________________________________________________________
(page generated 2023-07-06 23:00 UTC)