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

91–100 of 138 posts

Re: Web Browser Engineering (2021)

#91

Post by pavpanchekha »

fouric wrote: post #62
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…

Layout is so difficult that it made me quit using Common Lisp and ncurses to build my passion project and become the very thing I swore to destroy (a React developer). I can't be the only one who wants a simpler layout language than CSS that's designed with two decades of hindsight to provide the maximum simplicity-expressiveness product. Are there any serious projects to engineer something like this, or has everyone…

Author here, and I also teach web dev, including CSS, at the University of Utah (including this semester). Newer parts of CSS, like flex-box layout are both simple and powerful. Just use those! I think it's important to start thinking about learning all of the Web Platform like you'd think about learning all of the Windows APIs or all of the Linux system calls or all of your favorite programming language's features. People rarely do! (I have 15 years of Python experience, and I do not understand metaclasses or async.) There are lots of weird obscure corners, but you don't need to know those to build websites.

Re: Web Browser Engineering (2021)

#92

Post by jm4 »

aitchnyu wrote: post #13
jm4 wrote: post #11

This looks awesome. About 15 years ago, I started working on a headless browser and maintained it for several years. It used SpiderMonkey as the js interpreter and had a custom DOM implementation. It ran all the modern js from the time, AJAX, etc. Later, I added a custom Flash runtime. It basically did everything but draw to the screen. That project was a lot of fun. I'm definitely interested in going through this bo…

Umm, if you wanted/want to draw to the screen, what library will you use?

I didn’t have a clue. That wasn’t part of my skillset. All we needed was a headless browser that was automated. It was crawling a few million pages a day. I had a debug console where I could see cached pages, headers, cookies, etc.

Re: Web Browser Engineering (2021)

#93

Post by abixb »

adhamsalama wrote: post #57

Would be nice to have the option to download it as an epub to read it on my e-reader.

My thoughts precisely. I wish there was a service that could convert book-length webpages into neatly formatted ePUB document. I did find a 'converter', [0] but the service has tons of room for improvement.

[0] https://www.freeconvert.com/webpage-to-epub

Re: Web Browser Engineering (2021)

#94

Post by vivzkestrel »

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.

have you by any chance looked into alternative browser engines such as servo, ladybird, goanna, netsurf, sciter, flow etc?

Re: Web Browser Engineering (2021)

#96

Post by msie »

vbezhenar wrote: post #45
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…

This Babylonian tower will crumble one day. Layout does not have to be so complex. There are dozens of GUI frameworks with simpler layout system. Those are enough for applications everyone uses.

Pixel positioning is so nice! I remember how easy it was to layout UIs with VB.

Re: Web Browser Engineering (2021)

#97

Post by amjoshuamichael »

pmarreck wrote: post #42
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.

Or perhaps an entirely new platform/protocol, since this one is completely saturated with complexity at this point.

I keep coming back to this idea as the (albeit ideal) future of the web. HTML keeps morphing and changing to fit the increasingly complex requirements of modern web apps. I mean the W3C spec is 114 million words (1). I think that web apps as a concept are a good idea, but I just can't believe that HTML/CSS/JS are the best technologies to fill that out. I'd love to see someone tackle a new, "micro-sized app format", with a much simpler document format, and something like a FORTH as a scripting language. Uxn (2) and Decker (3) are good examples of this, but obviously a proper implementation would have to be built with the full range of possible UI and accessibility in mind, not just monochrome bitmap displays.

A web standard so simple, anyone can implement it!

One can dream...

(1) https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... (2) https://100r.co/site/uxn.html (3) https://internet-janitor.itch.io/decker

EDIT: There is Project Gemini (https://geminiprotocol.net/), but it doesn't support styling or scripting.

Re: Web Browser Engineering (2021)

#98

Post by throwup238 »

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…

Modern CSS implementations are full blown geometric constraint solvers now. The only things approaching their algorithmic complexity are now other geometric constraint solvers like CAD kernels and silicon layout software.

Re: Web Browser Engineering (2021)

#99

Post by pstrateman »

afavour wrote: post #50
pstrateman wrote: post #34

Earlier quoted context omitted.

> 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.

> not usefully true with most videos on the web today > The only time video is fully hardware decoded is when it's a simple video element to a static video file. These seem in disagreement to me. The vast majority of videos on the web are simple video elements going to static video files. It is not usual for each frame to pass through JavaScript before being displayed.

Most of the things you think of as static video files (say youtube) are actually video segments operating more or less exactly the way live streams work.

Re: Web Browser Engineering (2021)

#100

Post by hinkley »

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 did layout for a feature phone browser. WAP and mercifully XHTML-basic’s ideas of layout was simple enough that I could treat spans as a concave octagon - a rectangle with a bite out of the upper left and lower right corner. It made it at least an order of magnitude faster to paint and scroll a long document, and much simpler to think about.

In the years since I’ve used a lot of tricks for web app CSS that I’m not sure I’m smart enough to figure out. But then I’ve never thought as long and as hard about typesetting as I did at the time so who knows.

Post reply on HN