3 ms·

> browser-based technology struggles to utilize multiple cores in the same VM instance > javascript VMs choke on processing large amounts of data, which leaves

by jiofih 7y ago

> browser-based technology struggles to utilize multiple cores in the same VM instance > javascript VMs choke on processing large amounts of data, which leaves them a better fit for advanced interactive forms than compilers or data processing pipelines 2005 called and wants it’s quotes back. It is trivial to spawn worker processes today and VM performance is only 2-5x behind compiled ones, often closer. Not to mention WASM. The elephant in the room is not JavaScript or it’s VM but the browser engine. EDIT: seems like JavaFX has its own browser-like “scene graph” and embeds WebKit, so this will suffer from the same bloat in memory use and app sizes?

StreamBright 7y ago
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
brabel 7y ago
> seems like JavaFX has its own browser-like “scene graph” and embeds WebKit... Since Java 9 modules were introduced, the webview (and webkit) are only included in the app if the `javafx.web` module is used. Otherwise, it will not be included in your distribution if you pack it with jpackage.

by jiofih 7y ago

StreamBright 7y ago

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

brabel 7y ago

> seems like JavaFX has its own browser-like “scene graph” and embeds WebKit... Since Java 9 modules were introduced, the webview (and webkit) are only included in the app if the `javafx.web` module is used. Otherwise, it will not be included in your distribution if you pack it with jpackage.