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

211–220 of 349 posts

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

#211

Post by mananaysiempre »

illiarian wrote: post #194
chrismorgan wrote: post #176

Earlier quoted context omitted.

I believe it’s still wildly wrong. Had arp242 not spoken up at that time, I’d have been saying something similar, because the numbers were to me blindingly obviously extremely unrealistic. The entire HTML Standard (which is somewhat of a misnomer now, it covers much more than just HTML, quite a bit of CSS interactions, other web platform functionality, JavaScript APIs, and the likes) is now about half a million words…

> and I suspect it’s bigger than everything else put together, apart from ECMAScript The thing is, it's not just the HTML standard. It's also all the standards it references. And all the standards they reference, and all the standards those standards reference, ad infinitum. For example, HTML 5 references SVG 2 which references CSS 2 which references Unicode and XML 11 . Or, to go the same route, HTML 5 references SV…

ISO 646 and 61966? I won’t disagree with your annoyance with ISO water torture[1], but ASCII and sRGB are not the examples of needlessly sprawling web of references I would’ve chosen. Even if sRGB is an utter mess[2], it’s a mess you essentially have to use if you’re doing colour on computers.

[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

[2] https://photosauce.net/blog/post/what-makes-srgb-a-special-c...

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

#213

Post by Gigachad »

lysecret wrote: post #212

This is exactly the type of thing why I am so excited about LLMs. If they make use widely more productive we can build huge things like this and take on the monopolies in the space. It might lead to a wave of "thought impossible to build" products.

After the doomer wave I think we are going to see a lot of incredible projects people have built with these tools

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

#214

Post by andrekandre »

Brian_K_White wrote: post #121
samwillis wrote: post #31

Earlier quoted context omitted.

Happy to admit it's a crazy idea, and it's not something that I would want to see as a usual way to built sites. But for small areas of web apps where compatibility is difficult it does make sense. Google Docs used to be contenteditable based, but moved to a custom rendering engine. They are a large enough company to be able to invest in that. Small businesses aren't, and have to rely on content editable. Ladybird as…

"Google Docs used to be contenteditable based, but moved to a custom rendering engine." Is THAT why you can't cut & paste with the mouse in google docs like you can on every other site? Take me back to the old way then please.

yep, the use canvas to render everything now

https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

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

#215

Post by nicoburns »

hanselot wrote: post #193
illiarian wrote: post #159

Earlier quoted context omitted.

Worth noting the discussion at the link. Given that he omitted huge specs like WebGL etc. I wouldn't say it's wildly wrong. But I'd love to somehow arrive at a better estimate.

Given that someone that needs to develop a browser probably needs to hunt and peck through all that trash to find the relevant bits of information, is it not actually more damning that such a vast quantity of irrelevant cruft exists? Is this not the corporate equivalent of creating a walled garden (perhaps not the right phrase here, gastric moat sounds more apt), by exhausting the resources of all that should choose…

One thing the web specs do incredibly well is cross-linking. I've found it quite easy to start with a high-level spec (e.g. flexbox) and drill down into the bits I need because anywhere another spec is referenced it's linked to directly.

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

#216

Post by Tao3300 »

Brian_K_White wrote: post #110
Gys wrote: post #98

Earlier quoted context omitted.

[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 choo…

[flagged]

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

#217

Post by it_citizen »

spiffytech wrote: post #181

> Deferring on performance work I'll be curious to see how this plays out. History seems to show that boosting performance later is a monumental challenge. Early Chrome showed that Firefox was leaving a lot of performance on the table, and it took Firefox a long time to catch up.

But their product survived and they ended up being wildly successful.

In a lot of projects, early optimization hurt the development speed and maintainability, sometimes killing the product.

It is easier to see performance bottlenecks once a product is wildly used than adding optimizations everywhere we suspect it might become a problem later.

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

#218

Post by throwaway2037 »

codetrotter wrote: post #21
ryanjshaw wrote: post #15

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

The cross-platform version of the browser uses Qt The version of the browser native to SerenityOS hopefully still uses the SerenityOS GUI libraries

It looks like they ported Qt to SerenityOS. I saw a package called "qt6-serenity". Perhaps they use the SerenityOS GUI libraries underneath. Does anyone know?

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

#219

Post by actionfromafar »

cxr wrote: post #182
chrismorgan wrote: post #153

Earlier quoted context omitted.

I’m puzzled by your comment. I am expert in Rust for almost a decade, but only mildly conversant in C++, and have no interest in actively learning more C++. Rust seems to me far easier to learn and get going in due in major part to its incontrovertibly superior standard tooling. I can’t see any place for any meaningful difference in iteration speed between the two, save that you may well have to iterate more in C++ d…

Iteration speed with both Rust and C++ is abysmal. Builds take for fucking ever on large projects and it's just slightly less bad for small-to-medium and medium-sized projects. With Rust, though, it's as if someone looked at C++ compilation times (not to mention resource requirements) and said, "I think we can find a way to make it worse."

Crystal says "hold me beer" :-D

But I still really like Crystal.

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

#220

Post by tobr »

thrdbndndn wrote: post #104
tobr wrote: post #50

Earlier quoted context omitted.

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.

Please re-read your own comment. You describe two hard things, performance and long-tail compatibility, and literally state that “the team” will have a nightmare left after an initial cruise.
Post reply on HN