5 ms·

> Now that conventions are moving towards ‘single-page’ web apps, the concept of a ‘page’ is losing its special meaning. The web is so broken. The whole "web a

> Now that conventions are moving towards ‘single-page’ web apps, the concept of a ‘page’ is losing its special meaning. The web is so broken. The whole "web app" concept is just a giant hack. The job of us web developers today consists in employing a never ending pile of hacks (e.g. AJAX, long-pooling, semi-broken languages and implementations, non-standard vendor APIs) to fight a browser into submission so it can be used to run a general application instead of simply navigating hypertext, it's original purpose. All that because there's incentive in keeping users inside walled gardens and holding a ransom on their data. It's unbelievable we take as granted reinventing the wheel over and over again, dealing with weak standards and APIs designed by committee, fighting browsers into rendering interfaces and invoking the right callbacks. I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. The trend around mobile apps and some very successful native apps on the Mac App Store that consume web services seems to me as a best-of-two-worlds approach. > I have a hunch that WebDAV combined with standard HTTP authentication could be the answer. I’m not 100% sure on it, but I can easily envision a world where you fix bugs in your website by opening it up in a browser, reading a stack trace, fixing the JS in that same browser and persisting your changes back to the server. > I dream of the days when the Web truly does resemble SmallTalk. This would be more like a world with 5 different SmallTalk implementations, each slightly different, and all with a crappy/non-existant standard library and security model.

IEatShortPeople 14y ago
I disagree with your idea of running native code on the client as a replacement for the web in the context of laptops and desktops. The app store works because apple curates it. In the Android marketplace, many applications are viruses (http://www.androidguys.com/2012/12/14/lookout-18-million-infected-android-devices-by-end-of-2013/ http://www.androidguys.com/2012/12/14/lookout-18-million-inf...). If more than 9-10% of laptops and desktops had access to the app store, I would imagine that malware would be a more significant problem. Therefore, while I agree with the rest of your complaints, I disagree with the idea of making the web run using native code. I think that an interpreted environment will become good enough to do everything a user wants as computers get faster. In fact, if we can assume the standard user watches Youtube videos and sends and receives images and text through Facebook/Instagram/..., then interpreted code is fast enough today. On the web, where the user must constantly accept and run code from unknown and untrusted developers, code must run in a sandbox to minimize risk of unwanted access to the user's computer. Side Note: I also just really, really hate app stores. I find them to be much more restrictive than just throwing a website up and allowing anyone to access it. The idea of having to pay someone to allow users to be able to use my stuff is way too restrictive to me.
- hcarvalhoalves 14y ago
  Strictly speaking, native clients have nothing to do with app stores or speed. I just mentioned mobile apps and some software available in the Mac App Store as success cases because native clients backed by HTTP APIs seem to be a much saner development environment than shoehorning an app to run inside a browser, which is limited to one language, crappy APIs, broken interaction models and lack of standards. > On the web, where the user must constantly accept and run code from unknown and untrusted developers, code must run in a sandbox to minimize risk of unwanted access to the user's computer. First, sandboxed environments are not limited to browsers (e.g., OS X 10.8). Second, browsers are often the attack vector, because they were never meant to run applications, and have broken security models (e.g., no application signing). So you end up in a sandboxed environment with terribly limited APIs in the name of security, and on the other hand have hard to trace security holes, like XSS.
  - pjmlp 14y ago
    This is what I, after years of web development consulting, now advocate. The browser should be left for documents. The only way to provide the best user experience and operating system integration is via native applications, regardless of the environment, which communicate via network protocols.
crazygringo 14y ago
> I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. But that exists. It's called native programs, which are free to access web API's and whatnot just as much as any browser is. The whole point of the web is you don't have to download software, you don't have to store your data locally. Sure, it's a pain to support the quirks of different browsers and some badly designed web standards, but I'll take that any day over having to program for entirely different operating systems. I fail to see how web apps are a hack at all. Sure, they're not the "original purpose" of the web, but they work awfully well for things like GMail, GDocs, GMaps, etc. -- I'm awfully happy to have all these inside of browser tabs, instead of cluttering up my machine with more installed apps.
- hcarvalhoalves 14y ago
  > I fail to see how web apps are a hack at all. (...) Sure, they're not the "original purpose" of the web, but they work awfully well for things like GMail, GDocs, GMaps, etc. Well, you realize all the products you mention were only possible because someone figured out a hack (XMLHttpRequest), and now everybody relies on something that wasn't thought out in any shape or form? Can you see how fragile is the software stack an entire web industry is basing itself on? Also, I don't find GMail, GDocs or GMaps the epitome of good UI and interaction models, I can point a handful of quirks (GDocs is particularly bad.). I don't think these products withstand a round of user testing, people just take it for granted because they are provided for free. When a better alternative shows up (Sparrow), people flock to it even if it's a paid app. Of course, Google killed it, they are web app zealots after all and need the revenue from the ads.
  - gamblor956 14y ago
    XMLHttpRequest is not a hack. It was deliberately developed by Microsoft as part of Internet Explorer to enable desktop-like functionality in Outlook Web Access. [http://www.alexhopmann.com/xmlhttp.htm http://www.alexhopmann.com/xmlhttp.htm]. It was then copied by Netscape, and it spread from there.
    - 14y ago
cpeterso 14y ago
I don't disagree, but the web has a huge advantage over native applications: deployment. Installation is a nop. Every user has the latest version. The same website will (probably) work on an iPad and a Windows PC. Agile companies like Facebook roll out multiple releases each day. Imagine if Microsoft Word wanted to install an update every day! :)
- nnq 14y ago
  ...what would be so wrong with something like Word installing even a few updated a day, if it would do it "stealthly" and without disrupting my workflow? It can be done. People writing autoupgradeable software should learn a thing or two from good spyware writers...
nnq 14y ago
"A giant hack" is your name for evolved technology, as opposed to designed technology. Of course, there's nothing truly "evolved" in software and nothing designed that didn't evolve, it's just two ends of an axis measuring a weird think like "control and unitary vision". An extreme of "evolved" technology are things like the browsers and PHP - the templating language that was never intended to be a programming language and somehow mutated into one (and I assign most of its success to being attuned to the "evolvability spirit" of our web). Most "well designed" or "well engineered" software that could have powered the web either failed miserably or never reached the point of being usable or just wasn't there at the right time. I think there's a third path somewhere in this chaos, a path of software "designed/engineered to evolve", as opposed to "evolved" and "designed" software, a "nirvana" we should look for in this darkness. But in the meantime we can either embrace the "twisted creatures of webvolution"... or choose a different line of work :)
- Djehngo 14y ago
  I think there is a distinction between a platform's authors adding more functionality and the platform's users abusing existing functionality to make it do something it was never meant to. I would define the former as evolved and the latter as a hack. Web technology seems to have developed from a little of each. People were using iframes to do HTTP requests so XMLHttpRequest was added to IE, People were using long polling so HTML5 now supports websockets etc. etc.) I think the point of the grandparent is that the original standards were never meant to power applications, the web has changed but due to backwards compatability or old implementations the technology still has some warts. An example of this is CSS, it's a fantastic system if you want to lay some static text on a page interleaved with some static images and style the whole lot. If you are trying to create a semi-traditional GUI or a page where you can't know the sizes of elements in advance then the shortcomings of CSS become abundantly clear.
  - nnq 14y ago
    I don't like the distinction because for a software whose developers respond to what the users are doing, after every hackish new way the users find to (ab)use it, the developers come and add things that make it easier to do the things done by "hacks" (but at the same time they also need to keep the hacks working). And if the "users" of a software like the browsers are actually developers, it's obvious that they are not going to expect for features to be properly implemented, they will just (ab)used whatever half-assed features they can find. ...in my view, if you can clearly see "the distinction" between authors adding functionality and users abusing existing functionality for new purposes, it means that one party is clearly moving too slow: either the "users" are too slow to discover new ways to adopt and (ab)use the new software or the developers are working to slow and the users-developers need to do too many ugly hacks because the features they need take too long to be released and standardized (unfortunately the current state of web-development seems closer to this state of affairs). But there are possible solutions: I think things like standardization could be accelerated by having "tzars" in all committees (people that can just choose by themselves how some things over which they have authority get to work without needing a consensus or to justify to others why they choose one way) - I'm using the word "tzar" as in Haskell's "syntax tzar", the guy who could just choose what syntax a certain language feature needs and end the discussion right there because nobody had the right to contradict him [1] (I consider H's design-by-committee the only example where a committee did something mostly right and I wish similar "committees" would work on things like CSS and new ECMAScript versions...). But again, if standards evolve too fast, implementors will have to play catch-up and end-up with half-done implementations, which today happens even for sloth-slow evolving things like CSS. ...but of course, the real "root of all evil" is the backwards compatibility requirement, but we can't get away from this. ...and I know, some people will want to burn me at stake for screaming the "we're not going fast enough" heresy about web tech :) [1] http://my.safaribooksonline.com/book/software-engineering-and-development/9780596801670/haskell/a_functional_team http://my.safaribooksonline.com/book/software-engineering-an...
Uchikoma 14y ago
> I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. I won't. Installing native apps for everything I do? When I can just go to a app website and use it? I have no intention to go back into the 80s.
- derefr 14y ago
  There is no dichotomy between "the web" and "native applications", like the rhetoric here seems to imply. The line is much more blurred. You can buy "apps" on the Chrome Web Store that are launched from outside of the browser, render their own windows without Chrome's... chrome, etc. You can write native code that runs in a sandbox (NaCl) that gets updated whenever you hit Ctrl+R. And combining the two, you can "install" webapps, which happen to be launched like native apps, which happen to be written and updated like webapps, which happen to have all the performance and access-to-resources of native apps. Photoshop--the real one, not a janky Javascript clone--running "in" your web browser. Though it's not really a web browser any more, at that point: it's just a platform, like Silverlight, Adobe Air, etc. It just happens to be one for which there is this default "hypermedia viewer" app that comes with it.
- zokier 14y ago
  Ideally native app wouldn't require installation any more than a web app would. There is no reason why native apps couldn't be loaded dynamically on-demand from the internet. Java Web Start did something like that, but like all Java it was bit clunky. Of course current operating systems have poor support for such kind of behavior, but that could be remedied. I think the "activities" concept in Android already is first steps towards that goal.
  - Uchikoma 14y ago
    There are inherent problems which are not Java specific. Your app would need to have very few rights for starters, the sandbox should be as small as possible (like browser/JS). If you have different permissions and a complex sandbox with a runtime that supports classloaders, you run into the same security problems that Java currently enjoys for applets.
digeridoo 14y ago
Applets were always the answer. Amazing how badly a technology can fail because of start-up time.

IEatShortPeople 14y ago

I disagree with your idea of running native code on the client as a replacement for the web in the context of laptops and desktops. The app store works because apple curates it. In the Android marketplace, many applications are viruses (http://www.androidguys.com/2012/12/14/lookout-18-million-infected-android-devices-by-end-of-2013/ http://www.androidguys.com/2012/12/14/lookout-18-million-inf...). If more than 9-10% of laptops and desktops had access to the app store, I would imagine that malware would be a more significant problem. Therefore, while I agree with the rest of your complaints, I disagree with the idea of making the web run using native code. I think that an interpreted environment will become good enough to do everything a user wants as computers get faster. In fact, if we can assume the standard user watches Youtube videos and sends and receives images and text through Facebook/Instagram/..., then interpreted code is fast enough today. On the web, where the user must constantly accept and run code from unknown and untrusted developers, code must run in a sandbox to minimize risk of unwanted access to the user's computer. Side Note: I also just really, really hate app stores. I find them to be much more restrictive than just throwing a website up and allowing anyone to access it. The idea of having to pay someone to allow users to be able to use my stuff is way too restrictive to me.

hcarvalhoalves 14y ago
Strictly speaking, native clients have nothing to do with app stores or speed. I just mentioned mobile apps and some software available in the Mac App Store as success cases because native clients backed by HTTP APIs seem to be a much saner development environment than shoehorning an app to run inside a browser, which is limited to one language, crappy APIs, broken interaction models and lack of standards. > On the web, where the user must constantly accept and run code from unknown and untrusted developers, code must run in a sandbox to minimize risk of unwanted access to the user's computer. First, sandboxed environments are not limited to browsers (e.g., OS X 10.8). Second, browsers are often the attack vector, because they were never meant to run applications, and have broken security models (e.g., no application signing). So you end up in a sandboxed environment with terribly limited APIs in the name of security, and on the other hand have hard to trace security holes, like XSS.
- pjmlp 14y ago
  This is what I, after years of web development consulting, now advocate. The browser should be left for documents. The only way to provide the best user experience and operating system integration is via native applications, regardless of the environment, which communicate via network protocols.

crazygringo 14y ago

> I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. But that exists. It's called native programs, which are free to access web API's and whatnot just as much as any browser is. The whole point of the web is you don't have to download software, you don't have to store your data locally. Sure, it's a pain to support the quirks of different browsers and some badly designed web standards, but I'll take that any day over having to program for entirely different operating systems. I fail to see how web apps are a hack at all. Sure, they're not the "original purpose" of the web, but they work awfully well for things like GMail, GDocs, GMaps, etc. -- I'm awfully happy to have all these inside of browser tabs, instead of cluttering up my machine with more installed apps.

hcarvalhoalves 14y ago
> I fail to see how web apps are a hack at all. (...) Sure, they're not the "original purpose" of the web, but they work awfully well for things like GMail, GDocs, GMaps, etc. Well, you realize all the products you mention were only possible because someone figured out a hack (XMLHttpRequest), and now everybody relies on something that wasn't thought out in any shape or form? Can you see how fragile is the software stack an entire web industry is basing itself on? Also, I don't find GMail, GDocs or GMaps the epitome of good UI and interaction models, I can point a handful of quirks (GDocs is particularly bad.). I don't think these products withstand a round of user testing, people just take it for granted because they are provided for free. When a better alternative shows up (Sparrow), people flock to it even if it's a paid app. Of course, Google killed it, they are web app zealots after all and need the revenue from the ads.
- gamblor956 14y ago
  XMLHttpRequest is not a hack. It was deliberately developed by Microsoft as part of Internet Explorer to enable desktop-like functionality in Outlook Web Access. [http://www.alexhopmann.com/xmlhttp.htm http://www.alexhopmann.com/xmlhttp.htm]. It was then copied by Netscape, and it spread from there.
  - 14y ago

cpeterso 14y ago

I don't disagree, but the web has a huge advantage over native applications: deployment. Installation is a nop. Every user has the latest version. The same website will (probably) work on an iPad and a Windows PC. Agile companies like Facebook roll out multiple releases each day. Imagine if Microsoft Word wanted to install an update every day! :)

nnq 14y ago
...what would be so wrong with something like Word installing even a few updated a day, if it would do it "stealthly" and without disrupting my workflow? It can be done. People writing autoupgradeable software should learn a thing or two from good spyware writers...

nnq 14y ago

"A giant hack" is your name for evolved technology, as opposed to designed technology. Of course, there's nothing truly "evolved" in software and nothing designed that didn't evolve, it's just two ends of an axis measuring a weird think like "control and unitary vision". An extreme of "evolved" technology are things like the browsers and PHP - the templating language that was never intended to be a programming language and somehow mutated into one (and I assign most of its success to being attuned to the "evolvability spirit" of our web). Most "well designed" or "well engineered" software that could have powered the web either failed miserably or never reached the point of being usable or just wasn't there at the right time. I think there's a third path somewhere in this chaos, a path of software "designed/engineered to evolve", as opposed to "evolved" and "designed" software, a "nirvana" we should look for in this darkness. But in the meantime we can either embrace the "twisted creatures of webvolution"... or choose a different line of work :)

Djehngo 14y ago
I think there is a distinction between a platform's authors adding more functionality and the platform's users abusing existing functionality to make it do something it was never meant to. I would define the former as evolved and the latter as a hack. Web technology seems to have developed from a little of each. People were using iframes to do HTTP requests so XMLHttpRequest was added to IE, People were using long polling so HTML5 now supports websockets etc. etc.) I think the point of the grandparent is that the original standards were never meant to power applications, the web has changed but due to backwards compatability or old implementations the technology still has some warts. An example of this is CSS, it's a fantastic system if you want to lay some static text on a page interleaved with some static images and style the whole lot. If you are trying to create a semi-traditional GUI or a page where you can't know the sizes of elements in advance then the shortcomings of CSS become abundantly clear.
- nnq 14y ago
  I don't like the distinction because for a software whose developers respond to what the users are doing, after every hackish new way the users find to (ab)use it, the developers come and add things that make it easier to do the things done by "hacks" (but at the same time they also need to keep the hacks working). And if the "users" of a software like the browsers are actually developers, it's obvious that they are not going to expect for features to be properly implemented, they will just (ab)used whatever half-assed features they can find. ...in my view, if you can clearly see "the distinction" between authors adding functionality and users abusing existing functionality for new purposes, it means that one party is clearly moving too slow: either the "users" are too slow to discover new ways to adopt and (ab)use the new software or the developers are working to slow and the users-developers need to do too many ugly hacks because the features they need take too long to be released and standardized (unfortunately the current state of web-development seems closer to this state of affairs). But there are possible solutions: I think things like standardization could be accelerated by having "tzars" in all committees (people that can just choose by themselves how some things over which they have authority get to work without needing a consensus or to justify to others why they choose one way) - I'm using the word "tzar" as in Haskell's "syntax tzar", the guy who could just choose what syntax a certain language feature needs and end the discussion right there because nobody had the right to contradict him [1] (I consider H's design-by-committee the only example where a committee did something mostly right and I wish similar "committees" would work on things like CSS and new ECMAScript versions...). But again, if standards evolve too fast, implementors will have to play catch-up and end-up with half-done implementations, which today happens even for sloth-slow evolving things like CSS. ...but of course, the real "root of all evil" is the backwards compatibility requirement, but we can't get away from this. ...and I know, some people will want to burn me at stake for screaming the "we're not going fast enough" heresy about web tech :) [1] http://my.safaribooksonline.com/book/software-engineering-and-development/9780596801670/haskell/a_functional_team http://my.safaribooksonline.com/book/software-engineering-an...

Uchikoma 14y ago

> I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. I won't. Installing native apps for everything I do? When I can just go to a app website and use it? I have no intention to go back into the 80s.

derefr 14y ago
There is no dichotomy between "the web" and "native applications", like the rhetoric here seems to imply. The line is much more blurred. You can buy "apps" on the Chrome Web Store that are launched from outside of the browser, render their own windows without Chrome's... chrome, etc. You can write native code that runs in a sandbox (NaCl) that gets updated whenever you hit Ctrl+R. And combining the two, you can "install" webapps, which happen to be launched like native apps, which happen to be written and updated like webapps, which happen to have all the performance and access-to-resources of native apps. Photoshop--the real one, not a janky Javascript clone--running "in" your web browser. Though it's not really a web browser any more, at that point: it's just a platform, like Silverlight, Adobe Air, etc. It just happens to be one for which there is this default "hypermedia viewer" app that comes with it.
zokier 14y ago
Ideally native app wouldn't require installation any more than a web app would. There is no reason why native apps couldn't be loaded dynamically on-demand from the internet. Java Web Start did something like that, but like all Java it was bit clunky. Of course current operating systems have poor support for such kind of behavior, but that could be remedied. I think the "activities" concept in Android already is first steps towards that goal.
- Uchikoma 14y ago
  There are inherent problems which are not Java specific. Your app would need to have very few rights for starters, the sandbox should be as small as possible (like browser/JS). If you have different permissions and a complex sandbox with a runtime that supports classloaders, you run into the same security problems that Java currently enjoys for applets.

digeridoo 14y ago

Applets were always the answer. Amazing how badly a technology can fail because of start-up time.