Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Tuesday March 24 2020, @06:45AM   Printer-friendly
from the Safari?-Brave?-Opera? dept.

Software developer Drew DeVault has written a post at his blog about the reckless, infinite scope of today's web browsers. His conclusion is that, given decades of feature creep, it is now impossible to build a new web browser due to the obscene complexity of the web.

I conclude that it is impossible to build a new web browser. The complexity of the web is obscene. The creation of a new web browser would be comparable in effort to the Apollo program or the Manhattan project.

It is impossible to:

  • Implement the web correctly
  • Implement the web securely
  • Implement the web at all

Starting a bespoke browser engine with the intention of competing with Google or Mozilla is a fool's errand. The last serious attempt to make a new browser, Servo, has become one part incubator for Firefox refactoring, one part playground for bored Mozilla engineers to mess with technology no one wants, and zero parts viable modern web browser. But WebVR is cool, right? Right?

The consequences of this are obvious. Browsers are the most expensive piece of software a typical consumer computer runs. They're infamous for using all of your RAM, pinning CPU and I/O, draining your battery, etc. Web browsers are responsible for more than 8,000 CVEs.3

The browser duopoly of Firefox and Chrome/Chromium has clearly harmed the World-Wide Web. However, a closer look at the membership of the W3C committes also reveals representation by classic villains which, perhaps coincidentally, showed up around the time the problems noted by Drew began to grow.

Previously:
An Open Letter to Web Developers (2020)
Google Now Bans Some Linux Web Browsers from their Services (2019)
HTML is the Web (2019)
The Future of Browsers (2019)
One Year Since the W3C Sold Out the Web with EME (2018)


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Tuesday March 24 2020, @02:32PM (3 children)

    by Anonymous Coward on Tuesday March 24 2020, @02:32PM (#974983)

    I love Drew DeVault's work and agree with a lot of what he says. His Github/Gitlab/Gitea/Gogs/Kallithea/Allura alternative SourceHut is fantastic, and it only has a tiny bit of optional JS.

    But Drew hates Rust. https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html [drewdevault.com]

  • (Score: 0) by Anonymous Coward on Tuesday March 24 2020, @11:32PM

    by Anonymous Coward on Tuesday March 24 2020, @11:32PM (#975253)

    yeah, and he's wrong. fuck memory bugs.

  • (Score: 2) by bzipitidoo on Wednesday March 25 2020, @11:32AM (1 child)

    by bzipitidoo (4388) on Wednesday March 25 2020, @11:32AM (#975403) Journal

    He has a lot of weird opinions. I'll always take C++ over C, but not because I want C++ style OOP. You don't have to use templates and operator overloading, which were in any case kludgy bandages to bolt some features of OOP onto C. I just want the basics of OOP, the classes. He, however, seems to prefer C, That's the sort of opinion I'd expect of a old systems programmer.

    But then he comes out against concurrency as being really hard and bug prone. Uh, there's a place for concurrency. OSes in particular really need concurrency. And there's a reason CPUs went multicore around 15 years ago. Speed! He evidently doesn't mind his single thread getting held up and stalled on every fricking blockage, because parallel is scary. A lot of the problems with concurrency turned out to have simple solutions.

    • (Score: 0) by Anonymous Coward on Thursday March 26 2020, @01:32AM

      by Anonymous Coward on Thursday March 26 2020, @01:32AM (#975667)

      I think he is using concurrency in a different sense than you are. I think he actually means parallelism. Not only does he use the usual "X^Y problems" people mention with multithreading and he specifically mentions the poll() call, which allows for concurrent operations on descriptors but not parallel ones. With a proper setup, many of the gains from concurrency can be done but without the downsides he mentions from parallelism.