5 ms·

Personally I don't see any of that happening - client-side app development on the web is a chaotic mess with no "official" (whatever that means) way of doing th

Personally I don't see any of that happening - client-side app development on the web is a chaotic mess with no "official" (whatever that means) way of doing things. Throw into that mix the constant reinvention thats going on (yeah can't wait to see everything get re-invented AGAIN when web-assembly comes along), for what constitute incredibly marginal gains in the UI space (the web UI was already way fast enough 5 years ago without introducing mind-bending paradigms like react). On top of all that, the very concept of web apps (in my opinion) is fundamentally flawed in that they break the web (fundamentally flawed in a similar way that Flash as a interactive platform was flawed e.g user interaction along a timeline is an inherent conflict). So personally I expect all the client-side web app stuff to collapse under its own weight at some point. As a example, I've been a web developer for 20 years, and for my own projects at home I don't even bother with web front ends; I use QML and QT and bang out a great UI in a fraction of the time it takes to produce a web UI. It's not worth the hassle anymore, but then I have the luxury of my own projects not having many (any?) users beside myself. As for back-end, I've actually seen a shift more towards "systems" e.g a set of isolated sub-systems interacting via event busses or queues over HTTP/JSON either as micro-services or something close to that. Then a separate "web front-end" app pull data for output/display, almost as a client to that system. So a cleaner separation of The Real System from Web Application Back-end. And in this space, things seem to becoming much more standardised means of communication between parts, whilst at the same time there is a Cambrian explosion of new tools, languages etc which can be exploited. There is very much an idea that separate sub-systems can be written in languages which can best take advantage of for the problem space. It's very interesting to see the differences in the way the front-end and back-end communities are approaching progress/innovation. Anyway, thats my opinion/view of it all. Sorry for the wall of text

rimantas 10y ago
Agreed. As I once put it web stack for the apps is like trying to invent, version after version, a kind of fork which is most suitable to eat soup. Folks, the spoon exists for the reason.
lj3 10y ago
What do you think about a browser plugin that runs arbitrary .exe code via a plugin? It would have to be sandboxed, of course, but it would give you all of the benefits of a browser distribution model without having to deal with the DOM.
- jalfresi 10y ago
  Why not just make QML a media type and a spec that browsers can to implement? Then we can do away with all this HMTL-Page-Is-An-App nonsense
  - lj3 10y ago
    Why limit ourselves to a single UI format? Forget the part I said about a plugin. What if browsers were able to load and execute LLVM bitcode natively in a sandbox? You could get native performance in the browser using any language you'd like.
    - yencabulator 10y ago
      Please get non-Chrome browsers on board: https://developer.chrome.com/native-client https://developer.chrome.com/native-client
      - lj3 10y ago
        Please tell Google to publish a spec for the pepper api and to rewrite it so it doesn't require the blink rendering engine. As much as I dislike Mozilla, I give them props for trying to reverse engineer the pepper api from what was implemented in the chrome browser. But, expecting them to change their rendering engine to support an unpublished spec is ridiculous.

rimantas 10y ago

Agreed. As I once put it web stack for the apps is like trying to invent, version after version, a kind of fork which is most suitable to eat soup. Folks, the spoon exists for the reason.

lj3 10y ago

What do you think about a browser plugin that runs arbitrary .exe code via a plugin? It would have to be sandboxed, of course, but it would give you all of the benefits of a browser distribution model without having to deal with the DOM.

jalfresi 10y ago
Why not just make QML a media type and a spec that browsers can to implement? Then we can do away with all this HMTL-Page-Is-An-App nonsense
- lj3 10y ago
  Why limit ourselves to a single UI format? Forget the part I said about a plugin. What if browsers were able to load and execute LLVM bitcode natively in a sandbox? You could get native performance in the browser using any language you'd like.
  - yencabulator 10y ago
    Please get non-Chrome browsers on board: https://developer.chrome.com/native-client https://developer.chrome.com/native-client
    - lj3 10y ago
      Please tell Google to publish a spec for the pepper api and to rewrite it so it doesn't require the blink rendering engine. As much as I dislike Mozilla, I give them props for trying to reverse engineer the pepper api from what was implemented in the chrome browser. But, expecting them to change their rendering engine to support an unpublished spec is ridiculous.