5 ms·

I hope the next logical step implied here after this is NOT going back to native applications for everything. Out of curiosity, why? I always thought the model

I hope the next logical step implied here after this is NOT going back to native applications for everything. Out of curiosity, why? I always thought the model of static documents was a conceptual fit for the web, thinking of it as a file server. The move towards SPAs and real-time apps is really showing the browser's inner-platform effect, and the rough edges of the APIs thereof. Since we are using techniques to create a full parallel OS runtime inside the browser, I wouldn't be surprised if a surge of interest from web developers emerged into simply using the host OS again. By and large I believe the ideal of the browser as being the universal WORA platform to be largely bunk, in that cross-browser compatibility has always been grueling, with the reliance on polyfills and all sorts of ECMAScript and browser API incompatibilities persisting to the point where entire tables and guides are being drawn about them. In hindsight this should have been unsurprising. Just like the Unixes diverge, so do the browsers.

bobajeff 11y ago
Unless there is a vendor neutral standard for applications you get into the situation where only a few vendors get massive power dictate to everyone (users, developers, manufacturers) the terms in which they get access to the platform. Now the web isn't perfect but it's the closest thing to a commercially successful vendor neutral software platform in existence.
- vezzy-fnord 11y ago
  The vendor neutral standard for Unix-likes is POSIX, and by some extension Windows to the degree it has compatibility, or that it can be bolted on to via Cygwin or whatnot. Windows itself is a proprietary platform, but it has no central software repository, so developers distribute their software through all sorts of means. Market share means influence on OEMs is exherted, but is it not also the case that if, e.g. Chrome, becomes a dominant browser that they do not exhibit de facto diktat over many aspects of the web? Android's central platform is Google Play, but you are under no obligation to use it. You may opt for F-Droid or fetching lone APKs. It seems to me the only platform where central curation is so ingrained that alternatives become impractical, is iOS. Not to mention the web, despite being ostensibly vendor neutral, comes with a big problem of its own. Now every single page you interact with, no matter how primitive, is behind the scenes potentially a distributed, unobservable, multi-tier networked application with who knows how many layers of caching proxies, CDNs, ad trackers, analytics, data processing pipelines, etc. etc. with no way of knowing what's changing.
  - meddlepal 11y ago
    Another problem with the web is that every application has a massively different look and feel. I'm not just talking colors here, but some forms validate inputs as they are put it and others don't respond until you hit submit. Etc. There is no common UX for the web and IMO that sucks.
    - copperx 11y ago
      I think you are mistaken -- the web is more consistent that, say, the Windows GUI ever was. Yes, there are small quirks like the one that you describe, but in general, most users don't need to learn how to use a webpage. Have you ever seen a novice wrestle with a native GUI? It's horrific.
  - ubernostrum 11y ago
    The vendor neutral standard for Unix-likes is POSIX And look how well that turned out!
  - bobajeff 11y ago
    POSIX only covers the API's not the ABI's the software will run on. Also, that still leaves them running on a vendor specific CPU architecture. Your naive if you believe Microsoft and Google don't hold all the cards with thier platforms. More and more of Android is being swallowed up by Google Play Services. Windows does have a central software repository called "Windows Store". Let's not forget about how users have to put up with thier shenanigans because they are the gatekeepers to apps.
krick 11y ago
I would want very much to go back to "native apps for everything", but it seems we went too far to be able to turn back. So this idea is for some better world where communism wins and everyone lives happily. Or whatever. Let's recap what was there in the previous series… 1. Some folks made a network out of several computers and saw that they can now exchange information without sending mail and picking up a phone. Cool. 2. Some guys invented a simple protocol to assign address to every piece of information we would like to exchange. They invented HTML, to be able to put these addresses in the body of the document. Also, why don't we make several keywords to make that information a bit more structured? We'll use SGML as a base, because it's trendy. 3. More programs to use these protocol and markup language appear, markup transforms further to be able to add images to the body of the document and so on. 4. Somebody comes up with the idea that markup should give a structure to the information, and there should be another document — stylesheet — to describe what that stuff should look like. It also has to be cascade, because he's smart. 5. At this point things are pretty bad already, because there are many programs to interpret this protocol, and they are fighting with each other over the audience. But if back then people would make HTML and CSS "good enough" the idea of separating content and representation would have worked out and we'd have what we are talking about now… 6. …But something more interesting happens, and instead of plain simple document-exchange system we now have plugins, then applets, then javascript, then web2.0, ajax, interactive applications right in the browser. It isn't possible anymore for markup to be content and for everything else to be representation, because both are changing in real time, as user pushes buttons. And there're even more browsers to interpret this madness, and they are fighting with each other as never before. 7. Also, now we have some major evil corporations, that have lots of money to shape the technology world as they want, and they want to own all our data, which means making as many useful apps as possible server-side: which means moving all major client-side apps to the browser. 8. Now every site is fancy app, drawn by designers in Photoshop, then painfully re-created in html, css and js. Thousands of libraries and "frameworks" are made to make this "creating app in the browser" process comfortable, but they don't succeed. Although it's now somewhat easier than making native apps, because hardly anyone cares about them anymore. We achieve a point when HTML — no longer actually relevant thing in this world of interactive madness — seems to be "good enough" to stop evolving. We look back at #5 — browser as an app to show simple documents — and sigh. It would be good, but the whole world uses our in-browser-apps now. It is what customer is used to. We can't make our "simple" stuff, because nobody cares about simple.

bobajeff 11y ago

Unless there is a vendor neutral standard for applications you get into the situation where only a few vendors get massive power dictate to everyone (users, developers, manufacturers) the terms in which they get access to the platform. Now the web isn't perfect but it's the closest thing to a commercially successful vendor neutral software platform in existence.

vezzy-fnord 11y ago
The vendor neutral standard for Unix-likes is POSIX, and by some extension Windows to the degree it has compatibility, or that it can be bolted on to via Cygwin or whatnot. Windows itself is a proprietary platform, but it has no central software repository, so developers distribute their software through all sorts of means. Market share means influence on OEMs is exherted, but is it not also the case that if, e.g. Chrome, becomes a dominant browser that they do not exhibit de facto diktat over many aspects of the web? Android's central platform is Google Play, but you are under no obligation to use it. You may opt for F-Droid or fetching lone APKs. It seems to me the only platform where central curation is so ingrained that alternatives become impractical, is iOS. Not to mention the web, despite being ostensibly vendor neutral, comes with a big problem of its own. Now every single page you interact with, no matter how primitive, is behind the scenes potentially a distributed, unobservable, multi-tier networked application with who knows how many layers of caching proxies, CDNs, ad trackers, analytics, data processing pipelines, etc. etc. with no way of knowing what's changing.
- meddlepal 11y ago
  Another problem with the web is that every application has a massively different look and feel. I'm not just talking colors here, but some forms validate inputs as they are put it and others don't respond until you hit submit. Etc. There is no common UX for the web and IMO that sucks.
  - copperx 11y ago
    I think you are mistaken -- the web is more consistent that, say, the Windows GUI ever was. Yes, there are small quirks like the one that you describe, but in general, most users don't need to learn how to use a webpage. Have you ever seen a novice wrestle with a native GUI? It's horrific.
- ubernostrum 11y ago
  The vendor neutral standard for Unix-likes is POSIX And look how well that turned out!
- bobajeff 11y ago
  POSIX only covers the API's not the ABI's the software will run on. Also, that still leaves them running on a vendor specific CPU architecture. Your naive if you believe Microsoft and Google don't hold all the cards with thier platforms. More and more of Android is being swallowed up by Google Play Services. Windows does have a central software repository called "Windows Store". Let's not forget about how users have to put up with thier shenanigans because they are the gatekeepers to apps.

krick 11y ago

I would want very much to go back to "native apps for everything", but it seems we went too far to be able to turn back. So this idea is for some better world where communism wins and everyone lives happily. Or whatever. Let's recap what was there in the previous series… 1. Some folks made a network out of several computers and saw that they can now exchange information without sending mail and picking up a phone. Cool. 2. Some guys invented a simple protocol to assign address to every piece of information we would like to exchange. They invented HTML, to be able to put these addresses in the body of the document. Also, why don't we make several keywords to make that information a bit more structured? We'll use SGML as a base, because it's trendy. 3. More programs to use these protocol and markup language appear, markup transforms further to be able to add images to the body of the document and so on. 4. Somebody comes up with the idea that markup should give a structure to the information, and there should be another document — stylesheet — to describe what that stuff should look like. It also has to be cascade, because he's smart. 5. At this point things are pretty bad already, because there are many programs to interpret this protocol, and they are fighting with each other over the audience. But if back then people would make HTML and CSS "good enough" the idea of separating content and representation would have worked out and we'd have what we are talking about now… 6. …But something more interesting happens, and instead of plain simple document-exchange system we now have plugins, then applets, then javascript, then web2.0, ajax, interactive applications right in the browser. It isn't possible anymore for markup to be content and for everything else to be representation, because both are changing in real time, as user pushes buttons. And there're even more browsers to interpret this madness, and they are fighting with each other as never before. 7. Also, now we have some major evil corporations, that have lots of money to shape the technology world as they want, and they want to own all our data, which means making as many useful apps as possible server-side: which means moving all major client-side apps to the browser. 8. Now every site is fancy app, drawn by designers in Photoshop, then painfully re-created in html, css and js. Thousands of libraries and "frameworks" are made to make this "creating app in the browser" process comfortable, but they don't succeed. Although it's now somewhat easier than making native apps, because hardly anyone cares about them anymore. We achieve a point when HTML — no longer actually relevant thing in this world of interactive madness — seems to be "good enough" to stop evolving. We look back at #5 — browser as an app to show simple documents — and sigh. It would be good, but the whole world uses our in-browser-apps now. It is what customer is used to. We can't make our "simple" stuff, because nobody cares about simple.