4 ms·

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 in

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.
- anthk 2y ago
  I wish an embedded TCL won over JS. Also, I loved mozplugger. Embedded applications inside the browser. For the younger HN users, mozplugger basically opened some videos/ audio / documents, by simply embedding some native window from an application inside the browser. That's it. For Windows users, imagine the Sumatra PDF subwindow inside a browser tab to open the PDF's. Or VLC for HD videos. Video playing with mplayer under Linux was really fast in late 00's/early 10's. Far better than today with Chrome embedding maybe ffmpeg like ass, not delivering the whole performance. Because even with WebkitGTK4, running MPV with some h264 based settings outperforms Luakit on <video> tags by a huge margin.
BrenBarn 2y ago
> 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?' The question for me isn't what would make for a better developer experience, it's what would make for a better user experience. And, personally, as a user, what makes my experience better is when I get to decide how an app looks and works, and the developer's say in that is more limited. That is the big flaw with web apps: too many app authors want to be artists and want to create custom interfaces and lots of shiny gizmos. I want apps to generally be using standardized widgets like menus and buttons whose look and feel is determined by the user's platform preferences and are not a bespoke creation of the app author.
- somenameforme 2y ago
  I couldn't agree more, though it's kind of unfortunate that OS's are also going in the same direction. As meaningful innovation has, more or less, ended in the OS world - instead it's OS with shiny things I don't want, making controls look different just for the sake of looking different - sorry "new", packed with ad-tech I don't want, and soon undoubtedly to be packed with "AI" tech which I don't want. And all of this forced upon you thanks to imposed obsolescence with things like hardware [in]compatibility with older OSs. The entire tech world is really screwed up with how adversarial companies have become with their "customers."
  - BrenBarn 2y ago
    Yeah, when I found out what "client side decorations" are a little bit of me died inside. :-)

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.

anthk 2y ago
I wish an embedded TCL won over JS. Also, I loved mozplugger. Embedded applications inside the browser. For the younger HN users, mozplugger basically opened some videos/ audio / documents, by simply embedding some native window from an application inside the browser. That's it. For Windows users, imagine the Sumatra PDF subwindow inside a browser tab to open the PDF's. Or VLC for HD videos. Video playing with mplayer under Linux was really fast in late 00's/early 10's. Far better than today with Chrome embedding maybe ffmpeg like ass, not delivering the whole performance. Because even with WebkitGTK4, running MPV with some h264 based settings outperforms Luakit on <video> tags by a huge margin.

BrenBarn 2y ago

> 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?' The question for me isn't what would make for a better developer experience, it's what would make for a better user experience. And, personally, as a user, what makes my experience better is when I get to decide how an app looks and works, and the developer's say in that is more limited. That is the big flaw with web apps: too many app authors want to be artists and want to create custom interfaces and lots of shiny gizmos. I want apps to generally be using standardized widgets like menus and buttons whose look and feel is determined by the user's platform preferences and are not a bespoke creation of the app author.

somenameforme 2y ago
I couldn't agree more, though it's kind of unfortunate that OS's are also going in the same direction. As meaningful innovation has, more or less, ended in the OS world - instead it's OS with shiny things I don't want, making controls look different just for the sake of looking different - sorry "new", packed with ad-tech I don't want, and soon undoubtedly to be packed with "AI" tech which I don't want. And all of this forced upon you thanks to imposed obsolescence with things like hardware [in]compatibility with older OSs. The entire tech world is really screwed up with how adversarial companies have become with their "customers."
- BrenBarn 2y ago
  Yeah, when I found out what "client side decorations" are a little bit of me died inside. :-)