4 ms·

To expand on your point, somewhere along the line, the web went from a content delivery mechanism to a full GUI + content delivery mehanism. The allure and adv

To expand on your point, somewhere along the line, the web went from a content delivery mechanism to a full GUI + content delivery mehanism. The allure and advantages to developing a full GUI on the web are many, including portability and availability. But the downside is that you are suddenly developing to the lowest common denominator - the browser - which not only has to support the "old" web but complicated GUIs (something it was never designed for), which in turn means all sorts of "magic", as you put it, to make it work (i.e. crazy DOM manipulations). And because browsers were never designed for this, there is no One True Way to develop a simple user action. Search for "drag and drop in javascript" for example. So what happens is, everyone invents their own way of doing stuff, which turned into a race of who is more popular/clever, resulting in a gajillion ways to do the same thing.

tracker1 8y ago
There are drag/drop APIs defined... but people make abstractions... This happens even in desktop UI development. There are LOTS of front-end libraries.. but it takes a lot of effort to make them, so there are still far fewer. The web is easily flexible, and configurable in terms of how you deliver your UX... you aren't hamstrung into creating something that looks like it was made in 1996.
- mirkules 8y ago
  Delivery and flexibility are the greatest pros. But while the delivery mechanism is great, the UI has to be delivered and interpreted every time, through an unknown engine that theoretically follows a spec. This results in a) slower execution times and b) inconsistencies in how the UI is interpreted. Javascript browser applications are simply slower and less stable for than their native counterparts for those reasons. All that on top of a language which is on par with PHP as far as consistency, and often times worse. With regards to your 1996 comment, again I beg to differ. Try writing Photoshop or GarageBand as a web app. I shudder to think what that would look like, and the cost each would incur. There is a reason that "mobile web apps" have lost the battle to native, essentially - the friction to deliver an app is much smaller (app stores), every platform is more-less consistent and the apps are smoother and faster instead of choppy and half-baked for web apps. I would much rather, for example, use a Home Depot app than their website. Or Coinbase vs. GDAX (even though GDAX is more feature-rich). I can't even think of a webapp that I'd rather use (on a regular basis) if an app is available instead. But maybe I'm just a graybeard who can't accept change. Or maybe I'm simply old enough to remember what 1996 was like for UI, and that the web today feels like those times, just with prettier icons. Likely a combination of both.
  - tracker1 8y ago
    I take umbrage with your PHP reference... JavaScript the language is pretty damned consistent, and nice. The browser APIs, that's a different story. As to PhotoShop or GarageBand, I think there's some more flushing out to do as far as APIs, and frankly that kind of stuff might be workable with WebAssembly. It would take a lot of effort to convert everything, also, not sure if you can use WASM in WebWorkers, but that may be more ideal. As to the cost, are you meaning overhead, or programming cost? I'd guess a not insignificant number of "native" apps for mobile are at least partly framed web apps. Also, I would probably just reach for React Native and re-use as much as possible, which would still leverage JS for most of it. In the end it depends... you get a LOT from web applications today. I see it as a bigger boost for internal/corporate/enterprise applications. Because you don't have to manage wide infrastructure and updates in nearly the same ways, you can simply do server deploys and be done. Also the 1996 apps reference was in that most UI toolkits default to looks that haven't changed much since 1990's and aren't skinnable in the least. I remember the late 90's and early 2000's, litestep and winamp were two of my favorite things. I know that was user customizations of apps, over developer/designer. All the same, maybe I want my site/app to look like Material Design over Bootstrap, or something else.

tracker1 8y ago

There are drag/drop APIs defined... but people make abstractions... This happens even in desktop UI development. There are LOTS of front-end libraries.. but it takes a lot of effort to make them, so there are still far fewer. The web is easily flexible, and configurable in terms of how you deliver your UX... you aren't hamstrung into creating something that looks like it was made in 1996.

mirkules 8y ago
Delivery and flexibility are the greatest pros. But while the delivery mechanism is great, the UI has to be delivered and interpreted every time, through an unknown engine that theoretically follows a spec. This results in a) slower execution times and b) inconsistencies in how the UI is interpreted. Javascript browser applications are simply slower and less stable for than their native counterparts for those reasons. All that on top of a language which is on par with PHP as far as consistency, and often times worse. With regards to your 1996 comment, again I beg to differ. Try writing Photoshop or GarageBand as a web app. I shudder to think what that would look like, and the cost each would incur. There is a reason that "mobile web apps" have lost the battle to native, essentially - the friction to deliver an app is much smaller (app stores), every platform is more-less consistent and the apps are smoother and faster instead of choppy and half-baked for web apps. I would much rather, for example, use a Home Depot app than their website. Or Coinbase vs. GDAX (even though GDAX is more feature-rich). I can't even think of a webapp that I'd rather use (on a regular basis) if an app is available instead. But maybe I'm just a graybeard who can't accept change. Or maybe I'm simply old enough to remember what 1996 was like for UI, and that the web today feels like those times, just with prettier icons. Likely a combination of both.
- tracker1 8y ago
  I take umbrage with your PHP reference... JavaScript the language is pretty damned consistent, and nice. The browser APIs, that's a different story. As to PhotoShop or GarageBand, I think there's some more flushing out to do as far as APIs, and frankly that kind of stuff might be workable with WebAssembly. It would take a lot of effort to convert everything, also, not sure if you can use WASM in WebWorkers, but that may be more ideal. As to the cost, are you meaning overhead, or programming cost? I'd guess a not insignificant number of "native" apps for mobile are at least partly framed web apps. Also, I would probably just reach for React Native and re-use as much as possible, which would still leverage JS for most of it. In the end it depends... you get a LOT from web applications today. I see it as a bigger boost for internal/corporate/enterprise applications. Because you don't have to manage wide infrastructure and updates in nearly the same ways, you can simply do server deploys and be done. Also the 1996 apps reference was in that most UI toolkits default to looks that haven't changed much since 1990's and aren't skinnable in the least. I remember the late 90's and early 2000's, litestep and winamp were two of my favorite things. I know that was user customizations of apps, over developer/designer. All the same, maybe I want my site/app to look like Material Design over Bootstrap, or something else.