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

Web Browser Engineering (2021)

browser.engineering

Post reply on HN
Print view View original

31–40 of 138 posts

Re: Web Browser Engineering (2021)

#31

Post by 01HNNWZ0MV43FF »

currygen wrote: post #24

It's refreshing that browser engineering seems to become a "trend" now. The ecosystem is quite sparse with basically only Google, Apple and Mozilla defining it. I'd like to see forward into a future with more independent browser engines.

Something that uses less RAM would be nice. Other than that and the spyware from Capital-G Google Chrome and Capital-M Mozilla Firefox, I don't have a problem with it being sparse. It's millions of hours of de-duplicated work.

I'd like an alternative to HTML though. If I was to make a browser maybe I'd focus on replacing HTML because I can't stand it, and replacing js just because the runtime is heavy.

Like, a browser that only runs wasm and has nearly no JS runtime would make me giggle

Re: Web Browser Engineering (2021)

#32

Post by mannyv »

One great thing about this book is the 'stuff I didn't do' part.

Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head.

At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today.

As an aside, video decoding is offloaded onto hardware, so it's not as battery intensive as it used to be.

Re: Web Browser Engineering (2021)

#33

Post by 01HNNWZ0MV43FF »

mattlondon wrote: post #28
DavidPiper wrote: post #18

Earlier quoted context omitted.

I'm one of those ~nobodies. Firefox is actually quite good these days, I use it at home and at work, 100% of the time - i.e. no Chrome or Safari fallback needed. If anyone's looking for a reason to try a switch again, consider this your sign.

Is the performance hit sorted yet when opening a page? For me Firefox used to hang for a second or two doing something? Just a blank screen with the progress bar paused around 20% or so and apparently nothing happening...(DNS? HTTPS handshake?) and then it would kick off and load normally. Happened on mobile(android) and desktop(windows, Linux, macros). On chrome-based browsers the same pages on the same computers on…

Sorry to say but I've never seen that bug

Re: Web Browser Engineering (2021)

#34

Post by pstrateman »

mannyv wrote: post #32

One great thing about this book is the 'stuff I didn't do' part. Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head. At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today. As…

> As an aside, video decoding is offloaded onto hardware, so it's not as battery intensive as it used to be.

This is technically but not usefully true with most videos on the web today.

The video decode itself is accelerated, but each frame passes through JavaScript to be composited.

The only time video is fully hardware decoded is when it's a simple video element to a static video file.

Re: Web Browser Engineering (2021)

#35

Post by mike_hearn »

currygen wrote: post #24

It's refreshing that browser engineering seems to become a "trend" now. The ecosystem is quite sparse with basically only Google, Apple and Mozilla defining it. I'd like to see forward into a future with more independent browser engines.

I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.

The interesting space is really post-HTML UI/document tech. There's another thread running about Typst which is a sort of better LaTeX. Markdown was highly impactful. There's a lot of scope for people to do interesting things in this space that are "HTML but better". It doesn't even have to be a markup format - Typst and React HTML both blur the lines between code and data. Jetpack Compose shows how to use Kotlin's DSL features to make something that looks a bit like a UI description but which is actually code.

Of course it means you have to then either distribute a 'browser' for your format, or find a way to display it in the browser. But compiling down to some JS/HTML/WASM thing is certainly possible. You can also use portable GUI toolkits like JavaFX; that also gives you accessibility. Or do both!

Once you define your own UI language there's a lot of scope to try things that HTML doesn't do well. An obvious one is separation of content and style. HTML tried and never really got there. XSL:T tried harder but was a weird pure functional language with XML as its syntax. React does quite well with going JSON->boxes but the underlying protocols are always ad-hoc and tacked on, so you can't really write useful tooling on top of that.

Another idea would be a format that's natively immune to XSS.

Re: Web Browser Engineering (2021)

#36

Post by sylware »

mannyv wrote: post #32

One great thing about this book is the 'stuff I didn't do' part. Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head. At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today. As…

yep, namely noscript/basic (x)html.

Re: Web Browser Engineering (2021)

#37

Post by pmarreck »

lesuorac wrote: post #17
skeeterbug wrote: post #15

Earlier quoted context omitted.

I believe Chrome uses Skia

Yes [4]. > [1] The library is used as of 2023 in Google Chrome, ChromeOS, ChromiumOS, Mozilla Firefox, Mozilla Thunderbird, Android, Firefox OS, Flutter,[5] Avalonia (from Alpha 4), LibreOffice (from version 7.0) and RAD Studio[6](since version 12.0). > [2] Changes to the Skia repository will be rolled into Chromium by the AutoRoll bot several times per day. > [3] It serves as the graphics engine for Google Chrome an…

Whoa. Somehow I have not heard of this. Can this be used to make cross-platform GUI apps?

Re: Web Browser Engineering (2021)

#38

Post by pmarreck »

wmanley wrote: post #14
_benj wrote: post #9

It is so exciting to see material like this being made! Browsers seem like mysterious, undecipherable black boxes, which is very likely how G wants them to be perceived, but that is cracking by seeing the efforts/results of such projects like ladybird and others! I hope to one day be able to jump in and contribute to break that moat! And this books looks like an amazing start!

> I hope to one day be able to jump in and contribute to break that moat! The moat isn't caused by a lack of non-chrome browser engines, it's because so few people use a non-chrome browser engine. Firefox already exists - it's just that ~no-one uses it and for websites that don't work with it those users have learnt to just open up chrome. I'd love for the moat to be broken, and contributing to a browser engine like…

Firefox is great. I use Nightly. Sync bookmarks and everything. Chrome completely unnecessary.

Re: Web Browser Engineering (2021)

#39

Post by pavpanchekha »

mannyv wrote: post #32

One great thing about this book is the 'stuff I didn't do' part. Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head. At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today. As…

Yes, layout is difficult, especially because (I think):

1. The most "core" parts of layout, like CSS 2 stuff, is pretty poorly considered with a bunch of weird features that interact in strange ways. (Floats and clearance? Margin collapsing?) Some parts of this "core" were intended to be universal even though they're a bad fit for other layout modes. (Margin and padding, for example, don't have a clear purpose for say grid elements.)

2. It's not well-modularized the way JS APIs are. A JS API can often be implemented fairly stand-alone, but each layout module interacts with every other layout module since they can be nested in various ways. I think newer specs like grid are trying to be stricter with this but there are fundamental challenges: the actual 2D screen is a shared resource that different layout modes must split up.

Post reply on HN