Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're building a browser when it's supposed to be impossible

awesomekling.substack.com

Post reply on HN
Print view View original

101–110 of 349 posts

Re: We're building a browser when it's supposed to be impossible

#101

Post by debevv »

qikInNdOutReply wrote: post #88
yellowapple wrote: post #53

> So instead of [building the browser one feature/spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives. Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the…

Do we really pretend this is a architecture decision? This is the classic Agile Management wants to show result for reward fast, that leads to huge tech debt build up, as layers are not properly designed and reuseable.

Looks like regular TDD to me but tests are well defined real world use cases

Re: We're building a browser when it's supposed to be impossible

#102

Post by nicoburns »

I've been working on CSS Layout as a library recently[0] (we have Flexbox and CSS Grid support so far). It seems to me that librifying everything (much like is already done with JS engines) could be a good approach to making building a new browser engine more accesible.

Because that way any one wanting to build a new one can starting by pulling in a bunch of libraries (layout, rendering, etc), and then just customise the bits they need (ideally publishing them as a new iteroperable library that others can also use).

[0] https://github.com/DioxusLabs/taffy

Re: We're building a browser when it's supposed to be impossible

#103

Post by jonhermansen »

pavlov wrote: post #62
yellowapple wrote: post #53

> So instead of [building the browser one feature/spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives. Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the…

This approach works better for Wine where the Windows binaries are a fixed target. On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again.

Of course you are correct that supporting Twitter or any service is a moving target, so long as it changes. But that doesn't mean specific bugs can't be captured in a test case.

Watch this video of Andreas doing exactly this, albeit for a simpler web app https://www.youtube.com/watch?v=W4SxKWwFhA0

At one point, he deletes half the HTML file to isolate where in the site the problematic code is. In a way doing a kind of binary search. After a few iterations of this, he comes up with a very small case that exhibits the problem he's trying to solve.

It's clear he knows his way around the codebase and where to make changes, but isolating these test cases is probably as important. And presumably if you fixed enough of these issues (while following the specs), 99% of the modern web should work just fine.

Re: We're building a browser when it's supposed to be impossible

#104

Post by thrdbndndn »

tobr wrote: post #50
thrdbndndn wrote: post #30

Others have already mentioned performance is one of the hard part. Another aspect is that for any complex, large-scale project like browser, lots of, if not most of, effort is actually in the long tail: to make 90% or even 99% websites work probably is as hard as making the rest 1%. So while the team probably could cruise through when working on current gen spec and popular sites like Discord/Twitter, it's what left…

Is this something you know from experience or are you armchair guessing? If I recall correctly, the work Andreas did at Apple was mostly focused on performance, and Safari has long had a reputation for excellent performance. Maybe you’ve also done that type of work, but otherwise I’ll trust his judgement.

Could you elaborate your point?

I made a comment about why browser is hard in general. I don't in anyway suggest or imply this team would struggle with performance, so not sure why their (amazing) background would be relevant.

Re: We're building a browser when it's supposed to be impossible

#105

Post by ChickeNES »

ryanjshaw wrote: post #15

What we all REALLY care about: they went with C++ and Qt https://github.com/SerenityOS/serenity/tree/master/Ladybird

I would really like to see a version with a C API capable of being embedded, there's a lot of places where a lightweight HTML renderer would be useful, plus it would make it easier to port to other hobby kernels.

Re: We're building a browser when it's supposed to be impossible

#106

Post by zelphirkalt »

arp242 wrote: post #51
alkonaut wrote: post #20

The fact there are better specs doesn’t help if a large part of the work is handling things that are outside the spec. You better show every “buggy” page similar to how the major browsers show them or the new browser will be considered defective. That’s the unfortunate reality of web tech (I wish every page with an js error or incorrectky closed tag would be a big fat error message but it isn’t). And that’s still a l…

All this "quirks mode" stuff is part of the specification, no? It makes it all a bit more complex than it has to be, but I do believe it's specified. I'm not really sure if "you need to be bug-compatible" is still true; it probably was 15 years ago, but Chrome, Firefox, and WebKit tend to be pretty decent these days.

If anything, websites have become way less clean and invalid HTML. I remember people, including myself, putting W3C validator icons on websites. Rarely do I see any these days, because of all the invalid HTML and dynamically created websites. Maybe all the tags are closed nowadays, so maybe at least that. But which elements are used inside which other elements and whether they are semantically appropriately used is another matter.

Re: We're building a browser when it's supposed to be impossible

#107

Post by dolmen »

aylmao wrote: post #76
rob74 wrote: post #67

Earlier quoted context omitted.

I would say that in 2001, starting a browser engine from scratch was more work than today, because (as other commenters have noted) since then the specifications have become more robust and the "tag soup" sites not following the specs have become fewer.

Moreover, tools are better too. Even if one is still using only vim on the terminal, plugins work better, screens are bigger, code compiles faster, and the internet has better resources for everything from programming and communicating with your team, to just finding music that helps you stay productive, for example.

The Internet also has more social networks to keep you away from being productive.

Re: We're building a browser when it's supposed to be impossible

#108

Post by dolmen »

nicoburns wrote: post #102

I've been working on CSS Layout as a library recently[0] (we have Flexbox and CSS Grid support so far). It seems to me that librifying everything (much like is already done with JS engines) could be a good approach to making building a new browser engine more accesible. Because that way any one wanting to build a new one can starting by pulling in a bunch of libraries (layout, rendering, etc), and then just customise…

Question about implementation: while you are not building a browser (so I expect HTML is out of your scope) are you able to use an existing testsuite to compare your implementation?

Re: We're building a browser when it's supposed to be impossible

#109

Post by zelphirkalt »

Devasta wrote: post #90
rob74 wrote: post #67

Earlier quoted context omitted.

I would say that in 2001, starting a browser engine from scratch was more work than today, because (as other commenters have noted) since then the specifications have become more robust and the "tag soup" sites not following the specs have become fewer.

https://meiert.com/en/blog/valid-html-2021/ Most sites still don't have valid HTML. EDIT: my link is old. 98% of the top 100 sites had invalid HTML in 2021, in 2022 we've managed to hit 100%, great job everyone! https://meiert.com/en/blog/valid-html-2022/

This does not surprise me at all, with all the "must be a web app", still treating HTML mostly as a string in many web frameworks and semantically inappropriately using tags. It is exactly as I thought, the ratio of invalid HTML has become even worse. Probably most web devs these days do not even check their websites for HTML validity, because achieving it with the frameworks they chose is hard or impossible.

Re: We're building a browser when it's supposed to be impossible

#110

Post by Brian_K_White »

Gys wrote: post #98
peepee1982 wrote: post #77

Earlier quoted context omitted.

You can then just set the same goal again. I don't see the problem.

[flagged]

No wise old pro who was actually worth listening to I ever met in any field ever says things like "my young Padawan". Saying that makes you look like two kids in a trenchcoat trying to pretend to be an adult.

Which in this case is not inconsistent with this apparent misunderstanding of what moving goalposts means.

To use your own silly words, targeting the features that are the most used is litterally one way to choose challenges wisely.

Post reply on HN