6 ms·

Good. Maybe we can fight back the browser complexity. When you have free browser money, it makes it much easier to partake in turning the web into morass of dif

Good. Maybe we can fight back the browser complexity. When you have free browser money, it makes it much easier to partake in turning the web into morass of difficult to implement functionality, that then requires taking browser money.

int0x29 1y ago
This will just gut funding to fix exploits
- Brian_K_White 1y ago
  Features that don't exist don't have exploits.
  - socalgal2 1y ago
    Yea, so instead people make native apps which pown your machine. Great progress!
    - forgotoldacc 1y ago
      Honestly, the end of everything being a chrome-based app and people making actual native desktop apps that run at 10x the speed with 1/10th the energy usage would be excellent. I really hope that does happen.
      - inglor_cz 1y ago
        "that run at 10x the speed with 1/10th the energy usage" How many current developers optimize their products for speed and energy usage? I can see the very opposite happening: half-baked apps, whose massive portions were written using free-tier AI output, hogging gigabytes of RAM and four processor cores while the cursor is idly spinning and the laptop is becoming hot. Compared to the past (and my memory goes back to Netscape Navigator 3, old person that I am), modern browsers seem to be technologically fine.
        watermelon0 1y ago
        I'd say it's really hard to write a native app, however unoptimized, to be a bigger memory hog than Electron apps.
    - cosmic_cheese 1y ago
      Those at least have to be downloaded and installed by the user, which indicates a high level of intent/consent and is difficult to do accidentally. In the browser environment, malicious content can be navigated to without any user intent or consent whatsoever, which when combined with holes punched in browser sandboxes for the sake of fancy features makes for danger with a dramatically larger scope.
      - DecoySalamander 1y ago
        Right now, most untrusted code runs in the browser's sandbox, and that's great - outside of the realm of fancy 0 days, the damage is limited. But if downloading apps becomes the norm again (like every online store asking you to get their app and an extra app for a discount program), I expect that socially engineering less technical users into downloading malware will become much easier.
    - Brian_K_White 1y ago
      Yes. Native apps are 9000x prefferrable to the browser having to be a shitty os.
      - whatevaa 1y ago
        I guess Linux Desktop will die off then.
        Ekaros 1y ago
        Maybe it should if in 30 years it has not reliably solved native apps.
        redeeman 1y ago
        funny, it seems to me that a great many native apps exist, and works fine
        Brian_K_White 1y ago
        Been using them for 30 years already. I suspect if I heard whatever your definition of "solved" is, I would find it silly.
- mistercheph 1y ago
  it will also gut funding for the production of vulnerable code, in what ratio things will go is what it all depends on
dismalaf 1y ago
Reducing features just makes the web less competitive versus native apps, handing control of personal computing back to the MS and Apple duopoly.
- layer8 1y ago
  Reducing complexity doesn't necessarily mean reducing features. It can mean providing the features in a simpler, more sensible way. The real problem, of course, is backwards compatibility.
  - hdjrudni 1y ago
    Aside from a few rushed features, all the things that have been coming to web are really lovely. I'll be very sad if this all slows down. We were just about at feature parity with native mobile apps.
    - taftster 1y ago
      "Almost at parity" in feature set, maybe. But practically? How many sites actually offer an innovative and/or mobile-first version of their website anymore? There was definitely a time when we had websites delivering various layouts based on the viewport size of the user agent. CSS media queries, flexible layouts, etc. were all very important innovations for a very short lived period of time. Now, every serious web presence has moved on to offering their own mobile app, pushing users that direction. The browser was stubborn and erred on the side of privacy. So it didn't quite offer all the integrated (ahem, intrusive) means to interact with the user's device in order to bleed every penny and every bit of data mined from your usage and behaviors. So I don't see anything lovely in the current situation at all. The traditional web -- you know the one where you surf with a web browser to discover the world -- has been dying for quite some time. It might even be dead and we just don't realize it yet. We don't need web browser parity with mobile apps. We just need the web to be what the web is good at. It's a lost cause thinking that the web browser will ever integrate with a portable device quite the same as a native app. Those days are gone.
r0m4n0 1y ago
You do realize, a terrible company will buy chrome and we will be forced to wait until something better arrives (yahoo is interested at the moment). It’s going to get much worse before it gets better.
- dsnr 1y ago
  Chromium is open source, you can fork it to death while Terrible Company inc. is busy destroying chrome.
  - awesome_dude 1y ago
    People can do that right now, but don't. Instead we have endless complaints about what Google does with Chrome, and how complex it is :\
    - Apocryphon 1y ago
      ? https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browsers_based_on_Chromium https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browser...
      - mike_hearn 1y ago
        There are forks but they're very limited in how far they can deviate from what Google wants. The Manifest v3 discussions show this. Extension APIs aren't a big part of browsers compared to all the other things they do, and there was clearly demand to keep Manifest v2 alive, so you'd expect at least one or two forkers to differentiate by doing that. In practice the rebasing costs are so high that everyone shrugged and said they had no choice but to go along with it. Chromium is open source, but not designed for anyone except Google to develop it. Nothing malicious about it, it's just that building a healthy contributor community is a different thing to uploading some source code. If you've ever worked with the Chromium codebase you'll find you have to reverse engineer it to work things out. The codebase is deliberately under-architected (a legacy of the scars of working on Gecko), so many things you'd expect to be well defined re-usable modules that could be worked on independently of Google are actually leaky hacks whose API changes radically depending on what platform you're compiling for, what day of the week it is, etc. Even very basic things like opening a window isn't properly abstracted in a cross platform manner, last time I looked, and at any moment Google might land a giant rewrite they were working on in private for months, obliterating all your work at a stroke. There are reasons for all of this... Chrome is a native app that tries to exploit the native OS as much as possible, and they don't want to be tied down by lowest-common-denominator internal abstractions or API commitments. But if you view Chrome as an OS then the API churn makes Linux look like a stroll through a grassy meadow.
hyperhopper 1y ago
Web browsers that are so complex a person in their basement can't implement them are a sickness. We've gone too far. Give us back html homepages and executables you can run if you'd like something crazier
- chii 1y ago
  But why isn't the same logic applied to an operating system then? I dont think a browser being more complex than a person can grasp is an important aspect/problem that needs rectifying.
  - codr7 1y ago
    Having more options would certainly be nice, and the barrier to entry these days is pretty high.
  - Apocryphon 1y ago
    That logic is applied to operating systems, that's why SerenityOS has garnered so much interest.
  - swiftcoder 1y ago
    > why isn't the same logic applied to an operating system then? It absolutely should be. And arguably, is - there are multiple tiny OS projects that are somewhat useable
    - chii 1y ago
      and there's plenty of somewhat usable browsers out there too. But the OP's implication is that there ought to be a fully working browser (that satisfies the standards of the day), but creatable from someone in their garage. That hasn't been true for cars, appliances or any modern equipment for ages. And the same phenomenon being applicable to software isn't really that unimaginable (nor a problem).
      - Wobbles42 1y ago
erikerikson 1y ago
I completely appreciate what you're saying. Then I look at the level of crazy complexity and backward compatibility in html/css/js/wasm processing. And then I wonder: what are you actually proposing here?
- taftster 1y ago
  Going back to gopher as a starting point maybe. Let's innovate from there.
  - yjftsjthsd-h 1y ago
    That's a thing, in the form of https://en.wikipedia.org/wiki/Gemini_(protocol) https://en.wikipedia.org/wiki/Gemini_(protocol)
- photonthug 1y ago
  This is going to be unpopular but.. just to illustrate that we didn’t have to be stuck here. Using things like xpra/xephyr to serve a whole x11 gui over web is surprisingly easy and awesome and like 1/100th the complexity of a modern web stack. This might not be cheap to serve, but it’s cheap to build, and it makes you wonder about the intersection and inflection of those cost curves. And of course we haven’t spent decades optimizing for it. Don't get me wrong.. REST APIs, HTTP, HTML5, all wonderful. But as a user, the cost/benefits of ubiquitous JavaScript in depth simply to win interactivity and single page apps at the cost of um, everything wrong with the web (and by extension much of the world economy via surveillance capitalism) are a bit suspect.
- fsloth 1y ago
  The crazy complexity is stupid. It’s mostly lasagna engineering where the effort is spent to fix the design mistakes in earlier levels. Practically at this point it’s configuring a Skia render context. This gives a known api to target for the graphics stuff. There is near 0 value for designers to pain themselves over this. The design interface should be 85% graphical. The implementation should be a runtime for a configurable context and it should be configurable with code. The ui given to designers should be a graphical tool. There could be many, many such tools! I’m writing this as a graphics engineer who has followed this for over 20 years. I would love to hear engineering based counter arguments to this pov.
andrewstuart 1y ago
This is such a weird outlook. Clearly you’re not doing much front line web development. Web browsers are incredibly capable and all the features they add are making browsers better and life easier for developers and experience better for users. This is the sort of comment that back end developers make, who hate front end development.
- devnullbrain 1y ago
  Comparing this site (that you choose to comment on) to what Reddit has done with those features, I'm not convinced. I will concede the features are very useful for developers to push algorithmic slop and walled gardens onto us.
  - squigz 1y ago
    I don't think HN and reddit are really representative of what the web is or what it's capable of

int0x29 1y ago

This will just gut funding to fix exploits

Brian_K_White 1y ago
Features that don't exist don't have exploits.
- socalgal2 1y ago
  Yea, so instead people make native apps which pown your machine. Great progress!
  - forgotoldacc 1y ago
    Honestly, the end of everything being a chrome-based app and people making actual native desktop apps that run at 10x the speed with 1/10th the energy usage would be excellent. I really hope that does happen.
    - inglor_cz 1y ago
      "that run at 10x the speed with 1/10th the energy usage" How many current developers optimize their products for speed and energy usage? I can see the very opposite happening: half-baked apps, whose massive portions were written using free-tier AI output, hogging gigabytes of RAM and four processor cores while the cursor is idly spinning and the laptop is becoming hot. Compared to the past (and my memory goes back to Netscape Navigator 3, old person that I am), modern browsers seem to be technologically fine.
      - watermelon0 1y ago
        I'd say it's really hard to write a native app, however unoptimized, to be a bigger memory hog than Electron apps.
  - cosmic_cheese 1y ago
    Those at least have to be downloaded and installed by the user, which indicates a high level of intent/consent and is difficult to do accidentally. In the browser environment, malicious content can be navigated to without any user intent or consent whatsoever, which when combined with holes punched in browser sandboxes for the sake of fancy features makes for danger with a dramatically larger scope.
    - DecoySalamander 1y ago
      Right now, most untrusted code runs in the browser's sandbox, and that's great - outside of the realm of fancy 0 days, the damage is limited. But if downloading apps becomes the norm again (like every online store asking you to get their app and an extra app for a discount program), I expect that socially engineering less technical users into downloading malware will become much easier.
  - Brian_K_White 1y ago
    Yes. Native apps are 9000x prefferrable to the browser having to be a shitty os.
    - whatevaa 1y ago
      I guess Linux Desktop will die off then.
      - Ekaros 1y ago
        Maybe it should if in 30 years it has not reliably solved native apps.
        redeeman 1y ago
        funny, it seems to me that a great many native apps exist, and works fine
        Brian_K_White 1y ago
        Been using them for 30 years already. I suspect if I heard whatever your definition of "solved" is, I would find it silly.
mistercheph 1y ago
it will also gut funding for the production of vulnerable code, in what ratio things will go is what it all depends on

dismalaf 1y ago

Reducing features just makes the web less competitive versus native apps, handing control of personal computing back to the MS and Apple duopoly.

layer8 1y ago
Reducing complexity doesn't necessarily mean reducing features. It can mean providing the features in a simpler, more sensible way. The real problem, of course, is backwards compatibility.
- hdjrudni 1y ago
  Aside from a few rushed features, all the things that have been coming to web are really lovely. I'll be very sad if this all slows down. We were just about at feature parity with native mobile apps.
  - taftster 1y ago
    "Almost at parity" in feature set, maybe. But practically? How many sites actually offer an innovative and/or mobile-first version of their website anymore? There was definitely a time when we had websites delivering various layouts based on the viewport size of the user agent. CSS media queries, flexible layouts, etc. were all very important innovations for a very short lived period of time. Now, every serious web presence has moved on to offering their own mobile app, pushing users that direction. The browser was stubborn and erred on the side of privacy. So it didn't quite offer all the integrated (ahem, intrusive) means to interact with the user's device in order to bleed every penny and every bit of data mined from your usage and behaviors. So I don't see anything lovely in the current situation at all. The traditional web -- you know the one where you surf with a web browser to discover the world -- has been dying for quite some time. It might even be dead and we just don't realize it yet. We don't need web browser parity with mobile apps. We just need the web to be what the web is good at. It's a lost cause thinking that the web browser will ever integrate with a portable device quite the same as a native app. Those days are gone.

r0m4n0 1y ago

You do realize, a terrible company will buy chrome and we will be forced to wait until something better arrives (yahoo is interested at the moment). It’s going to get much worse before it gets better.

dsnr 1y ago
Chromium is open source, you can fork it to death while Terrible Company inc. is busy destroying chrome.
- awesome_dude 1y ago
  People can do that right now, but don't. Instead we have endless complaints about what Google does with Chrome, and how complex it is :\
  - Apocryphon 1y ago
    ? https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browsers_based_on_Chromium https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browser...
    - mike_hearn 1y ago
      There are forks but they're very limited in how far they can deviate from what Google wants. The Manifest v3 discussions show this. Extension APIs aren't a big part of browsers compared to all the other things they do, and there was clearly demand to keep Manifest v2 alive, so you'd expect at least one or two forkers to differentiate by doing that. In practice the rebasing costs are so high that everyone shrugged and said they had no choice but to go along with it. Chromium is open source, but not designed for anyone except Google to develop it. Nothing malicious about it, it's just that building a healthy contributor community is a different thing to uploading some source code. If you've ever worked with the Chromium codebase you'll find you have to reverse engineer it to work things out. The codebase is deliberately under-architected (a legacy of the scars of working on Gecko), so many things you'd expect to be well defined re-usable modules that could be worked on independently of Google are actually leaky hacks whose API changes radically depending on what platform you're compiling for, what day of the week it is, etc. Even very basic things like opening a window isn't properly abstracted in a cross platform manner, last time I looked, and at any moment Google might land a giant rewrite they were working on in private for months, obliterating all your work at a stroke. There are reasons for all of this... Chrome is a native app that tries to exploit the native OS as much as possible, and they don't want to be tied down by lowest-common-denominator internal abstractions or API commitments. But if you view Chrome as an OS then the API churn makes Linux look like a stroll through a grassy meadow.

hyperhopper 1y ago

Web browsers that are so complex a person in their basement can't implement them are a sickness. We've gone too far. Give us back html homepages and executables you can run if you'd like something crazier

chii 1y ago
But why isn't the same logic applied to an operating system then? I dont think a browser being more complex than a person can grasp is an important aspect/problem that needs rectifying.
- codr7 1y ago
  Having more options would certainly be nice, and the barrier to entry these days is pretty high.
- Apocryphon 1y ago
  That logic is applied to operating systems, that's why SerenityOS has garnered so much interest.
- swiftcoder 1y ago
  > why isn't the same logic applied to an operating system then? It absolutely should be. And arguably, is - there are multiple tiny OS projects that are somewhat useable
  - chii 1y ago
    and there's plenty of somewhat usable browsers out there too. But the OP's implication is that there ought to be a fully working browser (that satisfies the standards of the day), but creatable from someone in their garage. That hasn't been true for cars, appliances or any modern equipment for ages. And the same phenomenon being applicable to software isn't really that unimaginable (nor a problem).
    - Wobbles42 1y ago

erikerikson 1y ago

I completely appreciate what you're saying. Then I look at the level of crazy complexity and backward compatibility in html/css/js/wasm processing. And then I wonder: what are you actually proposing here?

taftster 1y ago
Going back to gopher as a starting point maybe. Let's innovate from there.
- yjftsjthsd-h 1y ago
  That's a thing, in the form of https://en.wikipedia.org/wiki/Gemini_(protocol) https://en.wikipedia.org/wiki/Gemini_(protocol)
photonthug 1y ago
This is going to be unpopular but.. just to illustrate that we didn’t have to be stuck here. Using things like xpra/xephyr to serve a whole x11 gui over web is surprisingly easy and awesome and like 1/100th the complexity of a modern web stack. This might not be cheap to serve, but it’s cheap to build, and it makes you wonder about the intersection and inflection of those cost curves. And of course we haven’t spent decades optimizing for it. Don't get me wrong.. REST APIs, HTTP, HTML5, all wonderful. But as a user, the cost/benefits of ubiquitous JavaScript in depth simply to win interactivity and single page apps at the cost of um, everything wrong with the web (and by extension much of the world economy via surveillance capitalism) are a bit suspect.
fsloth 1y ago
The crazy complexity is stupid. It’s mostly lasagna engineering where the effort is spent to fix the design mistakes in earlier levels. Practically at this point it’s configuring a Skia render context. This gives a known api to target for the graphics stuff. There is near 0 value for designers to pain themselves over this. The design interface should be 85% graphical. The implementation should be a runtime for a configurable context and it should be configurable with code. The ui given to designers should be a graphical tool. There could be many, many such tools! I’m writing this as a graphics engineer who has followed this for over 20 years. I would love to hear engineering based counter arguments to this pov.

andrewstuart 1y ago

This is such a weird outlook. Clearly you’re not doing much front line web development. Web browsers are incredibly capable and all the features they add are making browsers better and life easier for developers and experience better for users. This is the sort of comment that back end developers make, who hate front end development.

devnullbrain 1y ago
Comparing this site (that you choose to comment on) to what Reddit has done with those features, I'm not convinced. I will concede the features are very useful for developers to push algorithmic slop and walled gardens onto us.
- squigz 1y ago
  I don't think HN and reddit are really representative of what the web is or what it's capable of