Hacker News Reader

Comment by adrianN | Hacker News Reader

Stagnation is not always bad. For one, it helps keep complexity down. We're at a point where building a browser is impossible unless you have literally millions and millions of dollars to invest. That is not good.

View on HN

Why is the possibility of a wheel being reinvented a desirable thing?

Because competition is good?

The hundreds if not thousands of ad supported calculator and flashlight apps on play store beg to differ.

Good for the consumer.

Reasonable amount of competition is good.

Competition that spurs innovation is good, more like, but I am skeptical of the claim that competition is necessary to prompt innovation, and whether the costs of such a model (leading to massive waste of society's productive capacity) are worth the purported benefits. For instance, a good deal of mathematics and science was not done on the principle of competition, but search for improvement. The real question is whether the development in goods and services can be or could have used similar principles, which is not only more efficient but seems condusive to better mental well-being; I'd rather desire to improve than to slight (and possibly sabotage) someone who must be my opponent.

Is a browser really a "wheel"? There are so many choices to make, so many lines drawn in the sand. And besides, you really don't want the marketing and tracking giant Google to make all the decisions regarding the software that delivers so much content to billions of users' screens, do you? They've been okay so far, but there's a huge conflict of interest here.

If building from scratch maybe, but when was the last time a browser was built from scratch? Even Chromium was forked from WebKit.

That's my point. The web is so complex that browser engines are becoming a monoculture. Even if you forked Chromium now, you'd need hundreds of engineers just to keep up with all the new things that are constantly added.

Yeah, I was rather sad to see EdgeHTML go. Although I never used Edge, rendering engine diversity is good for the ecosystem.

> new things that are constantly added

By golly, that's the problem right there.

One thing I’ve discovered from learning and using Common Lisp seriously is that it’s really important for a system to be specified in a way that allows for extensions to the system to be implemented in terms of primitives the language provides (e.g. you want a new language construct, write a macro to transform your desired syntax into Common Lisp). In languages and systems that don’t have this feature, an implementation that introduces useful extension begins to develop lock-in and makes it harder to compete. (E.g. no one writes the Haskell specified in the Haskell report anymore, because all the libraries you might want to use use one or more ghc-specific extensions.( )

There are significant tradeoffs between shared constructs and self contained systems. Self contained systems resist ossification; they can be unilaterally replaced. A shared construct has to evolve in step with all of its users.

But the self contained system will have thousands of incompatible implementations, and the shared system will be easier to interact with and build on top of.

What this means is that a browser should standardize on things meant to be interfaces, and leave out all of the rest. Unfortunately, they didn't and now browser engines are huge and impossible to evolve except by adding more stuff.

Similarly, the value of programming languages is almost entirely in the interfaces they provide which allow you to develop code. Lisp provides almost none of that, and that is why it failed to become mainstream.

> no one writes the Haskell specified in the Haskell report anymore, because all the libraries you might want to use use one or more ghc-specific extensions

This is a bit of a misconception. One can still write Haskell98 whilst using a library that use a GHC-specific extension. The library doesn't (have to) force its consumers to use extensions too!

I phrased that a bit wrong: my experience (from talking to the Haskellers in my company) is that Haskellers generally prefer to turn on a bunch of extensions when they write code. So, while you might be able to write pure Haskell98, it tends not to be idiomatic to do so.

And yet the fact that the major engine implementation is opensource still allows each vendor to innovate by adding new useful features to the users.

We're really far from IE6 era of complete stagnation.

Not really, as far as the core browser engine tech goes. In practice it's too difficult to maintain a Chromium fork that diverges in any significant way other than the front end. Opera and Edge (per announcement) use vanilla upstream Blink.

But since when is it a good thing that the last time someone managed to build a web render engine from scratch was thousands of years ago?

Hopefully Mozilla will have some luck modernizing by replacing pieces one at a time with Rust components. ;)

What do Firefox implementation details have to do with this?

They are modernizing the browser by replacing pieces over time. That's relevant to the topic of browsers being built on legacy tech.

I don't see how this supports to the argument that you can easily build a new, competing browser by forking. If you fork and then need the same kind of resources to replyce the forked codebase with your own, I don't see what you'd win.

Even if you fork, you'll still need constant investment to just keep it up-to date with the ever-evolving "living standard".

Reply on news.ycombinator.com