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

51–60 of 138 posts

Re: Web Browser Engineering (2021)

#51

Post by FartyMcFarter »

systems wrote: post #40

why python, why not a system programming language like C, OCaml or Go (or newer languages like zig or odin) Are web browsers, not considered to be "system software"

They definitely are system software, since they include compilers and interpreters, software libraries and other such things which AFAIK have always been considered system software.

Browsers these days are about as complex as any operating system, or perhaps more complex when you consider all the non-systems stuff in them.

Re: Web Browser Engineering (2021)

#52

Post by btown »

mike_hearn wrote: post #35
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 inter…

Another thing you can feasibly do is implement flexbox or a similar useful subset of layout! https://www.yogalayout.dev/ is one such library that powers React Native. Letting people bring CSS intuition when writing greenfield code for a simpler engine can be a great way to onboard users.

Re: Web Browser Engineering (2021)

#53

Post by mnutt »

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…

As of 2024, WebKit's Linux ports (GTK and WPE) are switching to Skia too. [0] Prior to that, they used cairo.

[0]: https://blogs.igalia.com/carlosgc/2024/02/19/webkit-switchin...

Re: Web Browser Engineering (2021)

#54

Post by wslh »

Is there a promotional code for HN? I was a happy user of HTMLUnit [1] with Jython [2] in the past and am very interested in a future where we can automatically generate portions of browser code using code generation and verification techniques. I've never felt as comfortable with tools like Playwright/Cypress/Selenium as I did with HTMLUnit (with all due respect to both).

[1] https://htmlunit.sourceforge.io/

[2] https://www.jython.org/

Re: Web Browser Engineering (2021)

#56

Post by jgwil2 »

mananaysiempre wrote: post #12
mmkos wrote: post #10

Earlier quoted context omitted.

With all due respect, this feels better suited as a journal entry rather than a comment on a HN thread.

Perhaps, but it would have been of little use as a question there. Once you acquire enough of a feeling for a foreign language that not every bit of your skill in it comes from somebody telling you that a particular thing is said in a particular way, you are doomed to live with a constant suspicion that your feeling is somehow off in a way you don’t recognize. Usually it can be suppressed and ignored, but sometimes i…

I'm not sure about your point about "leveling" vs "leveling up", because for me, "leveling" means making a surface level/flat and does not have any video game-related meaning, but the "on" is probably coming from the phrase "to read up on" something (meaning to study/read about something; there's also a slangier variation, "to bone up on" something).

Re: Web Browser Engineering (2021)

#58

Post by pjc50 »

pstrateman wrote: post #34
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.

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

I don't think that's true, and it's even less true once DRM video is involved - it becomes very difficult to get other software on the machine to even see the video, at least on Windows. You can very occasionally see bugs where the hardware accelerated playback ends up in a different place to where the browser thinks the video should have been put, too.

What does happen is the video data gets reassembled in Javascript (e.g. Video.js) because the native player doesn't support HLS. Not quite the same thing. It's just reformatting MPEG-TS to the similar but not identical MP4. Oddly, the browser in my LG TV does play HLS video natively, and I think Safari does?

Re: Web Browser Engineering (2021)

#59

Post by paulddraper »

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…

> I challenge anyone to keep the whole CSS spec and its associated behaviors in their head.

Lol, no way.

People are always "guess what JS does, wut."

Doesn't hold a candle to Cascading Stylesheets.

Post reply on HN