5 ms·

Agreed. Browsers are now nothing but an application platform of APIs (https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/

Agreed. Browsers are now nothing but an application platform of APIs (https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API). For some reason they still retain the vestigial HTML, CSS and JS, but really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API. Then we can finally ship apps to users without the shackles of how a browser wants to interpret and render some markup. The idea of security "sandboxes" is quaint, but have been defeated pretty much since their inception. And the only reason we have "frontend developers" rather than just "developers" is HTML/CSS/JS/DOM/etc is a byzantine relic we refuse to let go of. Just let us deliver regular-old apps to users and control how they're displayed in regular programming languages. Let users can find any app in any online marketplace based on open standards.

sidewndr46 3y ago
If someone created a way for WASM to talk to an SDL equivalent, it'd probably end use of HTML & CSS
- yvdriess 3y ago
  And so closing the great circle of UI framework technologies.
- throwaway12245 3y ago
  WASM has support for SDL for a long time: https://www.jamesfmackenzie.com/2019/12/01/webassembly-graphics-with-sdl/ https://www.jamesfmackenzie.com/2019/12/01/webassembly-graph...
- tomsmeding 3y ago
  If so, all people relying on (often limited even with html that contains text) accessibility features will have to sit in a corner and cry.
  - wg0 3y ago
    I think that should be addressable.
    - Terr_ 3y ago
      Why do I get the feeling some company will address the issue by offering them a comfy chair and a free box of tissues?
- t0astbread 3y ago
  If tri-state logic becomes viable it's game over for binary!
- wg0 3y ago
  IF GTK/Qt etc can render to canvas using WebGPU while compiled to assembly, I think game is almost over than too IF there's a way to lazy load application modules. Think Autodesk products. Certain parts (wasm modules) only load when you hover over a menu while overall app loads within milliseconds because it just has the main window and such.
  - slondr 3y ago
    This has been possible for years. I actually got in the habit of porting my qt projects to the web target because they ran better than native compiled on some of my older machines.
- eternityforest 3y ago
  That sounds awful. People would be jamming entire 10MB toolkits into WASM to do things that HTML could do, and performance would probably suffer. HTML is declarative. The machine understands it. I like things machines can understand and optimize. Things that you can write automated tools to work with because it's not a full turing machine. If you want to make a screen reader, you can. If you want to reflow for mobile in a better way, you can, because you know what's text and what's an image. Just giving people a programming environment and the ability to draw some pixels, the browser has no idea what the intent is. There's nothing to optimize unless the individual sites do, and I doubt they have Google and Mozilla's budget. We already have too many unnecessary powerful imperative systems out there.
xigency 3y ago
I do think there’s never been a better time to reinvent the web, including basic technologies like HTML and JavaScript. For example, picking up more elements of semantic web and distributed systems and leveraging interconnected devices.
istjohn 3y ago
The web started as a graph of hyperlinked documents, and that use case hasn't gone away. SPA's aren't the internet.
eternityforest 3y ago
HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform. I'd rather we go the other way, and build the browser into the OS, so that desktop apps just serve a perfectly standard web server, with an API to launch a special OS client with slightly more native integration(Toolbar icons, closing the process when the browser closes, etc), to make native app dev easier and hopefully more popular. Security sandboxes mostly work. People aren't constantly getting viruses from clicking the wrong link, at least not quite as much. They're not perfect, but they're better than having to completely trust 100 different sites unsandboxed, and they can be improved. I'd rather have crappy security than no security at all.
- throwaway892238 3y ago
  If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads in 2022, generating billions in revenue. That's not a mistake or accident; that's a market filling a need. If we really want an application platform that works everywhere, then let's stop dicking around with these stupid document hypertext viewers and build a real app platform that works everywhere.
  - r3trohack3r 3y ago
    > Native mobile apps thrive despite this magical web browser working everywhere There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients. Many folks are surprised to see just how far you can push a browser app and how small the gap between web and browser has become for well built applications, including native-like things like Bluetooth, NFC, USB, etc. (see: https://youmightnotneedelectron.com/ https://youmightnotneedelectron.com/) Have hacked with quite a few devs/companies that had a fully functioning offline capable web native application. The most requested feature they’d get? “I want to download it from the App Store.” (Usually in the form of “I can’t find your app in the App Store”) I suspect this is why the PWA experience on mobile devices hasn’t been well paved and why some App Store policies call out “don’t just wrap a browser view in a native app” - they want to keep users coming in the front door of a marketplace where they collect a cut off the top of all transactions.
macinjosh 3y ago
> really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API Browsers have a 2D renderer (canvas) and you can write your GUI code in C++, Rust, or whatever and compile it to WASM. Some widget toolkits for this even exist already. If this were a superior model it would have taken over by now? I guess you are after deeper integration with the desktop environment?
- ogoffart 3y ago
  The challenge with toolkits confined to <canvas> rendering is their inability to effectively utilize the browser's integration with the OS. Key components like font rendering, input methods (including standard key shortcuts and behavior within input fields), selection handling, image decoding, network stack, native-like scrolling, and accessibility features need to be recreated from scratch. A web toolkit must use the DOM for optimal performance. (and therefore lower to HTML)
polynomial 3y ago
Presume you did not mean bytecode that calls ABI, but rather API? (ABI is a Web3 thing.)
- efreak 3y ago
  > In computer software, an application binary interface ( ABI) is an interface between two binary program modules. Often, one of these modules is a library or operating system facility, and the other is a program that is being run by a user. https://en.wikipedia.org/wiki/Application_binary_interface https://en.wikipedia.org/wiki/Application_binary_interface
wryanzimmerman 3y ago
But “regular old apps” don’t do all the same things. The whole point of properly developing web apps is that html/css indicates a certain level of semantic understanding which allows for different interpretation in different contexts. If you build a web app well, you build it to be a good experience on a computer for a power user with a huge screen and a keyboard for shortcuts, good for a user on a tiny touch screen, good for a blind person who doesn’t use a screen, and good for robots to parse and index. It should even be good for someone on an iPad with a mouse or a pencil which interprets the whole concept of the mouse differently from the desktop user’s mouse. The agreed-upon semantics of HTML and the separation of visual styling into CSS is what allows you to take a step beyond just building an app and add a layer of “say what you mean” such that human and non-human users can re-interpret it into their own devices, use cases, and specific needs. Web frontends are at their best when you don’t expect to perfectly control the end user experience, but try to convey the semantic meaning as perfectly as you can so it can be interpreted into good experiences even in situations where the display is wildly different than originally intended.

sidewndr46 3y ago

If someone created a way for WASM to talk to an SDL equivalent, it'd probably end use of HTML & CSS

yvdriess 3y ago
And so closing the great circle of UI framework technologies.
throwaway12245 3y ago
WASM has support for SDL for a long time: https://www.jamesfmackenzie.com/2019/12/01/webassembly-graphics-with-sdl/ https://www.jamesfmackenzie.com/2019/12/01/webassembly-graph...
tomsmeding 3y ago
If so, all people relying on (often limited even with html that contains text) accessibility features will have to sit in a corner and cry.
- wg0 3y ago
  I think that should be addressable.
  - Terr_ 3y ago
    Why do I get the feeling some company will address the issue by offering them a comfy chair and a free box of tissues?
t0astbread 3y ago
If tri-state logic becomes viable it's game over for binary!
wg0 3y ago
IF GTK/Qt etc can render to canvas using WebGPU while compiled to assembly, I think game is almost over than too IF there's a way to lazy load application modules. Think Autodesk products. Certain parts (wasm modules) only load when you hover over a menu while overall app loads within milliseconds because it just has the main window and such.
- slondr 3y ago
  This has been possible for years. I actually got in the habit of porting my qt projects to the web target because they ran better than native compiled on some of my older machines.
eternityforest 3y ago
That sounds awful. People would be jamming entire 10MB toolkits into WASM to do things that HTML could do, and performance would probably suffer. HTML is declarative. The machine understands it. I like things machines can understand and optimize. Things that you can write automated tools to work with because it's not a full turing machine. If you want to make a screen reader, you can. If you want to reflow for mobile in a better way, you can, because you know what's text and what's an image. Just giving people a programming environment and the ability to draw some pixels, the browser has no idea what the intent is. There's nothing to optimize unless the individual sites do, and I doubt they have Google and Mozilla's budget. We already have too many unnecessary powerful imperative systems out there.

xigency 3y ago

I do think there’s never been a better time to reinvent the web, including basic technologies like HTML and JavaScript. For example, picking up more elements of semantic web and distributed systems and leveraging interconnected devices.

istjohn 3y ago

The web started as a graph of hyperlinked documents, and that use case hasn't gone away. SPA's aren't the internet.

eternityforest 3y ago

HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform. I'd rather we go the other way, and build the browser into the OS, so that desktop apps just serve a perfectly standard web server, with an API to launch a special OS client with slightly more native integration(Toolbar icons, closing the process when the browser closes, etc), to make native app dev easier and hopefully more popular. Security sandboxes mostly work. People aren't constantly getting viruses from clicking the wrong link, at least not quite as much. They're not perfect, but they're better than having to completely trust 100 different sites unsandboxed, and they can be improved. I'd rather have crappy security than no security at all.

throwaway892238 3y ago
If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads in 2022, generating billions in revenue. That's not a mistake or accident; that's a market filling a need. If we really want an application platform that works everywhere, then let's stop dicking around with these stupid document hypertext viewers and build a real app platform that works everywhere.
- r3trohack3r 3y ago
  > Native mobile apps thrive despite this magical web browser working everywhere There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients. Many folks are surprised to see just how far you can push a browser app and how small the gap between web and browser has become for well built applications, including native-like things like Bluetooth, NFC, USB, etc. (see: https://youmightnotneedelectron.com/ https://youmightnotneedelectron.com/) Have hacked with quite a few devs/companies that had a fully functioning offline capable web native application. The most requested feature they’d get? “I want to download it from the App Store.” (Usually in the form of “I can’t find your app in the App Store”) I suspect this is why the PWA experience on mobile devices hasn’t been well paved and why some App Store policies call out “don’t just wrap a browser view in a native app” - they want to keep users coming in the front door of a marketplace where they collect a cut off the top of all transactions.

macinjosh 3y ago

> really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API Browsers have a 2D renderer (canvas) and you can write your GUI code in C++, Rust, or whatever and compile it to WASM. Some widget toolkits for this even exist already. If this were a superior model it would have taken over by now? I guess you are after deeper integration with the desktop environment?

ogoffart 3y ago
The challenge with toolkits confined to <canvas> rendering is their inability to effectively utilize the browser's integration with the OS. Key components like font rendering, input methods (including standard key shortcuts and behavior within input fields), selection handling, image decoding, network stack, native-like scrolling, and accessibility features need to be recreated from scratch. A web toolkit must use the DOM for optimal performance. (and therefore lower to HTML)

polynomial 3y ago

Presume you did not mean bytecode that calls ABI, but rather API? (ABI is a Web3 thing.)

efreak 3y ago
> In computer software, an application binary interface ( ABI) is an interface between two binary program modules. Often, one of these modules is a library or operating system facility, and the other is a program that is being run by a user. https://en.wikipedia.org/wiki/Application_binary_interface https://en.wikipedia.org/wiki/Application_binary_interface

wryanzimmerman 3y ago

But “regular old apps” don’t do all the same things. The whole point of properly developing web apps is that html/css indicates a certain level of semantic understanding which allows for different interpretation in different contexts. If you build a web app well, you build it to be a good experience on a computer for a power user with a huge screen and a keyboard for shortcuts, good for a user on a tiny touch screen, good for a blind person who doesn’t use a screen, and good for robots to parse and index. It should even be good for someone on an iPad with a mouse or a pencil which interprets the whole concept of the mouse differently from the desktop user’s mouse. The agreed-upon semantics of HTML and the separation of visual styling into CSS is what allows you to take a step beyond just building an app and add a layer of “say what you mean” such that human and non-human users can re-interpret it into their own devices, use cases, and specific needs. Web frontends are at their best when you don’t expect to perfectly control the end user experience, but try to convey the semantic meaning as perfectly as you can so it can be interpreted into good experiences even in situations where the display is wildly different than originally intended.