4 ms·

Browsers are doing well. I'm more worried about the fact the browser is turning into the entire operating system these days. Even the apps use the browser engin

Browsers are doing well. I'm more worried about the fact the browser is turning into the entire operating system these days. Even the apps use the browser engine for a lot of functionality these days. It's like a parasite, the OS is being eaten inside out. I'd be fine with this, it's a typical disruption process. Except the browser stack is full of legacy features, is bloated, and I'd hate for this to be the de-facto platform for "everything" going forward. The joke that JavaScript will become a virtual machine which will then be implemented in hardware and be the only way to do everything is not THAT far from reality.

rezonant 4y ago
The web is not an exception when put next to macOS (it's core remains mostly unchanged since Next) and Windows (literally can still run Win16 apps). The perfect API is the enemy of adoption and that's not going to change.
DaiPlusPlus 4y ago
> Except the browser stack is full of legacy features Examples?
- rezonant 4y ago
  I don't agree with GP's sentiment but one need only look at Number.parseInt vs parseInt and the associates coercion differences, and even typeof null which was on the front page today. Lots of cumbersome APIs like XHR and others designed before Promises existed, and even smooshgate, where we couldn't introduce flatten() because Prototype (iirc) implemented it already and failed to properly handle the possibility that the browser could already have it (plus it worked differently where the default depth of the new standard API is 2).
flohofwoe 4y ago
The browser turning into an operating system (or rather a separate meta-platform that provides a common wrapper over operating system services) has already happened a long time ago. And while many web APIs indeed 'suck', they're still roughly in the same ballpark as traditional OS APIs when it comes to legacy features, unfixable design warts and general 'pain of use' (e.g. it's not like native development is all rainbow-farting unicorns, while web development is eternal pain and suffering - it's both 'mildly annoying' most of the time).
- philistine 4y ago
  The opposing opinion would be that changes of vital OS features has happened to all the operating systems. Users expect a new version of software to run on newer operating systems. The web has never deprecated anything close to vital. We're stuck, seemingly, with everything ever conceived.
  - flohofwoe 4y ago
    I would argue that most users expect that their software continues to work on new operating system versions without being forced to upgrade (which is easy for free software, but less so if the upgrade costs money and the users are entirely happy with the feature set of their current version). PS: also, looking at Windows specifically, new operating system API layers don't necessarily mean that they are an improvement over the older APIs.
  - tacotime 4y ago
    Firefox has deprecated support for FTP, RSS feeds. Web extensions using manifest version 2 are being deprecated in Chrome, removing substantial capabilities. Whether these features are "close to vital" is debatable but certainly some functionality that used to be ubiquitous are being removed.
    - philistine 4y ago
      That’s not what I was thinking. I was thinking more of deprecating some elements of JavaScript that prevent speed gains.
pffft8888 4y ago
Browsers are using what the OS provides. I am not aware of any browser reimplementing Vulcan, DirectX or Metal, nor am I familiar with any browser reimplementing any feature of the underlying OS. It's just an application where you can build other applications and it provides access to some OS features via a scripting (higher level) language that's highly imperfect but thoroughly documented and used by millions. Speaking of hardware implementation for browser runtime, I just googled in the direction of WASM-in-hardware and came across this: https://github.com/lastmjs/wasm-metal https://github.com/lastmjs/wasm-metal
- KingLancelot 4y ago
  [dead]
- doctor_eval 4y ago
  > nor am I familiar with any browser reimplementing any feature of the underlying OS. Well QUIC is replacing TCP for many HTTP connections now, and that’s implemented entirely in the browser. The OS provides the datagram layer but at this point it’s semantics. The bulk of the protocol is in the browser.
  - pffft8888 4y ago
    Yes, Quic still relies on UDP. So that's like many other non-TCP protocols that are built by vendors on top of UDP for all sorts of applications. It still uses the OS layer for UDP, which is what many other applications do.
    - doctor_eval 4y ago
      I disagree. UDP is stateless, all the heavy lifting for the connection oriented protocol is being done in the browser. It is literally replacing the kernels TCP stack, a service the operating system has supplied for decades. The question was, has a browser has taken anything over from the OS, and the answer is - in this case - yes. It still uses the OS to control access to the network, but the role of the OS in HTTP has been significantly reduced.
chaxor 4y ago
Dedicated JavaScript processor sounds interesting. I wonder who will do the JPU first, and how many requests it will send per second to IP addresses you didn't ask it to send.
toastal 4y ago
But this also allows launching points for new OSs and less supported OSs to get ‘application’ support from many vendors that don't yet support a native app—especially of the proprietary variety where maintainers can't build it themselves. Entire OSs have been built on this model: Firefox OS, Chrome OS, KaiOS, Capyloon, Peppermint OS.
dghughes 4y ago
Or Boot from Google, Boogle?
jckahn 4y ago
> I'd hate for this to be the de-facto platform for "everything" going forward. How come? It seems like a positive, user-empowering shift to me.
- BulgarianIdiot 4y ago
  How does it empower the user, you think?
  - jckahn 4y ago
    Because users can control their experience more than any other platform. All browsers have powerful devtools built in and users can freely install extensions to enhance their experience. And the source (or at least executing) code cannot be hidden. The array of options at browser users’ disposal is unmatched.
forgotmypw17 4y ago
I personally love the legacy features. There are fewer of them than you may think, but the ones that have stuck around are now 25 years stable. This means that if you're careful about which features you use, you have a reasonable chance of your application not breaking randomly for 25 years ahead (Lindy Effect)

rezonant 4y ago

The web is not an exception when put next to macOS (it's core remains mostly unchanged since Next) and Windows (literally can still run Win16 apps). The perfect API is the enemy of adoption and that's not going to change.

DaiPlusPlus 4y ago

> Except the browser stack is full of legacy features Examples?

rezonant 4y ago
I don't agree with GP's sentiment but one need only look at Number.parseInt vs parseInt and the associates coercion differences, and even typeof null which was on the front page today. Lots of cumbersome APIs like XHR and others designed before Promises existed, and even smooshgate, where we couldn't introduce flatten() because Prototype (iirc) implemented it already and failed to properly handle the possibility that the browser could already have it (plus it worked differently where the default depth of the new standard API is 2).

flohofwoe 4y ago

The browser turning into an operating system (or rather a separate meta-platform that provides a common wrapper over operating system services) has already happened a long time ago. And while many web APIs indeed 'suck', they're still roughly in the same ballpark as traditional OS APIs when it comes to legacy features, unfixable design warts and general 'pain of use' (e.g. it's not like native development is all rainbow-farting unicorns, while web development is eternal pain and suffering - it's both 'mildly annoying' most of the time).

philistine 4y ago
The opposing opinion would be that changes of vital OS features has happened to all the operating systems. Users expect a new version of software to run on newer operating systems. The web has never deprecated anything close to vital. We're stuck, seemingly, with everything ever conceived.
- flohofwoe 4y ago
  I would argue that most users expect that their software continues to work on new operating system versions without being forced to upgrade (which is easy for free software, but less so if the upgrade costs money and the users are entirely happy with the feature set of their current version). PS: also, looking at Windows specifically, new operating system API layers don't necessarily mean that they are an improvement over the older APIs.
- tacotime 4y ago
  Firefox has deprecated support for FTP, RSS feeds. Web extensions using manifest version 2 are being deprecated in Chrome, removing substantial capabilities. Whether these features are "close to vital" is debatable but certainly some functionality that used to be ubiquitous are being removed.
  - philistine 4y ago
    That’s not what I was thinking. I was thinking more of deprecating some elements of JavaScript that prevent speed gains.

pffft8888 4y ago

Browsers are using what the OS provides. I am not aware of any browser reimplementing Vulcan, DirectX or Metal, nor am I familiar with any browser reimplementing any feature of the underlying OS. It's just an application where you can build other applications and it provides access to some OS features via a scripting (higher level) language that's highly imperfect but thoroughly documented and used by millions. Speaking of hardware implementation for browser runtime, I just googled in the direction of WASM-in-hardware and came across this: https://github.com/lastmjs/wasm-metal https://github.com/lastmjs/wasm-metal

KingLancelot 4y ago
[dead]
doctor_eval 4y ago
> nor am I familiar with any browser reimplementing any feature of the underlying OS. Well QUIC is replacing TCP for many HTTP connections now, and that’s implemented entirely in the browser. The OS provides the datagram layer but at this point it’s semantics. The bulk of the protocol is in the browser.
- pffft8888 4y ago
  Yes, Quic still relies on UDP. So that's like many other non-TCP protocols that are built by vendors on top of UDP for all sorts of applications. It still uses the OS layer for UDP, which is what many other applications do.
  - doctor_eval 4y ago
    I disagree. UDP is stateless, all the heavy lifting for the connection oriented protocol is being done in the browser. It is literally replacing the kernels TCP stack, a service the operating system has supplied for decades. The question was, has a browser has taken anything over from the OS, and the answer is - in this case - yes. It still uses the OS to control access to the network, but the role of the OS in HTTP has been significantly reduced.

chaxor 4y ago

Dedicated JavaScript processor sounds interesting. I wonder who will do the JPU first, and how many requests it will send per second to IP addresses you didn't ask it to send.

toastal 4y ago

But this also allows launching points for new OSs and less supported OSs to get ‘application’ support from many vendors that don't yet support a native app—especially of the proprietary variety where maintainers can't build it themselves. Entire OSs have been built on this model: Firefox OS, Chrome OS, KaiOS, Capyloon, Peppermint OS.

dghughes 4y ago

Or Boot from Google, Boogle?

jckahn 4y ago

> I'd hate for this to be the de-facto platform for "everything" going forward. How come? It seems like a positive, user-empowering shift to me.

BulgarianIdiot 4y ago
How does it empower the user, you think?
- jckahn 4y ago
  Because users can control their experience more than any other platform. All browsers have powerful devtools built in and users can freely install extensions to enhance their experience. And the source (or at least executing) code cannot be hidden. The array of options at browser users’ disposal is unmatched.

forgotmypw17 4y ago

I personally love the legacy features. There are fewer of them than you may think, but the ones that have stuck around are now 25 years stable. This means that if you're careful about which features you use, you have a reasonable chance of your application not breaking randomly for 25 years ahead (Lindy Effect)