8 ms·

I'm sorry but how would making browsers the operating system cause the incompatability problems to reappear? I think this is massively ignoring the realities:

by rtpg 11y ago

I'm sorry but how would making browsers the operating system cause the incompatability problems to reappear? I think this is massively ignoring the realities: - there's almost no native-feeling cross-platform UI library for native apps at the moment - There's a standard for most things happening in a browser, which means that things look pixel-perfectly the same on a huge amount of browsers. Differences among current browsers are more among performance and experimental features So currently, if Google, Apple, and MSFT decided to jointly ban all native apps and only have a web browser on their smartphones, we would have a much better compatability situation, since so much functionality has been standardised on that end, and _actually respected_. The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence.

pikzen 11y ago
>there's almost no native-feeling cross-platform UI library for native apps at the moment Xamarin.Forms is the closest I can think of. Qt too, kind of. >The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence. It's true, the browser succeeded as a working everywhere JVM equivalent. It also succeeded at reimplementing half of your OS features, being another massive source of security issues, being inefficient with resources (chrome memory usage lol), having piss poor perfomance and locking everything to Javascript. Compiling to Javascript is not a solution. A proper bytecode is. Which we may have with WebAssembly as soon as it's implemented and the standard respected by browser builders (which will probably be around 2040). Until Google decides to add a new WA feature that's incompatible with other browsers because that's what Google does. Let's not get started on the fact that HTML is a terrible language for UIs and that any Javascript based solution is not a solution at all (i.e. React is still crap, as is Meteor and javascript.framework.of.the.day.js). The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page. > if Google, Apple, and MSFT decided to jointly ban all native apps and only have a web browser on their smartphones, we would have a much better compatability situation, since so much functionality has been standardised on that end, and _actually respected_. 1. We've been hoping to get at least TWO browser vendors to fully collaborate for the last 20 years and it has not happened. It won't happen. 2. Performance will still be crap. 3. I'd rather not get locked to Google's piss poor record of updating the stock Android browser. In fact, I'd rather not get locked to Google's piss poor software at all, thank you very much. The same argument applies to Apple and Microsoft. Safari is awful, and so is IE/Edge.
- apalmer 11y ago
  I get where your coming from, and agree with a lot of what you say. BUT, Fundamentally... >The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page. Is just not a true statement. Or rather, the web sucks, but it is the only cross platform UI experiment that has 'worked' on any significant level.
  - ForHackernews 11y ago
    > the only cross platform UI experiment that has 'worked' on any significant level. Users do not care about cross-platform compatibility, at all. They only care that it works on their platform. As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc. The only people who should be upset about cross-platform compatibility issues are budget-conscious managers and unfortunate OSS devs.
    - ectoplasm 11y ago
      > Users do not care about cross-platform compatibility, at all. I've heard that some users have both a phone and a laptop.
      - pyre 11y ago
        No one has a laptop anymore. We're in the "post PC" era, haven't you heard?
    - MacsHeadroom 11y ago
      >As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc. This is like saying "As construction workers we should be cheering for natural disasters, because there will be more work for construction workers to rebuild destroyed cities." Job security is great- but at what cost? I'd rather see developers making completely new things than wasting time porting from one native platform to another.
vezzy-fnord 11y ago
There's a standard for most things happening in a browser There's POSIX, too. In practice, divergences are plentiful. Differences among current browsers are more among performance and experimental features The fact that are huge web tables meticulously documenting feature compatibilities across browsers implies differently. Besides, a lot of web standards are done post-facto. I don't see the situation as being any better than POSIX. It might even be worse.
- the8472 11y ago
  > There's POSIX POSIX + a standard library for UI components + containerization + webassembly would be the "correct", cleanroom solution in my opinion. If you want to build and run "native but untrusted" applications on the user's computer on heterogenous environments and can't anticipate which APIs someone is going to need next. Well then give them access to a walled-off part of the computer. Same-origin policy? Replace it with a l7 firewall (+ some DNS security manifests?) No cookies/local storage? That just means spinning up a new container every time the user visits. No audio playback? Don't map the sound device into the container. Etc.
  - vezzy-fnord 11y ago
    Sounds like you're really poorly reinventing Inferno. I don't even understand why you would need WebAssembly in this hypothetical scheme. Container namespacing isn't fine-grained enough, and much of this is the result of traditional Unix-likes having large disparities between different ways of naming things that cannot be composed. The Spring solution was to have all of these descend from a name service, and the Plan 9/Inferno solution to have all resources be multiplexed into virtual file systems (i.e. one way of naming things). Furthermore, the inclusion of containers here gives you a worst-of-both-worlds approach. You're not even detaching resource subsystems from a unit of execution's POV, you're cloning the entire OS namespace modulo disallowed subsystems for every unit of execution. That's a combinatorial explosion of the state space. It also means complicated solutions to the problem of resource management and communication within and between containers, which is a problem when virtualization occurs at a too high level. In contrast, virtualization at the process/task level with OS-wide capabilities for single-system imaging and a heavily integrated subsystem for naming things (either a one true approach or a prototype-based one) means you can configure a system like it's a whole unit without sacrificing security. Then it's not like POSIX is even that great. Why should a process be associated with one uid? Why can't I dynamically attach and remove capability tokens from processes while they're running, like the Hurd does it?
adrusi 11y ago
You're right, there's no native-feeling cross-platform UI library for native apps, and the browser isn't poised to be an exception to that. Apps made in the browser don't feel native. The closest to native-feeling app built in a browser that I can think of is Atom, which feels like a more sluggish version of Sublime (a Qt app). Neither of them feel as native as truly native apps do on their native platforms. Not nearly as native as Gedit on GNOME, Kate on KDE, Notepad++ on Windows or TextMate/BBedit on Mac. And they never will because the native feel comes from paying close attention to the design language and behavior of your app with respect to the host platform. If a cross platform app really paid close enough attention to these things to make a difference, they may as well completely rewrite their UI layer on all platforms.
Shorel 11y ago
>there's almost no native-feeling cross-platform UI library for native apps at the moment wxWidgets is native and it has been working for decades now. May be some people disagree with its use of macros, but it certainly works, runs fast and it's native in Windows, OSX and Linux. I repeat it again. It's not only native-feeling. It uses the native controls in each platform it supports. It is fully native.
- gull 11y ago
  I'm curious about this. Does something like wxWidgets offer all widgets that are available in an OS? Does it offer the files listing widget the Mac has in that fourth mode, where flipping between files shows on top an extra area that feels like flipping between music CDs? I guess the point is, what do you do with widgets available in one OS that aren't available in another? Should UI libraries keep up?
  - Shorel 11y ago
    It keeps up in some cases, as some dialog options are only available for one platform and ignored in the rest. But it is updated slowly, i.e. the platform has a new widget and the corresponding wxWidgets update happens several months later. You can check for example Audacity in your platform and evaluate if it feels native enough.
- comex 11y ago
  It is more native than toolkits which try to recreate the controls themselves. But I would not call it "fully native", because it does not let you write cross-platform fully native-feeling apps. It fails at that for the simple reason that that is impossible: different platforms have different UI conventions, including icon appearance, controls with no direct equivalents on other platforms, or with equivalents that have subtle differences in usage, idioms and standard layouts, behavior of keyboard shortcuts and gestures, use of platform-specific features, etc. If you do not spend a significant amount of time tuning your UI for each, you may end up with something that's 80% right, but it will never be 100% right. Also, wxWidgets has had a lot of problems lately on OS X: high-DPI not being supported properly for years, broken focus, other bugs. It's not just the macros that make it an icky framework, which I say from unfortunate first-hand experience.
GrinningFool 11y ago
> There's a standard for most things happening in a browser, which means that things look pixel-perfectly the same on a huge amount of browsers <snip>he browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence. That's a good theory. My experience as a consumer of web sites across chrome, firefox, chrome on mobile, and firefox on mobile leaves me with a perspective more aligned with reality than theory. The same pages vary widely across these platforms. It's not uncommon for form fields to be illegible on one or more of them, layout is different, readability is different. Maybe once we get that little problem ironed out (whether it be people building websites badly or things aren't as compatible as they should be, I don't know) we can talk about taking it further...
- simoncion 11y ago
  Agreed. I feel a little twinge every time I hear someone say that something on The Web should be or is "pixel perfect". That phrase has a particular -and obvious- definition; one that is rarely correct when speaking of a web page that is viewed in more than one browser and/or on more than one machine.
emehrkay 11y ago
> The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence. I'd say Flash is better than a browser. Flash seems to fall apart when embedded into a browser, but stand-alone it is decent. And it's IDE/tooling is top notch too.

by rtpg 11y ago

pikzen 11y ago

>there's almost no native-feeling cross-platform UI library for native apps at the moment Xamarin.Forms is the closest I can think of. Qt too, kind of. >The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence. It's true, the browser succeeded as a working everywhere JVM equivalent. It also succeeded at reimplementing half of your OS features, being another massive source of security issues, being inefficient with resources (chrome memory usage lol), having piss poor perfomance and locking everything to Javascript. Compiling to Javascript is not a solution. A proper bytecode is. Which we may have with WebAssembly as soon as it's implemented and the standard respected by browser builders (which will probably be around 2040). Until Google decides to add a new WA feature that's incompatible with other browsers because that's what Google does. Let's not get started on the fact that HTML is a terrible language for UIs and that any Javascript based solution is not a solution at all (i.e. React is still crap, as is Meteor and javascript.framework.of.the.day.js). The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page. > if Google, Apple, and MSFT decided to jointly ban all native apps and only have a web browser on their smartphones, we would have a much better compatability situation, since so much functionality has been standardised on that end, and _actually respected_. 1. We've been hoping to get at least TWO browser vendors to fully collaborate for the last 20 years and it has not happened. It won't happen. 2. Performance will still be crap. 3. I'd rather not get locked to Google's piss poor record of updating the stock Android browser. In fact, I'd rather not get locked to Google's piss poor software at all, thank you very much. The same argument applies to Apple and Microsoft. Safari is awful, and so is IE/Edge.

apalmer 11y ago
I get where your coming from, and agree with a lot of what you say. BUT, Fundamentally... >The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page. Is just not a true statement. Or rather, the web sucks, but it is the only cross platform UI experiment that has 'worked' on any significant level.
- ForHackernews 11y ago
  > the only cross platform UI experiment that has 'worked' on any significant level. Users do not care about cross-platform compatibility, at all. They only care that it works on their platform. As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc. The only people who should be upset about cross-platform compatibility issues are budget-conscious managers and unfortunate OSS devs.
  - ectoplasm 11y ago
    > Users do not care about cross-platform compatibility, at all. I've heard that some users have both a phone and a laptop.
    - pyre 11y ago
      No one has a laptop anymore. We're in the "post PC" era, haven't you heard?
  - MacsHeadroom 11y ago
    >As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc. This is like saying "As construction workers we should be cheering for natural disasters, because there will be more work for construction workers to rebuild destroyed cities." Job security is great- but at what cost? I'd rather see developers making completely new things than wasting time porting from one native platform to another.

vezzy-fnord 11y ago

There's a standard for most things happening in a browser There's POSIX, too. In practice, divergences are plentiful. Differences among current browsers are more among performance and experimental features The fact that are huge web tables meticulously documenting feature compatibilities across browsers implies differently. Besides, a lot of web standards are done post-facto. I don't see the situation as being any better than POSIX. It might even be worse.

the8472 11y ago
> There's POSIX POSIX + a standard library for UI components + containerization + webassembly would be the "correct", cleanroom solution in my opinion. If you want to build and run "native but untrusted" applications on the user's computer on heterogenous environments and can't anticipate which APIs someone is going to need next. Well then give them access to a walled-off part of the computer. Same-origin policy? Replace it with a l7 firewall (+ some DNS security manifests?) No cookies/local storage? That just means spinning up a new container every time the user visits. No audio playback? Don't map the sound device into the container. Etc.
- vezzy-fnord 11y ago
  Sounds like you're really poorly reinventing Inferno. I don't even understand why you would need WebAssembly in this hypothetical scheme. Container namespacing isn't fine-grained enough, and much of this is the result of traditional Unix-likes having large disparities between different ways of naming things that cannot be composed. The Spring solution was to have all of these descend from a name service, and the Plan 9/Inferno solution to have all resources be multiplexed into virtual file systems (i.e. one way of naming things). Furthermore, the inclusion of containers here gives you a worst-of-both-worlds approach. You're not even detaching resource subsystems from a unit of execution's POV, you're cloning the entire OS namespace modulo disallowed subsystems for every unit of execution. That's a combinatorial explosion of the state space. It also means complicated solutions to the problem of resource management and communication within and between containers, which is a problem when virtualization occurs at a too high level. In contrast, virtualization at the process/task level with OS-wide capabilities for single-system imaging and a heavily integrated subsystem for naming things (either a one true approach or a prototype-based one) means you can configure a system like it's a whole unit without sacrificing security. Then it's not like POSIX is even that great. Why should a process be associated with one uid? Why can't I dynamically attach and remove capability tokens from processes while they're running, like the Hurd does it?

adrusi 11y ago

You're right, there's no native-feeling cross-platform UI library for native apps, and the browser isn't poised to be an exception to that. Apps made in the browser don't feel native. The closest to native-feeling app built in a browser that I can think of is Atom, which feels like a more sluggish version of Sublime (a Qt app). Neither of them feel as native as truly native apps do on their native platforms. Not nearly as native as Gedit on GNOME, Kate on KDE, Notepad++ on Windows or TextMate/BBedit on Mac. And they never will because the native feel comes from paying close attention to the design language and behavior of your app with respect to the host platform. If a cross platform app really paid close enough attention to these things to make a difference, they may as well completely rewrite their UI layer on all platforms.

Shorel 11y ago

>there's almost no native-feeling cross-platform UI library for native apps at the moment wxWidgets is native and it has been working for decades now. May be some people disagree with its use of macros, but it certainly works, runs fast and it's native in Windows, OSX and Linux. I repeat it again. It's not only native-feeling. It uses the native controls in each platform it supports. It is fully native.

gull 11y ago
I'm curious about this. Does something like wxWidgets offer all widgets that are available in an OS? Does it offer the files listing widget the Mac has in that fourth mode, where flipping between files shows on top an extra area that feels like flipping between music CDs? I guess the point is, what do you do with widgets available in one OS that aren't available in another? Should UI libraries keep up?
- Shorel 11y ago
  It keeps up in some cases, as some dialog options are only available for one platform and ignored in the rest. But it is updated slowly, i.e. the platform has a new widget and the corresponding wxWidgets update happens several months later. You can check for example Audacity in your platform and evaluate if it feels native enough.
comex 11y ago
It is more native than toolkits which try to recreate the controls themselves. But I would not call it "fully native", because it does not let you write cross-platform fully native-feeling apps. It fails at that for the simple reason that that is impossible: different platforms have different UI conventions, including icon appearance, controls with no direct equivalents on other platforms, or with equivalents that have subtle differences in usage, idioms and standard layouts, behavior of keyboard shortcuts and gestures, use of platform-specific features, etc. If you do not spend a significant amount of time tuning your UI for each, you may end up with something that's 80% right, but it will never be 100% right. Also, wxWidgets has had a lot of problems lately on OS X: high-DPI not being supported properly for years, broken focus, other bugs. It's not just the macros that make it an icky framework, which I say from unfortunate first-hand experience.

GrinningFool 11y ago

> There's a standard for most things happening in a browser, which means that things look pixel-perfectly the same on a huge amount of browsers <snip>he browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence. That's a good theory. My experience as a consumer of web sites across chrome, firefox, chrome on mobile, and firefox on mobile leaves me with a perspective more aligned with reality than theory. The same pages vary widely across these platforms. It's not uncommon for form fields to be illegible on one or more of them, layout is different, readability is different. Maybe once we get that little problem ironed out (whether it be people building websites badly or things aren't as compatible as they should be, I don't know) we can talk about taking it further...

simoncion 11y ago
Agreed. I feel a little twinge every time I hear someone say that something on The Web should be or is "pixel perfect". That phrase has a particular -and obvious- definition; one that is rarely correct when speaking of a web page that is viewed in more than one browser and/or on more than one machine.

emehrkay 11y ago

> The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence. I'd say Flash is better than a browser. Flash seems to fall apart when embedded into a browser, but stand-alone it is decent. And it's IDE/tooling is top notch too.