3
lorentz
1y

The reason there aren't independent web browsers anymore is that the web standards include a lot of concepts that should never have been standardised and their presence in the browser as opposed to compilers and interpreters targeting the web has no benefit whatsoever.

Comments
  • 1
    CSS is getting webassembly layout and render worklets, tiny WASM programs that can organize boxes or paint on them. Great progress I say, but since this is a generalization of all CSS, why keep CSS engines, which are a massive part of every browser and endanger the rest of the project with their enormous upkeep? Why not make them individual libraries, implemented in WASM, which websites may choose to import and browsers may choose to develop as an optional component or borrow from elsewhere?
  • 1
    My ideal browser is a sandbox that provides accurate information about the presence and nature of peripherals and regulates their use while introducing the miinimal amount of overhead compared to a native application necessary to enforce stringent safety policies.

    My ideal browser is a good OS.
  • 1
    Well, that's the thing.

    Web apps have had such an (IMO underserved) boom, that now browsers actually need to be like an OS within an OS, because "omg so portable and ubiquitous".

    If webs had been kept as webs and apps as apps, we wouldn't have this circus.
  • 0
    @CoreFusionX Web apps couldn't not have boomed. If I find or make a new fancy diagram drawing tool that helps me explain myself easier and send a link to my audience, they can just click the link and instantly be in a whole ass program without a tedious installation process, having to trust the vendor with the safety of their computer, or figuring out a new programmer's headcanon about how data is really structured, because the link binds both data and code, and comes with a guarantee of sandboxing. This is the only part the user inherently has to trust, and this is the part they can freely choose.
  • 0
    @lorentz

    Yes, but this is exactly what causes what you originally posted.

    Who is responsible for that safety and that sandboxing but browser vendors?

    In essence, your burden them with that concern of trust instead of the app vendor. And given the amount of apps vs amount of browsers it's only natural this reduces the amount of browsers vendors to those few who have the resources to keep up.

    I would like to see something like the model you envision, but in the end, how would that be any different from what you last said?

    It would be trusting the safety of your machine with the code of an external vendor anyway (whoever providers the JS engine, it the css engine, or the layout engine, etc)
  • 1
    @CoreFusionX The user trusts the browser vendor to protect them against potentially hostile app vendor. In my model, no one has to trust the CSS engine's vendor because it's inside the sandbox. All the browser has to do is run Webassembly and provide APIs like WebGL, XMLHttpRequest, Websockets, the history API, and guarantee their safety. Not a small task still, but much more manageable than the same tasks plus state-of-the-art trace compilers to optimize JS based on static analysis to determine invariants that the dev already put into the code but they were stripped during compilation to meet a standard that has no reason to be a standard.
  • 0
    @lorentz

    Agreed.

    Still, how many relevant OSs do we have, how many VM vendors do we have?

    When you force browsers to be essentially VMs, how many do you expect to have?

    Back when I was young, implementing a browser was relatively simple, you basically had to implement curl.

    Now, it's a behemoth out of reach for most stakeholders.
  • 0
    @CoreFusionX A large part of the complexity in hypervisors comes from the fact that they have to pretend to be bare metal because the virtualized OS usually doesn't make an effort to make the hypervisor's job easier. Browsers in this personal utopia of mine would be more like runtimes with a dedicated assembly language designed for portability, dedicated APIs that are intended to be much simpler than native ones, and dedicated software that assumes a certain degree of inefficiency and isolation, and doesn't attempt to use its environment as if it were a circuit board.
  • 0
    But still, I really would like to see a greater willingness from the W3C to deprecate standards which are specializations of other standards with only minor performance benefits that ultimately don't warrant the maintenance effort.
Add Comment