Live data from Hacker News

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

awesomekling.substack.com

141–150 of 349 posts

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

#142
post #66

Earlier quoted context omitted.

> Web browsers are a moving target It moves slower than people assume; I installed Opera 12 last year for the craic – the last version built on their Presto engine, released almost ten years ago – and it works surprisingly well with many sites. I did have to use mitmproxy to rewrite some trivial stuff like some CSS prefixes and s/(let|const)/var/ in JS. Flexboxes are supported, but grid isn't so that failed for some…

>I mentioned this at the time And Drew himself answered you at the time on points made to your comment, that is things you said shouldn't be included that should and others you said were incorrectly included but were instead excluded in first place.

Those replies are handwavy and offer no convincing defence at all. In just a few minutes I was able to reduce the 1,217 URLs to 434 by simply excluding outdated or non-applicable stuff. That's about a third and includes some pretty large documents, and that's just with a quick check. The list is unambiguously categorically wrong and anyone who seriously looks at it and comes to a different conclusion is suffering from serious confirmation bias.

Whether the web is "too complex" is a different matter and open to interpretation as "too complex" is subjective. But the data very wrong and therefore the article is wrong. A "correct" conclusion with faulty arguments is just as worthless as an incorrect conclusion: any possible solution depends on a correct understanding of the situation. "Global warming happens because of pornography, therefore we must ban pornography" is just as useless as "global warming is a fake fraud" even though the conclusion of the first is correct.

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

#143

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.

I experimented with this a while ago but didn’t get very far.

The rendering was done into a pixel buffer with inputs being passed though a few relatively simple C++ classes.

I think that a small embedded version would make for a great UI framework with minimal dependencies.

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

#144
post #49

I think that there will be a new successful browser one day - and it will be disruptive. But it needs two properties: 1. A unique use case or feature that cannot be easily implemented in the existing browsers. Something that breaks the current architecture and turns the current use cases into afterthoughts. ("oh, yeah, right we actually need to render html somehow at some point, can the intern do it?") 2. A significa…

I don't think Ladybird is being built to dethrone Chrome, just like Serenity is not being built to dethrone Linux.

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

#145

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

I thought unsafe language were a no-go in the context of extremely vulnerable pieces of software like the web?

The are building a memorysafe language too : https://awesomekling.github.io/Memory-safety-for-SerenityOS/

and their goal is to use it to incrementally rewrite SerenityOS

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

#148
post #12

Building a web browser is a difficult, but attainable task. On the other hand, getting the UX right is a gargantuan task that even big tech struggle with.

Actually, UX is much easier to iterate on. There are countless Chomium implementations that are mainly competing on UX. They all render websites just fine. UX is the only thing they compete on. Mostly, there is a lot of imitation and not a lot of innovation in that space. It seems people like tabs at this point and things like bookmarks and back buttons. There are only so many ways to arrange those features on a screen and we've seen most of those over the past 20 years.

The real difficulty with browsers is building a better one than the existing ones. If you make a new browser. It does exactly the same thing as the other ones. It's a great technical accomplishment but it has a very low value. Which is why nobody bothers at this point.

At this point there are only three browser engines with any audience still worth talking about: chromium, safari/webkit, and firefox/gecko. Obviously the first two are related but they forked so long ago that they are quite different at this point. In terms of what they do there are some minor differences but they basically render the same websites in more or less the same ways. There is very little point in picking one over the other at this point.

I actually use Firefox and I'm pretty happy with it. I don't think it does a lot better/different than the other two at this point but I like not selling out completely to Apple/Google. Google treats me like a product rather than a user and Apple seems more interested in telling me what I can't do rather than enabling me to do things I want to do. But objectively, both do a fine job of rendering websites and allowing me to browse the web. Just like Firefox does. And given that there is no practical difference, I choose to use Firefox.

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

#149
post #51

Earlier quoted context omitted.

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 a…

Like most people I gave up on the whole semantic pedantry a long time do. Correct header ordering, basic semantics like : sure, that's great. But "no

inside allowed!" just makes no real sense and is exceedingly pedantic.

The validator badges were kind of a backlash against the tag soup of the day; part of the reason for that was that everyone who knew how to program a VCR could get employed as a "webmaster" in those days, but also because the authoring tools for non-tech authors weren't as good. HN sees a lot of posts from non-tech people, often written on WordPress, Medium, or whatnot. 25 years ago it would more likely have been "tag-soup'd" by some non-tech person who just learned a bit of HTML.

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

#150
post #33

Earlier quoted context omitted.

Chrome used an already existing render engine and improved on it.

More specifically, Chrome used Safari's rendering engine, and Safari used Konqueror's rendering engine, because even in 2001, starting a browser engine from scratch seemed like too much work.

And Firefox is going all the way back to Netscape Navigator...
Post reply on HN