4 ms·

>I strongly suspect the generation after this will rediscover the power of desktop apps and some of the dev tools that were around at that time. The biggest th

by hueving 10y ago

>I strongly suspect the generation after this will rediscover the power of desktop apps and some of the dev tools that were around at that time. The biggest thing desktop apps are missing was the delivery mechanism. With web apps: * a new user is just a hyperlink away * pushing app updates is a page reload * server-side state eliminates all of the migration headaches for client-based state People are fickle and they will decide not to use a service if it takes a couple of seconds to load. When you require them to download an app and install it, you've already eliminated two major categories of users: impatient users, and users who don't know how to (or aren't allowed to) install applications.

baq 10y ago
webassembly + full page canvas. games already work like that. hopefully sanity is just around the corner.
- lj3 10y ago
  Wouldn't Canvas need more advanced text handling for that to be practical? I know that's a big reason canvas based frameworks never took off.
  - TimJYoung 10y ago
    The problem with using the canvas functionality for everything is that it's an all-or-nothing proposition, and you end up having to write a lot of stuff that is already handled by the browser, or can only be handled by the browser (think bi-directional text/NLS issues).
    - lj3 10y ago
      I don't think that's a problem, personally. Something like canvas should be an all-or-nothing proposition. There's very little overlap between what you need for content-based static web pages and applications that just happen to run on the web. The problem is canvas wasn't designed to be that all-or-nothing alternative to the DOM. It was designed as an alternative to the flash player for html5 games. As a result, it lacks several features that are needed to display generic content, the most prominent of these features being proper (and easy!) font rendering. I suppose you could build your own advanced font rendering engine (I think Flipboard did exactly that), but that's more work and risk than most companies or even individuals are prepared to take these days. And you are right; creating your own would cause you to re-create a lot of stuff that's already handled by the browser, like font highlighting, copy/paste, etc.
- btschaegg 10y ago
  I personally suspect that actually, Henry Spencer's famous prediction is more likely what's looming around the corner. You just wait - there will be a terminal emulator written with webassembly+Canvas eventually. Perhaps powered by the already existing Emscripten port of Linux.
  - bbcbasic 10y ago
    Could you run a browser in that thing?
chadcmulligan 10y ago
yes this was always the reason given for not using Delphi instead of making a web app in every enterprise I worked at. Every time I said "hey how about we do this in Delphi, we'll have it finished in a couple of weeks" the argument was "but we'll have to put it through the windows guys and get a package made and distribute it to the users", so we made a web app. a couple of hundred grand later we had a web app, it wasn't as good as what the Delphi one would have been, it was slower, less features, but hey our 20 users didn't need to download it. lmao, I was paid by the hour.

by hueving 10y ago

baq 10y ago

webassembly + full page canvas. games already work like that. hopefully sanity is just around the corner.

lj3 10y ago
Wouldn't Canvas need more advanced text handling for that to be practical? I know that's a big reason canvas based frameworks never took off.
- TimJYoung 10y ago
  The problem with using the canvas functionality for everything is that it's an all-or-nothing proposition, and you end up having to write a lot of stuff that is already handled by the browser, or can only be handled by the browser (think bi-directional text/NLS issues).
  - lj3 10y ago
    I don't think that's a problem, personally. Something like canvas should be an all-or-nothing proposition. There's very little overlap between what you need for content-based static web pages and applications that just happen to run on the web. The problem is canvas wasn't designed to be that all-or-nothing alternative to the DOM. It was designed as an alternative to the flash player for html5 games. As a result, it lacks several features that are needed to display generic content, the most prominent of these features being proper (and easy!) font rendering. I suppose you could build your own advanced font rendering engine (I think Flipboard did exactly that), but that's more work and risk than most companies or even individuals are prepared to take these days. And you are right; creating your own would cause you to re-create a lot of stuff that's already handled by the browser, like font highlighting, copy/paste, etc.
btschaegg 10y ago
I personally suspect that actually, Henry Spencer's famous prediction is more likely what's looming around the corner. You just wait - there will be a terminal emulator written with webassembly+Canvas eventually. Perhaps powered by the already existing Emscripten port of Linux.
- bbcbasic 10y ago
  Could you run a browser in that thing?

chadcmulligan 10y ago

yes this was always the reason given for not using Delphi instead of making a web app in every enterprise I worked at. Every time I said "hey how about we do this in Delphi, we'll have it finished in a couple of weeks" the argument was "but we'll have to put it through the windows guys and get a package made and distribute it to the users", so we made a web app. a couple of hundred grand later we had a web app, it wasn't as good as what the Delphi one would have been, it was slower, less features, but hey our 20 users didn't need to download it. lmao, I was paid by the hour.