4 ms·

> I am hopeful that in my lifetime, the web will die. I'd like to see the www go back to its roots as a way to share and browse documents, hyperlinked together

> I am hopeful that in my lifetime, the web will die. I'd like to see the www go back to its roots as a way to share and browse documents, hyperlinked together. The web worked when it was just documents to render and click on links. It is terrible as an application platform. It's been 30 years since JavaScript was invented. Imagine what we'd have today, if instead of making the WWW into this half-assed application platform, those 30 years of collective brainpower were instead spent on making a great cross-platform native application development and delivery system!

scarface_74 2y ago
Native for Windows, Macs, Linux, iPhones and Android devices? Now imagine trying to update all of those native apps across a large enterprise or multiple large enterprises. Since I do use multiple devices, when everything is on the web, you also don’t have to worry about syncing or conflict resolution like you do with semi connected scenarios.
- ryandrake 2y ago
  > Native for Windows, Macs, Linux, iPhones and Android devices? > Now imagine trying to update all of those native apps across a large enterprise or multiple large enterprises. With the tools we have now, it would absolutely not work. In my post I was imagining a parallel alternate universe where native development tools got all the brainpower and innovation over the last 30 years, instead of the web tools getting it.
  - mjevans 2y ago
    The web got it because for some _insane_ reason, websites were able to convince IT departments to allow scripts to run. That left the barn door unlocked. Suddenly the download everything every time (or hope some is at least cached) environment of JavaScript / ECMAScript became the ONE place a user could 'for sure' 'install' (run someone else's unapproved) program. - Websites, _really_, should work just fine with zero scripts turned on. Possibly with the exception of a short list of trusted or user approved websites.
    - scarface_74 2y ago
      As opposed to native apps like the parent poster is proposing with no sandbox and that need to be created for each platform?
      - mjevans 2y ago
        As opposed to applications authorized by professionals in charge of equipment.
        scarface_74 2y ago
        ???
  - bobthepanda 2y ago
    Native development's story has been, for the longest time, the native way or the highway, which is precisely why it failed in favor of web where everyone begrudgingly supports a common feature set. No one wants to implement the same feature in five different native idioms.
    - ryandrake 2y ago
      And unfortunately, every system had their own way. Native development has suffered for decades from stubborn OS vendors who are incentivized against portability and cross-platform interoperability. Everyone's "way" was different and required you to rewrite your application to support it. I always wonder, if the web never took off as the common platform, would we today have better cross-platform native tools and APIs? I guess we'll never know.
      - scarface_74 2y ago
        There have been cross platform API and tools forever and they all suck and you end up not taking advantage of the platform and features. Java Swing, Electron, QT, React Native, etc. If you are going to create a “native” app that doesn’t take advantage of the platform features, you might as well just use the web. Besides, it’s always a leaky abstraction that forces you to have some type of escape hatch to take advantage of subtleties of the platform.
      - mike_hearn 2y ago
        Yes, but in fairness if operating systems don't differ then what's the point in having them. This is the "what killed [os] innovation" problem: if nobody is writing native apps then there's no incentive to add new capabilities to your OS. What's really needed here is a platform with the same advantages as the web, but which makes it much easier for OS vendors to expose proprietary capabilities. Then you will get innovation. Once browser makers killed off plugins it was over for desktop operating systems as outside of gaming (where innovation continues apace), there was no way to let devs write 90% cross platform code whilst still using the 10% special sauce.
  - mike_hearn 2y ago
    It can work. I have spent several years of my life making it work :) Obviously, on mobile you have app stores including enterprise app stores. On desktop you don't, or you do but they suck so people often don't want to use them. Making shipping desktop apps as easily as you can ship a web app is the goal of my company [1] and although it's always a work in progress it does get very close to that goal now. In particular: - Once set up you can deploy with a single command that builds, signs, integrates auto update engines, renders icons, uploads and everything else. It's not harder than uploading a new version of a web app. - Apps can do synchronous update checks on startup, web style, so once you push a new version everyone will get that version when they next start up the app. You can easily implement version checks whilst the app runs to remind users to restart after a while (big SPAs have the same issue if the server changes whilst user's tabs are still open). - Apps can update in the background too. - Delta updates make update times very low once the initial install is done. - On Windows, apps from different vendors can share files. So if two apps share a runtime and it's stable enough that files don't change totally from version to version, the user won't have to download them. Unfortunately on other platforms this nice trick doesn't work, and in a world where runtimes update every few weeks it's of less value. But still. All this works behind the firewall, also. [1] https://hydraulic.dev/ https://hydraulic.dev/
MaxBarraclough 2y ago
We have JavaFX and Qt, and they're both better than ever, but they don't see much use. With JavaFX you can build and distribute a portable .jar file, and I think it can be used with JNLP/Java Web Start for distribution if you prefer that approach. With Qt, you're likely to be delivering self-contained native application packages in the target platform's native form. (JavaFX has been carved out of the core JVM, which is annoying, but if the target machine has a JVM installed that bundles JavaFX, you're all set.)
- marmarama 2y ago
  I'm not sure you can say that Qt doesn't see much use, when there are hundreds, probably thousands, of well-known commercial apps using it, and it's in millions upon millions of embedded systems. And obviously KDE as well. It's just it's largely invisible. It works, it does exactly the job it's meant to do, and it does it well.
- pjmlp 2y ago
  Because most folks nowadays rather ship Chrome with their application, and then they complain Google has taken over the Web.
- FrankDelporte 2y ago
  Indeed JavaFX is better than ever ;-) See https://www.jfx-central.com/ https://www.jfx-central.com/ for many example applications, libraries, tutorials, etc.
sunrunner 2y ago
The web as it was originally conceived - readable (but not interactive) content with linked resources - feels a far cry from the web of today, a platform for interactive applications that seems to grow asymptotically towards feature-parity with native applications (UI, input handling, data processing, hardware access) while never quite getting there, encompassing the fundamental things that make 'applications' work. If the modern web _did_ reach feature parity in some way the real question would then be 'What makes it different?'. As linked resources doesn't seem like a particularly strong unique feature today the only other things I can think of are the simpler cross-platform experience and the ease of distribution. So then the questions are 'What would make for a better cross-platform development experience?' (Chromium embedded framework not included) and 'How do we make app distribution seamless?' Is it feasible or sensible to have users expect to access every application just by visiting a named page and getting the latest version blasted at their browser? And I guess that's how we got Chrome OS.
- bobthepanda 2y ago
  The web gained traction as a development platform because for the most part, it broadly works the same on every device due to the web standards, and so it's very easy to develop something that works consistently on all the different devices. Purists may bemoan that things no longer respect the "native look and feel" but that is a feature, not a bug, for the vast majority of users and developers. As an example, I absolutely hate that my work email on Outlook does not have the same feature set on Windows vs Mac vs whatever, and even in scenarios where application developers want to deliver the same features everywhere the minutiae of the native development patterns make it like herding cats. It is basically the electrical plug of our era, in that it is a means to an end, never mind if 110V 60Hz is necessarily the most efficient way to deliver power in the home in North America.
- 0xbadcafebee 2y ago
  > 'What would make for a better cross-platform development experience?' Back in the day, people balked at using Java as a universal portable application platform, because ironically, everyone wanted their own language and their own platform semantics. Yet everyone on the planet has already unanimously agreed to a cross-platform development platform with a strict set of languages: - HTML/CSS for presenting text/style/layouts - Javascript for crafting and organizing the UI - WebAssembly for compiled code run in a VM - HTTP for IPC So right there you have prescribed languages, formats, protocols. We gave up a single simple prescribed system for a more complicated one. However, if you wanted to, you could get rid of the browser, and still support those same things - plus everything else a native app can do. Separate those components into libraries, then link those libraries into your app, have your app load the libraries & components you want, and configure how the library should handle the presentation, UI, and business logic. You're then basically shipping a custom, streamlined browser - except it doesn't have to obey browser rules! It can run any code you want, because it's your app. It can present any way you want, because it's your app. But it's also portable! The UI, the business logic, presentation, would all be using libraries ported to multiple platforms. Just recompile your app on the target platform. Avoid native code for an instant recompile, or add native code and deal with the portability tax. It's sort of like compiling one browser on multiple platforms, except 1) it's broken down into components, 2) you can interchange those components with ones from different vendors that follow the same standards, and 3) you are not limited to these libraries - you can add your own native code. In terms of interoperability with other apps, use the same network protocols, the same URIs. You can add new ones too, if you prefer, just for your own custom backend for your app... but probably everyone will stick to HTTP, because it's a universal way to access everyone's backend APIs or other native apps across sandboxes.

scarface_74 2y ago

Native for Windows, Macs, Linux, iPhones and Android devices? Now imagine trying to update all of those native apps across a large enterprise or multiple large enterprises. Since I do use multiple devices, when everything is on the web, you also don’t have to worry about syncing or conflict resolution like you do with semi connected scenarios.

ryandrake 2y ago
> Native for Windows, Macs, Linux, iPhones and Android devices? > Now imagine trying to update all of those native apps across a large enterprise or multiple large enterprises. With the tools we have now, it would absolutely not work. In my post I was imagining a parallel alternate universe where native development tools got all the brainpower and innovation over the last 30 years, instead of the web tools getting it.
- mjevans 2y ago
  The web got it because for some _insane_ reason, websites were able to convince IT departments to allow scripts to run. That left the barn door unlocked. Suddenly the download everything every time (or hope some is at least cached) environment of JavaScript / ECMAScript became the ONE place a user could 'for sure' 'install' (run someone else's unapproved) program. - Websites, _really_, should work just fine with zero scripts turned on. Possibly with the exception of a short list of trusted or user approved websites.
  - scarface_74 2y ago
    As opposed to native apps like the parent poster is proposing with no sandbox and that need to be created for each platform?
    - mjevans 2y ago
      As opposed to applications authorized by professionals in charge of equipment.
      - scarface_74 2y ago
        ???
- bobthepanda 2y ago
  Native development's story has been, for the longest time, the native way or the highway, which is precisely why it failed in favor of web where everyone begrudgingly supports a common feature set. No one wants to implement the same feature in five different native idioms.
  - ryandrake 2y ago
    And unfortunately, every system had their own way. Native development has suffered for decades from stubborn OS vendors who are incentivized against portability and cross-platform interoperability. Everyone's "way" was different and required you to rewrite your application to support it. I always wonder, if the web never took off as the common platform, would we today have better cross-platform native tools and APIs? I guess we'll never know.
    - scarface_74 2y ago
      There have been cross platform API and tools forever and they all suck and you end up not taking advantage of the platform and features. Java Swing, Electron, QT, React Native, etc. If you are going to create a “native” app that doesn’t take advantage of the platform features, you might as well just use the web. Besides, it’s always a leaky abstraction that forces you to have some type of escape hatch to take advantage of subtleties of the platform.
    - mike_hearn 2y ago
      Yes, but in fairness if operating systems don't differ then what's the point in having them. This is the "what killed [os] innovation" problem: if nobody is writing native apps then there's no incentive to add new capabilities to your OS. What's really needed here is a platform with the same advantages as the web, but which makes it much easier for OS vendors to expose proprietary capabilities. Then you will get innovation. Once browser makers killed off plugins it was over for desktop operating systems as outside of gaming (where innovation continues apace), there was no way to let devs write 90% cross platform code whilst still using the 10% special sauce.
- mike_hearn 2y ago
  It can work. I have spent several years of my life making it work :) Obviously, on mobile you have app stores including enterprise app stores. On desktop you don't, or you do but they suck so people often don't want to use them. Making shipping desktop apps as easily as you can ship a web app is the goal of my company [1] and although it's always a work in progress it does get very close to that goal now. In particular: - Once set up you can deploy with a single command that builds, signs, integrates auto update engines, renders icons, uploads and everything else. It's not harder than uploading a new version of a web app. - Apps can do synchronous update checks on startup, web style, so once you push a new version everyone will get that version when they next start up the app. You can easily implement version checks whilst the app runs to remind users to restart after a while (big SPAs have the same issue if the server changes whilst user's tabs are still open). - Apps can update in the background too. - Delta updates make update times very low once the initial install is done. - On Windows, apps from different vendors can share files. So if two apps share a runtime and it's stable enough that files don't change totally from version to version, the user won't have to download them. Unfortunately on other platforms this nice trick doesn't work, and in a world where runtimes update every few weeks it's of less value. But still. All this works behind the firewall, also. [1] https://hydraulic.dev/ https://hydraulic.dev/

MaxBarraclough 2y ago

We have JavaFX and Qt, and they're both better than ever, but they don't see much use. With JavaFX you can build and distribute a portable .jar file, and I think it can be used with JNLP/Java Web Start for distribution if you prefer that approach. With Qt, you're likely to be delivering self-contained native application packages in the target platform's native form. (JavaFX has been carved out of the core JVM, which is annoying, but if the target machine has a JVM installed that bundles JavaFX, you're all set.)

marmarama 2y ago
I'm not sure you can say that Qt doesn't see much use, when there are hundreds, probably thousands, of well-known commercial apps using it, and it's in millions upon millions of embedded systems. And obviously KDE as well. It's just it's largely invisible. It works, it does exactly the job it's meant to do, and it does it well.
pjmlp 2y ago
Because most folks nowadays rather ship Chrome with their application, and then they complain Google has taken over the Web.
FrankDelporte 2y ago
Indeed JavaFX is better than ever ;-) See https://www.jfx-central.com/ https://www.jfx-central.com/ for many example applications, libraries, tutorials, etc.

sunrunner 2y ago

The web as it was originally conceived - readable (but not interactive) content with linked resources - feels a far cry from the web of today, a platform for interactive applications that seems to grow asymptotically towards feature-parity with native applications (UI, input handling, data processing, hardware access) while never quite getting there, encompassing the fundamental things that make 'applications' work. If the modern web _did_ reach feature parity in some way the real question would then be 'What makes it different?'. As linked resources doesn't seem like a particularly strong unique feature today the only other things I can think of are the simpler cross-platform experience and the ease of distribution. So then the questions are 'What would make for a better cross-platform development experience?' (Chromium embedded framework not included) and 'How do we make app distribution seamless?' Is it feasible or sensible to have users expect to access every application just by visiting a named page and getting the latest version blasted at their browser? And I guess that's how we got Chrome OS.

bobthepanda 2y ago
The web gained traction as a development platform because for the most part, it broadly works the same on every device due to the web standards, and so it's very easy to develop something that works consistently on all the different devices. Purists may bemoan that things no longer respect the "native look and feel" but that is a feature, not a bug, for the vast majority of users and developers. As an example, I absolutely hate that my work email on Outlook does not have the same feature set on Windows vs Mac vs whatever, and even in scenarios where application developers want to deliver the same features everywhere the minutiae of the native development patterns make it like herding cats. It is basically the electrical plug of our era, in that it is a means to an end, never mind if 110V 60Hz is necessarily the most efficient way to deliver power in the home in North America.
0xbadcafebee 2y ago
> 'What would make for a better cross-platform development experience?' Back in the day, people balked at using Java as a universal portable application platform, because ironically, everyone wanted their own language and their own platform semantics. Yet everyone on the planet has already unanimously agreed to a cross-platform development platform with a strict set of languages: - HTML/CSS for presenting text/style/layouts - Javascript for crafting and organizing the UI - WebAssembly for compiled code run in a VM - HTTP for IPC So right there you have prescribed languages, formats, protocols. We gave up a single simple prescribed system for a more complicated one. However, if you wanted to, you could get rid of the browser, and still support those same things - plus everything else a native app can do. Separate those components into libraries, then link those libraries into your app, have your app load the libraries & components you want, and configure how the library should handle the presentation, UI, and business logic. You're then basically shipping a custom, streamlined browser - except it doesn't have to obey browser rules! It can run any code you want, because it's your app. It can present any way you want, because it's your app. But it's also portable! The UI, the business logic, presentation, would all be using libraries ported to multiple platforms. Just recompile your app on the target platform. Avoid native code for an instant recompile, or add native code and deal with the portability tax. It's sort of like compiling one browser on multiple platforms, except 1) it's broken down into components, 2) you can interchange those components with ones from different vendors that follow the same standards, and 3) you are not limited to these libraries - you can add your own native code. In terms of interoperability with other apps, use the same network protocols, the same URIs. You can add new ones too, if you prefer, just for your own custom backend for your app... but probably everyone will stick to HTTP, because it's a universal way to access everyone's backend APIs or other native apps across sandboxes.