The blog entry was tagged by the author as "blasphemy." It should have been tagged "idiocy."
"It’s a simple fact that complex web applications are almost impossible to create."
Maybe for the author. Aside from the stupid notion that complex == funky GUI widgets, it dismisses not only great AJAX frameworks but the Adobe Flex rich internet app building tools. Heck, with Adobe AIR you are making a desktop app that can live in a browser or the desktop. Rich text box controls? How about embedding FCKeditor, YUI's editor, or any of the other AJAX text editor components.
"And then you have to host this. Once you grow big, you will need a full time system administrator to manage all of this, the way Fog Creek and 37Signals both do."
Right. There's no overhead to creating and distributing desktop apps? You can automagically update customers' software without also managing the process?
The sad thing is I'm actually typing a rebuttal when it's clearly flamebait with an incendiary title. Must.. resist... next time.
His idea of a complex web application is completely misguided. He sees a "complex web application" as a "desktop application that runs in the browser." That's wrong, and it is no wonder why such "complex web applications" run better on the desktop.
My idea of a complex web application is one that simply cannot be done on the desktop. I'm making one and I don't even include any Javascript libraries. AJAX != Complexity.
Not that I agree with him, but what exactly can't be done on desktop? Everything you can do in a browser can be done in a desktop application because the browser is a desktop application.
You might argue that it would be easier to develop as web application, you might argue that it would lower barrier to entry because users won't need to download and install software. But please don't imply that there is some special about web applications which can't be done in a desktop application.
The funny thing to me is that he doesn't know that "desktop in a browser" functionality is not an incredibly complex thing for web apps anymore. It's a matter of having good enough client side development skills to implement it. Also, with UI frameworks like Flex, YUI-EXT, and Apache XAP abstracting all of the hard stuff away...you don't even have to be an expert.
This guy doesn't even fully understand the topic that he is ranting about.
This is an argument that has been going on since the first web apps started to emerge. The general argument is this: "You can't implement feature x in a browser". Initially the list of features that could not be implemented was quite long.
Things like rich-text editing, asynchronous communication, audio, video, drag and drop, sliders, etc. were very hard, or impossible. So, things like complex games, email clients, im clients, text editors, spreadsheets, and media players were out.
And that leads to the problem with his argument. The list of things which cannot be done on the web is constantly being reduced. Everything on that list can now be done... and fairly easily. (Which isn't to say they don't take time. Complex things take time... easy or not.)
So, now people have started saying things like "Well you can't implement (Photoshop|GIMP|text editors|IDEs|.+) on the web". That may be true for some limited amount of time, however, even now inroads are being made in all of the above. (See Heroku)
In short, people are going to continue clinging to the sinking ship that is this argument until they finally run out of applications to point at. If theres one thing I've learned from recent history... its best not to bet against the advancement of technology.
"... You may actually discover that your customers actually want to host the software themselves, even though it’s a web app, in which case you have to do #terrible things# [0] to make your dorkus malorkus customers happy. ..."
When I read this bit with link to the Joel on Software article on Wasabi I realised the author missed the finer point of why. From Joels article ...
"... And we have the ability to add any feature to the language that we want easily... this is the same power Paul Graham talks about in On Lisp, the power to invent new language features that suit your exact application domain. Lisp does this through a mechanism called macros. ..." [1]
Wasabi was a summer project by a super bright Intern who created a real compiler. [2] Meaning if the need arises to port the application to another language it can be done. For the price a one summers project Wasabi FogCreek can change languages without major re-writes. Wasabi also means the source code can be released. The customers get the benefit of access to the code they run. FogCreek still get to charge hard cash.
I remember having this argument many years back when developing handheld applications. Every customer we talked to wanted to view their app on the handheld through a browser, rather than use our fat client.
About 15 minutes of discussion put that to rest. I can dig up my bullets if anyone cares.
I suggest you revisit the handheld arena with an open mind in 2008. Some things still apply, but with bigger screens, always-on internet connectivity, and built-in web browsers that support full html and sometimes flash and ajax, handhelds are trending towards relying on web apps for mobility and extensibility. A web app should be the first mobile solution for a handheld because it is cheaper, easier, less wasteful in development, that also allows you to easily track statistics about which apps and features are being used, and how.
Then you can create a native version for the blackberry and iPhone to take advantage of one of the two things I believe make a native app advantageous at a later point in time:
1) synching the handheld's data with your web app, or
2) saving data to access if you're without an internet connection.
As far as GUI elements go, the iPhone lets you make your program look like a native application.
As far as speed of access, launching an app on an older treo model would take at least 2-5 seconds, especially a database application. You can load a web page over Wireless-G in today's handhelds in that time.
Amen. I can't believe someone took so long to say it: a browser is for browsing. I have yet to see a web app that blew my mind, or hell, even came close to what a standard fat-client application can do easily.
You're not seeing the potential of the web anymore than the original writer does. The web provides utility computing, the box on your desk does not. As soon as we lose this horse/buggy mindset and start noodling on the issues of 1) proof of correctness in code, 2) fault mitigation or absorption, and 3) true concurrency (grab a unit of computing power wherever it is), utility computing will absolutely render the desktop obsolete for any computing problem -- yep any computing problem. Right now, that Google facility in The Dalles can compute anything faster than what you can do on your desktop for less money. The fastest video card you can buy for your Dell will do one TFlop -- SETI@Home claims to be averaging 408 TFlops from a volunteer project. This is the law of economics kicking in, where money spent and efficiency desired cross, and it will kill the traditional desktop.
I dunno, I use plenty of web apps for running my business that are a lot better than anything I have found for the desktop. Also they saved me when I switched to the mac as I didn't need to look for a new version.
Ok, I waited to see if anyone would say it and no one has.
1) It is always easier to create a given user experience with the desktop. Desktop apps have more resources available and more tools. This favors the user.
2) Web apps are always easier to distribute. This includes distribution, versioning, upgrades, etc. This is not up for discussion. This always favors the producer.
3) It is generally easier to incorporate non-local data into a web app. This is not a significant factor compared to #1 and #2.
4) Success = balance between benefiting user and producer. Depending on the app, one will be favored over the other (i.e. low latency needed for games vs. low cost per user needed for ad-supported services).
5) If the user experience is acceptable to the user, then the producer benefits mean that it will probably be created as a web app. As more tools make producing acceptable user experiences cheaper, more apps will be web apps.
i think the point is that the web is not an easy platform to create apps for. so, when you end up choosing to do, you should ask yourself if it really is the best place.
for data that really needs to be shared with other users, like social networks, the web is really the best place for it, and the benefits of that connectivity outweighs the complete pain of doing so.
for something like spreadsheet software, you dont want to replace Excel, you want to add features that Excel would have an incredibly difficult time matching, like sharing and collaboration.
the web is a great way to share information with other people, and apps that rely on such sharing find their way to the internet.
Latency is an issue. If I've got hundreds of email messages to check then I'd rather do it with a native desktop application. However, for casual use, a web application is easily the most convenient and portable solution.
Photoshop has been done (perhaps not as sophisticated). Maya is hard to imagine, but stranger innovations have happened.
In any case: we're in the infancy of the inter-netter-webs. Someday schoolkids will view us the way we view the early aviators with their stiff, old-fashioned suits and their weirdo moustaches.
[+] [-] DocSavage|18 years ago|reply
"It’s a simple fact that complex web applications are almost impossible to create."
Maybe for the author. Aside from the stupid notion that complex == funky GUI widgets, it dismisses not only great AJAX frameworks but the Adobe Flex rich internet app building tools. Heck, with Adobe AIR you are making a desktop app that can live in a browser or the desktop. Rich text box controls? How about embedding FCKeditor, YUI's editor, or any of the other AJAX text editor components.
"And then you have to host this. Once you grow big, you will need a full time system administrator to manage all of this, the way Fog Creek and 37Signals both do."
Right. There's no overhead to creating and distributing desktop apps? You can automagically update customers' software without also managing the process?
The sad thing is I'm actually typing a rebuttal when it's clearly flamebait with an incendiary title. Must.. resist... next time.
[+] [-] mattjaynes|18 years ago|reply
Fortunately, enough guys get over these setbacks to propagate our species (and create web apps, build startups etc) ;)
[+] [-] carpal|18 years ago|reply
My idea of a complex web application is one that simply cannot be done on the desktop. I'm making one and I don't even include any Javascript libraries. AJAX != Complexity.
[+] [-] marcus|18 years ago|reply
You might argue that it would be easier to develop as web application, you might argue that it would lower barrier to entry because users won't need to download and install software. But please don't imply that there is some special about web applications which can't be done in a desktop application.
[+] [-] mpc|18 years ago|reply
This guy doesn't even fully understand the topic that he is ranting about.
[+] [-] akkartik|18 years ago|reply
[+] [-] tyler|18 years ago|reply
Things like rich-text editing, asynchronous communication, audio, video, drag and drop, sliders, etc. were very hard, or impossible. So, things like complex games, email clients, im clients, text editors, spreadsheets, and media players were out.
And that leads to the problem with his argument. The list of things which cannot be done on the web is constantly being reduced. Everything on that list can now be done... and fairly easily. (Which isn't to say they don't take time. Complex things take time... easy or not.)
So, now people have started saying things like "Well you can't implement (Photoshop|GIMP|text editors|IDEs|.+) on the web". That may be true for some limited amount of time, however, even now inroads are being made in all of the above. (See Heroku)
In short, people are going to continue clinging to the sinking ship that is this argument until they finally run out of applications to point at. If theres one thing I've learned from recent history... its best not to bet against the advancement of technology.
[+] [-] axod|18 years ago|reply
[+] [-] imsteve|18 years ago|reply
I found comfort in his anger towards the difficulty of developing for current web application platforms. The situation is obscenely bad.
[+] [-] bootload|18 years ago|reply
When I read this bit with link to the Joel on Software article on Wasabi I realised the author missed the finer point of why. From Joels article ...
"... And we have the ability to add any feature to the language that we want easily... this is the same power Paul Graham talks about in On Lisp, the power to invent new language features that suit your exact application domain. Lisp does this through a mechanism called macros. ..." [1]
Wasabi was a summer project by a super bright Intern who created a real compiler. [2] Meaning if the need arises to port the application to another language it can be done. For the price a one summers project Wasabi FogCreek can change languages without major re-writes. Wasabi also means the source code can be released. The customers get the benefit of access to the code they run. FogCreek still get to charge hard cash.
Never underestimate Joel.
[0] Wasabi, http://www.joelonsoftware.com/items/2006/09/01b.html
[1] Wasabi, Ibid
[2] You can read more "Up the tata without a tutu" ~ http://www.joelonsoftware.com/articles/fog0000000026.html
[+] [-] sanj|18 years ago|reply
About 15 minutes of discussion put that to rest. I can dig up my bullets if anyone cares.
[+] [-] vlad|18 years ago|reply
Then you can create a native version for the blackberry and iPhone to take advantage of one of the two things I believe make a native app advantageous at a later point in time:
1) synching the handheld's data with your web app, or 2) saving data to access if you're without an internet connection.
As far as GUI elements go, the iPhone lets you make your program look like a native application.
As far as speed of access, launching an app on an older treo model would take at least 2-5 seconds, especially a database application. You can load a web page over Wireless-G in today's handhelds in that time.
[+] [-] unknown|18 years ago|reply
[deleted]
[+] [-] david927|18 years ago|reply
[+] [-] jksmith|18 years ago|reply
[+] [-] DarrenStuart|18 years ago|reply
[+] [-] wvenable|18 years ago|reply
[+] [-] pchristensen|18 years ago|reply
1) It is always easier to create a given user experience with the desktop. Desktop apps have more resources available and more tools. This favors the user.
2) Web apps are always easier to distribute. This includes distribution, versioning, upgrades, etc. This is not up for discussion. This always favors the producer.
3) It is generally easier to incorporate non-local data into a web app. This is not a significant factor compared to #1 and #2.
4) Success = balance between benefiting user and producer. Depending on the app, one will be favored over the other (i.e. low latency needed for games vs. low cost per user needed for ad-supported services).
5) If the user experience is acceptable to the user, then the producer benefits mean that it will probably be created as a web app. As more tools make producing acceptable user experiences cheaper, more apps will be web apps.
[+] [-] edw519|18 years ago|reply
Henry Ford
I guess there's a little less competition for those of us here who think we can.
[+] [-] joeguilmette|18 years ago|reply
for data that really needs to be shared with other users, like social networks, the web is really the best place for it, and the benefits of that connectivity outweighs the complete pain of doing so.
for something like spreadsheet software, you dont want to replace Excel, you want to add features that Excel would have an incredibly difficult time matching, like sharing and collaboration.
the web is a great way to share information with other people, and apps that rely on such sharing find their way to the internet.
[+] [-] cellis|18 years ago|reply
[+] [-] ice5nake|18 years ago|reply
[+] [-] thingsilearned|18 years ago|reply
"Nothing bothers me more than unchallenged ignorance."
http://metacircular.wordpress.com/2007/12/11/the-triumph-of-...
[+] [-] xirium|18 years ago|reply
[+] [-] chaostheory|18 years ago|reply
[+] [-] sammyo|18 years ago|reply
[+] [-] tx|18 years ago|reply
[+] [-] sabat|18 years ago|reply
In any case: we're in the infancy of the inter-netter-webs. Someday schoolkids will view us the way we view the early aviators with their stiff, old-fashioned suits and their weirdo moustaches.
[+] [-] rms|18 years ago|reply
[+] [-] curi|18 years ago|reply
[+] [-] warwick|18 years ago|reply
[+] [-] sabat|18 years ago|reply
Poster, question your presumptions. Wallowing frustration is your enemy. Things are much better than you imagine.