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

311–320 of 349 posts

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

#311

Post by cxr »

noirscape wrote: post #249
cxr wrote: post #202

Earlier quoted context omitted.

This comment gets some pretty important fundamentals wrong. > The real bugbear here is JS though, HTML and CSS are complex but workable. JS is an ever-moving target What you characterize as "JS" is, in reality, more HTML and CSS than JS. JS is a language. The fact that all the behavioral details of the HTML and CSS objects and related host objects have bindings available to JS programs does not make those things "JS"…

Fair. I meant JS here as in "fully DOM compatible, as-used-in-your-browser JS". JS engines themselves aren't that hard to make (I think there's about 9 or 10 actively maintained ones?), but to make one that's usable in situations that aren't things like node or as a sub-language in a different project... that's far more difficult.

> "fully DOM compatible, as-used-in-your-browser JS"

That's still wrong.

s/DOM//

s/JS/DOM/

Continuing to say JS when you're really talking about what is, again, still in the land of HTML, CSS, etc just confuses things. Viz:

> to make [a JS engine] that's usable in situations that aren't things like node or as a sub-language in a different project... that's far more difficult

It's really, really not about JS. You don't make a browser that's compatible with the Wild Wild Web by adding stuff to the JS engine. You do it by implementing moar browser.

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

#312

Post by School-Cotton »

eastbound wrote: post #35
ryanjshaw wrote: post #15

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?

A no-go? Every major browser is written in an unsafe language, except for parts of Firefox.

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

#314

Post by giantrobot »

cxr wrote: post #310
giantrobot wrote: post #288

Earlier quoted context omitted.

A more detailed spec might have more concrete definitions but it also means more actual code for someone to write. An under-detailed spec you might have a case switch with a couple defined values and an undefined catch all. A super detailed spec just adds case statements and requires more code to handle them. The detail in the spec makes for lower cognitive load but the code still needs to be written and ideally test…

> A more detailed spec [...] means more actual code for someone to write. No, it doesn't. A detailed spec has the same amount of code to write as a spec for the same thing with less detail; for the types of specs relevant to this discussion, the primary requirement of "does what the other browsers do" exists whether the details are made explicit in the spec or not. More code is a consequence of an increase in require…

No. If a spec doesn't define a behavior code can jump to some "undefined" handler which could be anything from a no-op to some quirks mode. Unless you're Microsoft writing specs "do what Word 97 does", copying the behavior of existing browsers is not a specification.

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

#315

Post by bogeholm »

travisjungroth wrote: post #284
naikrovek wrote: post #265

Earlier quoted context omitted.

> On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again. this is not directed at you, but at this attitude which is very common and which I see all the time: everyone is lightning fast to come up with reasons that something won't work. why? why do people say…

Can you imagine some situations where this strategy would have positive value?

With regards to the negative interpretation having positive value, yes - working in a company that values ‘not failing in particular cases’ higher than ‘working in general, room for improvement’.

For example in a conservative corporation where a given project requires a ‘go’ from several departments were the success of the project does not give an immediate advantage to those departments, but a failure will require them to explain why they didn’t ‘catch it in review’.

Not an example to follow, but pretty common IME.

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

#316

Post by still_grokking »

bogwog wrote: post #200
GaggiX wrote: post #112

Earlier quoted context omitted.

The biggest problem IMO with using C++ when I tried the browser is that it crash, it crash a lot and I would imagine they are segmentation fault.

Can you recommend a language that doesn't crash?

For example C/C++, with the help of something like: https://www.absint.com/astree/index.htm

But there are actually other languages that are better suited to such methods: More or less everything from the functional space is quite well applicable to those.

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

#317

Post by Asraelite »

EVa5I7bHFq9mnYK wrote: post #208
chrismorgan wrote: post #135

Since “The reckless, infinite scope of web browsers” is depicted at the start of the article, I think it’s worth pointing out that its claim of W3C having 1,217 specs totalling 114 million words is wildly wrong, probably by 2–3 orders of magnitude in the total. The considerable majority of the documents considered were not specs or not web-relevant, and dozens of versions of the same thing were often counted. Source:…

Mozilla Windows binaries weight 226MB ... does it mean encoding rate of 2 bytes per word of specifications? Pretty good packing, I'd say.

I'm not surprised, it usually takes many words of English to describe very little code.

For example, changing "greater than" to "greater than or equal to" might require only a single bit of change in the machine code.

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

#318

Post by still_grokking »

rob74 wrote: post #67
hayleox wrote: post #33

Earlier quoted context omitted.

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.

I would say that in 2001, starting a browser engine from scratch was more work than today, because (as other commenters have noted) since then the specifications have become more robust and the "tag soup" sites not following the specs have become fewer.

The problem was solved by standardizing tag-soup. Now just any tag-soup will get displayed the same according to the new specs.

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

#319

Post by cxr »

giantrobot wrote: post #314
cxr wrote: post #310

Earlier quoted context omitted.

> A more detailed spec [...] means more actual code for someone to write. No, it doesn't. A detailed spec has the same amount of code to write as a spec for the same thing with less detail; for the types of specs relevant to this discussion, the primary requirement of "does what the other browsers do" exists whether the details are made explicit in the spec or not. More code is a consequence of an increase in require…

No. If a spec doesn't define a behavior code can jump to some "undefined" handler which could be anything from a no-op to some quirks mode. Unless you're Microsoft writing specs "do what Word 97 does", copying the behavior of existing browsers is not a specification.

Please don't ignore the context. We are talking about Web browsers.

You don't, in reality, have the latitude to do "anything from a no-op to some quirks mode" of your choice. The requirement is absolutely the one stated: to be compatible with what other browsers are doing. If your browser doesn't satisfy that requirement, then you break the Web, regardless of whether the spec is a hundred words or a hundred million. No amount of pointing at a standard and arguing that it doesn't specify clearly defined behavior in some area will ever be enough to teach a site to be able to say, "Oh, I'll just unbreak myself then so you can go ahead and view/use this page on your computer."

Besides that, even if you were right—and to be clear, you aren't—that doesn't change the fact that, again, arguing for underspecification because "a couple defined values" isn't as much "actual code" that "still needs to be written" is an argument that approaches a problem that isn't I/O bound as if it is.

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

#320

Post by pflanze »

guilherme-puida wrote: post #144
choeger wrote: 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.

I guess "won't be big and professional like gnu" can only be said once innocently. :)

(To be fair, the tech landscape may be sufficiently different that the same won't happen again, too.)

Post reply on HN