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: 2) by mth on Tuesday March 24 2020, @12:55PM (7 children)

    by mth (2848) on Tuesday March 24 2020, @12:55PM (#974935) Homepage

    The article seems to mix up two things: the complete application and rendering engine.

    Writing a rendering engine from scratch is probably indeed too much work for any group to tackle. But is that a bad thing? I have no fond memories of the time we had to work around different bugs in different browsers, especially when IE6 was still around. Developing for the web is much more pleasant today.

    If enough people are unhappy with Chrome and Firefox as applications, it is feasible to create a different web browser from the components of those browsers and drop the unwanted policies and features. And there are in fact several alternative browsers around that are very usable.

    The security risk of having such a complex application is a valid point. But I don't think that can be solved by cutting features. For example, not supporting video would reduce the attack surface quite a bit, but people like to be able to watch videos in their browsers. I think splitting the browsers into multiple processes and sandboxing them, as both Chrome and Firefox have been doing, is the only practical solution here.

    When mentioning Servo, I assume that with "technology no one wants" the author means Rust. I strongly disagree there: writing complex applications entirely in C++ is one of the reasons they're so full of vulnerabilities. We should accept the limitations of our human brain and stop pretending that being a better coder is the solution.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 4, Insightful) by Anonymous Coward on Tuesday March 24 2020, @01:07PM

    by Anonymous Coward on Tuesday March 24 2020, @01:07PM (#974940)

    > …is that a bad thing?

    It is. In such ecosystems standards go away, and the only things left are bug-compatibility and The Corp's will.

  • (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.

  • (Score: 2, Interesting) by Anonymous Coward on Tuesday March 24 2020, @09:22PM

    by Anonymous Coward on Tuesday March 24 2020, @09:22PM (#975207)

    A language which can hide arbitrary complexity in one innocuous-looking operator sign, is a disaster waiting to happen, period.

    The thing personifying that disaster to me, is one old (but possibly still unfixed) crash bug in OpenOffice. It was crashing when copying stuff, and was doing it only on slow machines. The thing with it, was that one thread was deleting an object before another was done with it; a classic case of insufficient locking BUT... the action in question was ONE assignment operator, a lowly "=", expanded into a chain of 8 costly function calls doing various conversions. A nice landmine to step on and go up in flames, isn't it?
    http://icu-project.org/docs/papers/cpp_report/the_anatomy_of_the_assignment_operator.html [icu-project.org]
    Single characters should NOT be having "anatomy". Complex thing should LOOK complex. It is as simple as that.

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

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

    i agree with your assessment and i look forward to servo. Maybe i can even write a stripped down web browser in Rust to go with it.