Hacker News Reader

> 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.

> 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.

Arguments about the hacky-ness and fragility of web apps are always extremely silly.

Unix was also a hack. C was also a hack. Windows 95 was also a hack. Windows NT had better design, but with hacks bolted on to make it compatible with Win 9X. Java was a hack. Linux was a hack. The Internet itself is the biggest hack of all.

In fact I dare you to name one successful platform that wasn't a hack. Because from where I'm standing, the platforms that weren't hacks failed, in addition to being on the whole horrible.

> I don't find GMail, GDocs or GMaps the epitome of good UI and interaction models, I can point a handful of quirks

With all those quirks, GMail killed the desktop email client for me. For the last 4 years I haven't been able to use any other client. Even on my iPad, before the latest "native" GMail on iOS I was using the web version, simply because Apple's Mail app wasn't doing threaded conversations well.

For all the quirks of the web version of Google Maps, at least it is available everywhere. Just ask the poor schmucks that were in a hurry to upgrade to iOS 6.

Same argument goes for GDocs. It's available everywhere and it allows for efficient collaborative editing. You just open a browser and you're good to go. It doesn't even have to be your browser. I do value this a lot.

> I don't think these products withstand a round of user testing, people just take it for granted because they are provided for free.

I'm a Google Apps customer and I also pay for Google Drive, if it matters. And quite the contrary, people receiving stuff for free tend to be more self-entitled and critical. That people don't voice too many negative opinions on these products is kind of shocking, because either Google has a really good PR department or these products do in fact satisfy most users.

> When a better alternative shows up (Sparrow), people flock to it even if it's a paid app

For what is worth, I didn't.

On the Windows 95 "hack": http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-...

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]. It was then copied by Netscape, and it spread from there.

> 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.

I believe you tried to correct me, but you proved my point even further.

Desktop-like functionality on a software meant to navigate between linked documents is simply a broken interaction model.

Or you see it as a finishing off the implementation of the hypermedia model's original idea of transclusion.

>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.

Sparrow? It existed for a couple of years before being bought by Google and people hardly "flocked" to it. It was mostly a marginal app. The overwhelming majority of OS X users either used Mail.app or Gmail on the web.

Google just brought it for the talent and to get some better native app tech. Not because people were ...flocking to Sparrow and lessening Google's revenue. I doubt there was even a dent to their revenue.

>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?

How is that different from, anything else, really? The first wheel was also a hack. Fire was also a hack (hey, let's bang this two stones together).

XMLHttpRequest was not a hack. It was a feature engineered my Microsoft that people found another use for. After that the hack status was gone: it was standardised, documented, best practices were written, an interchange format was invented for it (JSON), etc.

Don't conflate the origin with the result.

Sure, you don't have to download software.

On the other hand, the platforms we /do/ download software onto (in real time) are disgusting.

(I wrote PHP for the first time last week. Oh. My. God. Why does this crap exist? WHY IN GOD'S NAME (yes I am shouting) DO WE PUT UP WITH THIS UNBELIEVABLY MISERABLE CRAPFEST WE CALL MODERN WEB DEVELOPMENT!?)

Um . . . breathe.

I don't have any answers today that don't involve burning something to the ground, public shaming, or retreating to a code monastary and crafting a diamond (which /never/ works).

How do we get unstuck?

PHP has nothing to do with the browser (i.e. the "platform you download software into"). If you don't like programming in PHP, then pick a different server side language instead. Even JavaScript can mostly be avoided, if you want, by using one of the higher level languages that compiles down to JavaScript.

My objections don't start (or end) with PHP. Browsers are terrible platforms, and the protocols we have to deal with are likewise terrible (ever written an HTTP proxy? Oh boy).

> (ever written an HTTP proxy? Oh boy)

Oh yeah, and it's not fairly hard. After all, it's a well defined, text-based protocol. It's sweet to implement if you're not using C. That is, before you started supporting persistent connections or interacting with the content.

In any case, it's loads better than FTP and SMTP (at least HTTP spelled things completely), and loads easier to use than binary protocols.

"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 :)

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.

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-an...

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-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.

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.

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.

> 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.

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.

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.

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.

Security, permission management, and sandboxing would be critical concepts of a system running code from potentially untrusted sources. But I don't think the security problems often associated with Java and Flash are inherent for such sandboxes. Web browsers themselves are an excellent example of sandboxing that seems to have stood fairly well against attacks. And NaCl demonstrates that the security model of web browsers is extensible to native code.

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! :)

...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...

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