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: 5, Insightful) by Anonymous Coward on Tuesday March 24 2020, @07:43AM (19 children)

    by Anonymous Coward on Tuesday March 24 2020, @07:43AM (#974833)

    Maybe start with the one with no scripting whatsoever. And stay that way.

    Starting Score:    0  points
    Moderation   +5  
       Insightful=5, Total=5
    Extra 'Insightful' Modifier   0  

    Total Score:   5  
  • (Score: 2) by gtomorrow on Tuesday March 24 2020, @11:12AM (1 child)

    by gtomorrow (2230) on Tuesday March 24 2020, @11:12AM (#974899)

    You mean like Dillo [dillo.org]?

    • (Score: 2) by captain normal on Tuesday March 24 2020, @09:25PM

      by captain normal (2205) on Tuesday March 24 2020, @09:25PM (#975209)

      Thanks, looks interesting. I'll be checking it out.

      --
      When life isn't going right, go left.
  • (Score: 3, Insightful) by bradley13 on Tuesday March 24 2020, @11:37AM (2 children)

    by bradley13 (3053) on Tuesday March 24 2020, @11:37AM (#974905) Homepage Journal

    No scripting, sure, but CSS is also a huge problem. CSS/3 is unendingly complex. You would have to revert to CSS/2 to have any chance of a successful new implementation.

    --
    Everyone is somebody else's weirdo.
    • (Score: 0) by Anonymous Coward on Tuesday March 24 2020, @12:59PM (1 child)

      by Anonymous Coward on Tuesday March 24 2020, @12:59PM (#974937)

      They are all separate modules now. Just cherry pick whatever feels reasonable above CSS2, one at a time.

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

        by Anonymous Coward on Thursday March 26 2020, @07:12AM (#975766)

        Speaking of which, display: flow-root is a must.

  • (Score: 2) by mth on Tuesday March 24 2020, @12:31PM (5 children)

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

    A website that is just pages with information can function without JavaScript just fine. But for web applications, no scripting really limits what is possible. As a Linux user, I really appreciate not needing native applications for accessing services from companies.

    • (Score: 1, Insightful) by Anonymous Coward on Tuesday March 24 2020, @12:57PM

      by Anonymous Coward on Tuesday March 24 2020, @12:57PM (#974936)

      You don't need scripting for most services, though.

    • (Score: 2) by DannyB on Tuesday March 24 2020, @03:06PM (3 children)

      by DannyB (5839) Subscriber Badge on Tuesday March 24 2020, @03:06PM (#975007) Journal

      As a Linux user, I really appreciate not needing native applications for accessing services from companies.

      In the event that web scripting were to go away, let me wildly speculate.

      Java is already cross platform. And has not one but two cross platform desktop GUIs already. And it's open source. (GPL + Classpath) While not everyone likes Java [soylentnews.org], it is thoroughly modern. It has run on everything from flip phones, blue ray players, and in some form Android, smart cards, and monster servers.

      Big Boring Business Software is what makes the world go around. A great deal of this invisible software is written in Java (and runs on Linux!). Custom business applications are everywhere, but instead of custom GUIs that look like Windows 95, you see these all running in a web browser. (Next time you check out a library book, or get your oil changed, or your doctor orders lab blood work, or you check into a hotel, or . . . just look at the application they are using.)

      Platform portability is a huge part of this. Especially if it is portable at the binary application level.

      1. I could predict the rise (or return) of myriad Java desktop GUI applications -- installed at the client.

      2. To keep one of the major advantages of the web, these applications would be very self maintaining and updating (like Google Chrome).

      3. Maybe a generic application would emerge where the server sends Java binary classes (or JARs) to the client to be run within the generic application. This is another way for the application to be very self updating, but without nearly as many updates at the client end. Only when the generic client changes.

      On a completely different track . . .

      Maybe major players might get together and fork, then vastly simplify, an existing web browser. Just make it good as a "remote terminal" for web applications. (This probably also makes it suitable as a "browser" as a side effect.)

      The advantage of this approach over the previous, is that browsers are already more portable and exist on more platforms.

      Microsoft might view the demise of browsers as another way to gain worldwide domination over all software.

      --
      People today are educated enough to repeat what they are taught but not to question what they are taught.
      • (Score: 2) by Pino P on Tuesday March 24 2020, @09:14PM

        by Pino P (4721) on Tuesday March 24 2020, @09:14PM (#975204) Journal

        Let's imagine for a moment the client were to switch from web applications written in JavaScript and/or WebAssembly to downloadable written in. Each application would still need to be written three times: once in JDK using a desktop framework, a second time using Android's nonstandard variant of the Java class library, and a third time for iOS and iPadOS in a completely different language because Apple bans JIT.

        As for the topic of the article: The Java platform isn't just too complex to reimplement; it's actually illegal. Last I checked, the license of the Java language and class library specification banned distributing a work-in-progress or otherwise incomplete implementation to the public, and Google got sued for this. So we'd end up in an OpenJDK monoculture on desktop.

      • (Score: 2) by toddestan on Thursday March 26 2020, @02:21AM (1 child)

        by toddestan (4982) on Thursday March 26 2020, @02:21AM (#975690)

        I would say the more likely scenario is that web technologies will continue to dominate. If you want a desktop application, especially a cross-platform application, then it'll just be the web application packaged up with its own copy of a web browser that's hard-coded to point just at the web application. Or basically the Electron framework which is popular nowadays, for better or for worse.

        • (Score: 2) by DannyB on Thursday March 26 2020, @02:14PM

          by DannyB (5839) Subscriber Badge on Thursday March 26 2020, @02:14PM (#975876) Journal

          That is one way to implement a desktop application.

          At present, web applications are superior because they are:
          1. zero maintenance
          but also . . .
          2. zero install

          The maintenance, updates, backups all happen at the server. To the end user, it all just works.

          Plus entire classes of support problems simply disappear. "Jane can't print!" Never had that problem in over a decade now. The web app previews, and then downloads a PDF. Even forms! (eg, checks, W2s, etc) Your desktop app doesn't need to support printing. The user prints the PDF using their favorite PDF viewer. If your PDF is crafted properly, all the boxes on forms line up on the paper, on EVERY printer. Regardless of margin settings.

          My employer originally offered the application I work on in a "customer self hosted" version where the customer could install the server on their own server. And that was a turnkey (Windows) setup.exe. Ultimately very few of those sold. Everyone almost universally wanted us to host it. Like it or not. That is the reality. Despite that they pay more for us to host it. (And the app is multi-tenant. One app instance services all customers. Each customer has separate database.)

          If web browsers suitable for running applications were to disappear, I would be looking at a way to implement a universal desktop client. And maybe a way to implement a tablet client on Android/iOS. And chromebooks.

          Because web applications from giant corporations are so many and so prevalent (yet generally invisible in society) I expect there would be some kind of industry effort to come up with an open replacement. Probably forking and simplifying current browser or browsers.

          --
          People today are educated enough to repeat what they are taught but not to question what they are taught.
  • (Score: 3, Insightful) by DannyB on Tuesday March 24 2020, @02:53PM

    by DannyB (5839) Subscriber Badge on Tuesday March 24 2020, @02:53PM (#974998) Journal

    Maybe start with the one with no scripting whatsoever. And stay that way.

    This may be a well intentioned idea. But look, advertisers are never going to go for this craziness.

    This would leave us condemned to a web without any advertising. So it will never fly. Oh the humanity!

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.
  • (Score: 2) by Pino P on Tuesday March 24 2020, @09:06PM (6 children)

    by Pino P (4721) on Tuesday March 24 2020, @09:06PM (#975201) Journal

    In a web browser with only forms and no scripting, how would a web-based chat app such as Riot (the frontend to Matrix) work? Or would each web application instead need to be rewritten five times as a native application, once for each of Windows, macOS, X11/Linux, Android, and iOS?

    • (Score: 3, Touché) by Arik on Wednesday March 25 2020, @02:38AM (5 children)

      by Arik (4543) on Wednesday March 25 2020, @02:38AM (#975301) Journal
      It would need to be written once in a high level language. If you were bothering to optimize it for different platforms, which no one has bothered to do with this sort of application for many years, then you might rewrite a small portion 5 times, for each supported OS.
      --
      If laughter is the best medicine, who are the best doctors?
      • (Score: 2) by Pino P on Wednesday March 25 2020, @03:24AM (4 children)

        by Pino P (4721) on Wednesday March 25 2020, @03:24AM (#975314) Journal

        Which non-JavaScript high-level languages are most useful to write a chat client or another similar application that targets all five client platforms?

        • (Score: 2) by Arik on Wednesday March 25 2020, @03:48AM

          by Arik (4543) on Wednesday March 25 2020, @03:48AM (#975322) Journal
          I'm not the right person to ask that question, as I haven't programmed shit in over a decade.

          But I'm pretty sure C would work.

          *Runs off to *check**

          Oh yeah, it definitely works. http://www.bitchx.com/
          --
          If laughter is the best medicine, who are the best doctors?
        • (Score: 0) by Anonymous Coward on Wednesday March 25 2020, @01:06PM (2 children)

          by Anonymous Coward on Wednesday March 25 2020, @01:06PM (#975434)

          Basically all of them. It's 2020. Most languages can either be directly run or can be compiled to run on all major platforms. Same is true for many GUI toolkits and other useful APIs and frameworks.

          The argument used to be that you couldn't respect the look and feel of the platform. The web said "FUCK THAT! We need to hire expensive media designers so we can force developers into using a viewing guideline DSL as a pixel perfect DSL", so anyone continuing to use the look-and-feel argument as a reason to rewrite an application for each platform is just bullshitting you.

          Client-server chat programs are things freshman write near the end of the first year, at least that's what we did in my Intro To CS 3 class (C++) in 2006. (FYI: C++ is not a good language for general application development due to its high bug rate and complexity.)

          • (Score: 0) by Anonymous Coward on Thursday March 26 2020, @07:15AM (1 child)

            by Anonymous Coward on Thursday March 26 2020, @07:15AM (#975767)

            > FYI: C++ is not a good language for general application development due to its high bug rate and complexity.

            Compared to C it's a godsend. C is nice and all but it's way too effective footgun for complex software.

            • (Score: 1) by Arik on Tuesday March 31 2020, @07:02AM

              by Arik (4543) on Tuesday March 31 2020, @07:02AM (#977542) Journal
              "C is nice and all but it's way too effective footgun for complex software. "

              Well some of the less obvious features can be footguns. But also opportunities.

              Complex software obviously is tricky because it has excessive number of failure points. But if you build it from less complex parts, each of the parts shrinks to the point that they can be reasonably tested and audited. In theory at least.

              Keeping it as simple as possible makes it easier to audit.

              --
              If laughter is the best medicine, who are the best doctors?