3 ms·

The real question is why though. Why should we use the HTTP/HTML/JS/CSS universe to deliver interactive applications to users. I only see downsides here. Not to

The real question is why though. Why should we use the HTTP/HTML/JS/CSS universe to deliver interactive applications to users. I only see downsides here. Not to mention that we pull these things into native applications like it was great to begin with. WASM might be able to address some of the shortcomings of this stack, not sure.

jiofih 7y ago
Because it is an extremely effective model for building UIs. As I mentioned above even this project uses a similar architecture, only backed by Clojure. Any UI toolkit will have similarities with the web stack. The real issue is the size of these monster engines, but a lightweight engine that only supports the subset needed for apps is possible - see Sciter, and I have high hopes for https://ultralig.ht/ https://ultralig.ht/
- StreamBright 7y ago
  >>Because it is an extremely effective model for building UIs. Is it? Have you ever tried? I think it is extremely hard to build reponsive UIs that work on every platform and there are no UX problems. We have to deal with a giant amount of boilerplate in many cases because using vanilla things (JS especially) won't cut it anymore. I am not even sure how many frameworks are targeting this space and try to solve the typical issues with these technologies and fail miserably. I think some of these issues are finally started to be handled the right way (Elm or ReasonML) but there are still some painpoints left (CSS). The question still, is it worth it? Couldn't we do better? The performance implications (energy consumption) for an average website is just hilarious. We should have a day where everybody disables JS and measure how much percentage of our computing capacity is going to render websites because we do not want to move away from HTML which was not (by any strectch of imagination) designed for this to start with. If anything, this should be a concern to most of us.
  - jiofih 7y ago
    > Have you ever tried? I’ve been doing it for 15 years. > I think it is extremely hard to build reponsive UIs that work on every platform and there are no UX problems It is hard on native platforms as well. Developing for mobile is not that far off from web today, everything converging towards flexbox or constraint solving, reducers etc. I think you’re conflating the problem of a bloated JS stack with the platform itself. We were building perfectly fine interactive UI without any of this crap ten years ago, and can still do it.
    - StreamBright 7y ago
      HTTP and HTML were not designed to do this. It was specifically static and stateless. We are retrofitting statefulness and dynamic content to this platform. Imagine if we designed a stateful and dynamic platform from the ground up that could be implemented with minimal effort to every platform and started to use the right abstractions with the right set of tools.
tannhaeuser 7y ago
WASM doesn't help at all here as it wants to be a new instruction set architecture (without even DOM access and GC) when what's needed is a portable and compact UI API.
- jiofih 7y ago
  “Processing large amounts of data” is one of the reasons in the page

jiofih 7y ago

Because it is an extremely effective model for building UIs. As I mentioned above even this project uses a similar architecture, only backed by Clojure. Any UI toolkit will have similarities with the web stack. The real issue is the size of these monster engines, but a lightweight engine that only supports the subset needed for apps is possible - see Sciter, and I have high hopes for https://ultralig.ht/ https://ultralig.ht/

StreamBright 7y ago
>>Because it is an extremely effective model for building UIs. Is it? Have you ever tried? I think it is extremely hard to build reponsive UIs that work on every platform and there are no UX problems. We have to deal with a giant amount of boilerplate in many cases because using vanilla things (JS especially) won't cut it anymore. I am not even sure how many frameworks are targeting this space and try to solve the typical issues with these technologies and fail miserably. I think some of these issues are finally started to be handled the right way (Elm or ReasonML) but there are still some painpoints left (CSS). The question still, is it worth it? Couldn't we do better? The performance implications (energy consumption) for an average website is just hilarious. We should have a day where everybody disables JS and measure how much percentage of our computing capacity is going to render websites because we do not want to move away from HTML which was not (by any strectch of imagination) designed for this to start with. If anything, this should be a concern to most of us.
- jiofih 7y ago
  > Have you ever tried? I’ve been doing it for 15 years. > I think it is extremely hard to build reponsive UIs that work on every platform and there are no UX problems It is hard on native platforms as well. Developing for mobile is not that far off from web today, everything converging towards flexbox or constraint solving, reducers etc. I think you’re conflating the problem of a bloated JS stack with the platform itself. We were building perfectly fine interactive UI without any of this crap ten years ago, and can still do it.
  - StreamBright 7y ago
    HTTP and HTML were not designed to do this. It was specifically static and stateless. We are retrofitting statefulness and dynamic content to this platform. Imagine if we designed a stateful and dynamic platform from the ground up that could be implemented with minimal effort to every platform and started to use the right abstractions with the right set of tools.

tannhaeuser 7y ago

WASM doesn't help at all here as it wants to be a new instruction set architecture (without even DOM access and GC) when what's needed is a portable and compact UI API.

jiofih 7y ago
“Processing large amounts of data” is one of the reasons in the page