Maddock: The End of Indie Web Browsers

> The "modern" web has just become too monstrously complex

I think it has always been complex, but the kind of complexity has changed. The complexity used to be in the trickiness of the implementation; now it's more in the vastness of the implementation.

E.g. it used to be very difficult to write an HTML parser that would work on real web sites with the level of compatibility needed for a competitive browser. The specifications were useless - you'd have to reverse-engineer other browsers and then spend a decade fixing your parser in response to bug reports, and in the meantime you'd be losing users whose favourite site didn't render correctly. Then HTML5 took the results of that reverse-engineering effort from all the major browsers, did a load of compatibility testing of its own, wrote a specification, and convinced the browsers to converge on that. Now anyone can simply implement that specification in a few weeks and have a fairly decent parser.

The same applies to most HTML4-era parts of the platform, which were a mess of underspecified (or unspecified) reverse-engineered features, where a lot of the complexity was in solving compatibility problems. HTML5 showed that it was feasible and valuable to write specifications in an excruciating level of detail, with the explicit goal of making it easier for competing browsers to be developed - all you need to do is translate the spec into code. Since that was relatively successful, new features were designed and specified with a similar philosophy. Then more new features, and more, and now there's so many specifications that the impossible complexity comes from trying to keep up with them all.

> How many actual use cases could the Web Crypto API _actually_ have?
For example, we're using it to sign requests to our service.

While I agree with your description of how the volume and complexity of all the api:s for the modern web makes a new implementation nearly impossible today, I do not think we should primarily - if at all - attribute it to malice. Rather it is very much an incidental complexity growing from years of well intended ambition to meet genuine user needs.

A more interesting question is how to address such patterns of continuous added incidental complexity. I do not believe that browser developers or users would accept a moratorium on new features. So, is there anything else that can be done to reduce the complexity of the web again?

Honestly, as was pointed out below HTML5 really improved things for the basics.

And as has always been the case with Web APIs and features for browser buildings:
just implement those you actually think make sense: http://html5test.com/ https://caniuse.com/

A bigger problem is probably creating a fast Javascript engine for example. As websites have become thicker, getting a good user experience depend on a lot of optimization.

Still, Mozilla seems be rewriting large parts of their engine over time in Rust. With I assume the goal of pretty much rewriting the whole thing.

> Without EME, the streaming services would just roll their own DRM like they always did, which would probably be a major hassle for users of niche operating systems like Linux, if not exclude them from streaming altogether.

EME does not specify the type of DRM used or guarantee portability to different platforms. If streaming services choose to standardize their DRM implementation, and aren't too picky about things like "protected media path", then streaming may work on "niche" operating systems—with or without EME. On the other hand, each service could also mandate its own proprietary and non-portable EME DRM plugin. The advantage here comes from the adoption of Widevine, not EME, and even then it depends on the level of Widevine DRM the service requires. If the Widevine plugin were implemented with NPAPI and ActiveX interfaces instead of EME the result would be essentially unchanged.

EME has a few real advantages over previous plugin systems. It's not as tightly linked to a particular platform as ActiveX, and the interface is much smaller and more modern than NPAPI. In the end, though, it's just another system for implementing native browser plugins, designed specifically to support plugins and services which are hostile to the owners of the devices running them (i.e. malware by any reasonable definition).

If EME had not been standardized, Google would just have gone ahead and shipped a non-standardized API in Chrome to let sites use Widevine, which would have been a strictly worse situation for non-Google browsers.

This!!

The internet do adapts, while the web is getting more complex, many people still buids sites that aren't that complex. The most complex sites are either for audio/video, build to track you or try behave like a local apps. All those can be replaced, they existed even before html5, even if replaced by unofficial tools/sites

If only one engine existed, i suspect that a new tool would emerge. Either fork from blink or start a new one/upgrade one of the existent smaller ones or even a new tools would show up (say a mix of usenet+chat+p2p+wiki talking via TLS json payloads)... and it could end (on the long run) replace http, like http replaced gopher and ftp.

Yes, it is hard to replace, it would take time, but mozilla manage to sail against a thunder storm for several years and manage to arrive to the target goal. Those years were painful, but proves that i can be done, there is always people that will not accept "one size fits all"

>What actually happened is he spent a week slapping together the 15,731,294th worthless CEF UI wrapper on github

That may well be true but it doesn't make his points about not being to be "allowed" to have working DRM less valid.

As others have said the days of building a completely new web browser from scratch are probably over anyway for other reasons but taking an existing opensource web engine and customizing it in some way useful for your niche can still have value.

As FLHerne points out below, what's new? It's always been Flash or some other binary plugin between you and sites like Netflix. The death of Flash has been much more of a boon to users of odd operating systems and ISAs than this will be a bane.

There's also https://sciter.com/ , though it's more of a UI engine

Yes. More examples:

Links 2, works on framebuffer console as well as X11. Has a text frontend that's useful over ssh. I found it very convenient to use it to read LWN and browse HTML documentation when I need to use my memory for something more useful than whatever wastes it with Firefox.

Dillo is a very lightweight FLTK based X11 browser, that does a decent job at rendering modern web sites that are not completely brain dead. It used to struggle with https, but that's apparently worked on for next release.

Both start in no time and do a good job at rendering many web sites. Perhaps not Facebook or Twitter .

Self-plug: I wrote Fifth http://fifth-browser.sf.net/ - posting this comment from it. It's Webkit-based however, so perhaps "15,731,294th worthless Webkit UI wrapper on Sourceforge".

Then again, I wrote the FLTK backend for webkit, and heavily customized webkit innards to suit my tastes in how a browser should behave. So perhaps halfway between an indie browser and a Webkit UI wrapper. It works well for my use, but I don't stream video, social notwork, etc.

Fifth, Otter, Midori, etc are somewhere in the middle. Not as light as Dillo or Lynx, but can actually render most of the modern web.