61–70 of 349 posts
Earlier quoted context omitted.
I thought unsafe language were a no-go in the context of extremely vulnerable pieces of software like the web?
Firefox has tons and tons of C++ to this day.
> So instead of [building the browser one feature/spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives. Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the…
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.
I'm finding it weird that unlike other non-trivial projects like OSes or compilers, people often discourage building web browser engine because it is "hard" or something like that like... how is it different from building a compiler? You gotta build HTML parser, CSS parser, figure out a fancy structure to represent those concepts and modify at fly. Also there's difference between making it work and making state of th…
Yeah it's "just" building some parsers and figuring out live updates, but you have to keep in mind that this is ~the internet~. People have been uploading broken, against spec, webpages since forever. Coding a web browser as a serious project (so not as a flight of fancy) borders on the impossible mostly because of that.
The main sites people test against/use aren't the "simple" CSS/JS/HTML sites from the past. Few people will care for a browser whose main job is to be able to render a neocities website. People want their popular sites working - Discord, Facebook, reddit, twitter. All of those are big JS apps.
The real bugbear here is JS though, HTML and CSS are complex but workable. JS is an ever-moving target as spec implementers (mostly Chrome) dump more and more of the jobs a browser was meant to do as the user agent into JS[0]. (And that's without delving into how widevine became part of the spec, which means it's legally impossible to make a fully spec compliant browser.)
Polyfills can offer a lot of fallback/lenience, but polyfills are a moving target too - older browsers get deprecated, polyfills get removed for performance/optimization reasons, so your baseline spec for functional JS becomes ever-increasing unless you somehow get the people making popular JS libraries to accept that your browser project is important enough to keep the necessary polyfills around for.
[0]: Presumably so that Google can take away the User part from the browsers job as the User Agent, but typically covered up as a poorly defined "privacy problem".
Web browsers are a moving target, just like operating systems. Anyone can 'build there own'; but I'd also say that it is close to impossible to build a secure and viable competing web browser that correctly implements the specification better than Chrome. The two most important keywords in Drew's blogpost is *serious* and *security*. There is not one mention of either of those words in this blog post; hence Drew's po…
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 sites.
> Drew's points still stands unchallenged
His points are based on a faulty assumption to start with: he counts all sorts of documents, but that count is spectacularly wrong as it counts many things it shouldn't. I mentioned this at the time: https://news.ycombinator.com/item?id=22617721
Is it a large project? Sure, as many software projects are. But "impossible" and "comparable to the Manhattan project"? Certainly not; it's just that there's not a whole lot of money to be made with a new browser engine or other broadly shared motivation.
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.
I'm finding it weird that unlike other non-trivial projects like OSes or compilers, people often discourage building web browser engine because it is "hard" or something like that like... how is it different from building a compiler? You gotta build HTML parser, CSS parser, figure out a fancy structure to represent those concepts and modify at fly. Also there's difference between making it work and making state of th…
- the web is numerous specifications: HTTP, HTML, CSS, JS, SVG. At worst, a regular compiler needs to worry about macros and the language syntax
- each of those specifications has numerous versions which, in some cases, can be significantly different from other versions of the same language or protocol. A language compiler generally only focuses on one version of that language
- A browser needs to support broken websites. A compiler only needs to fail gracefully
- A browsers output is graphical, which is much harder to unit test
In short, you’re dealing with a harder problem across a broader number of specifications. I would liken writing a browser more closely to writing a new graphical OS than writing a compiler.
(“Browser” here means “browser + engine et al” and not just a reskin of Chromium).