Web applications suck and they’re not worth creating(metacircular.wordpress.com)
metacircular.wordpress.com
Web applications suck and they’re not worth creating
http://metacircular.wordpress.com/2008/02/04/web-applications-suck-and-theyre-not-worth-creating/
18 comments
"Girls suck, and they're not worth dating (sob... sniffle...)"
Fortunately, enough guys get over these setbacks to propagate our species (and create web apps, build startups etc) ;)
Fortunately, enough guys get over these setbacks to propagate our species (and create web apps, build startups etc) ;)
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.
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.
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.
For practical purposes, I agree with the original author that there are things that can be done on the desktop that can't be done on the browser, but not the other way around. This is just a simple extension of the fact that the user has the same computer and the same internet connection, but in a browser-based app, you don't have access to all the computer's resources. Therefore, you have less overall power available and there are things that theoretically can't be done. If you have unlimited bandwidth and transfer speeds, then there is no difference.
And there's nothing you couldn't do with a desktop app, if for no other reason that you could "Greenspun" a full browser into your desktop app to include anything that theoretically couldn't be done without a browser.
And there's nothing you couldn't do with a desktop app, if for no other reason that you could "Greenspun" a full browser into your desktop app to include anything that theoretically couldn't be done without a browser.
Up modded both for merit and for making Greenspun a verb.
Already a verb (or at least a gerund):
http://www.google.com/search?hl=en&q=greenspunning
http://www.google.com/search?hl=en&q=greenspunning
What I need is a multimedia (product description and examples), hyperlinked (for product referrals) app browsing program that will transparently download and run the apps I'm interested in. Can you greenspin this out of your desktop software?
Like all things, there is the good and the bad. The author is referring to BAD web apps that simply port desktop apps to the web.
Good web apps are ones that utilize features of web apps to enhance the application. For example
Collaborative work Easy deployment Being Viral Mobility CHEAP CHEAP CHEAP, no need to print cds.(save some trees, or petroleum)
i ran out of things for now, but i'm sure come up with more after my hot pocket.
Good web apps are ones that utilize features of web apps to enhance the application. For example
Collaborative work Easy deployment Being Viral Mobility CHEAP CHEAP CHEAP, no need to print cds.(save some trees, or petroleum)
i ran out of things for now, but i'm sure come up with more after my hot pocket.
Hot pocket ( http://www.urbandictionary.com/define.php?term=hot%20pocket )? I wasn't famaliar with this phrase. Perhaps, I shouldn't have consulted the Urban Dictionary.
With web-applications you can force users to either pay for them or not use them. Good luck doing that with desktop applications.
People can't use my desktop application at any random library, or on their {i,g}phone--with my web application they can.
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 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.
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.
Who voted this up? I'm not sure it really merits a reply to be honest.
The trick is, don't make conclusions about the article based on its title.
I found comfort in his anger towards the difficulty of developing for current web application platforms. The situation is obscenely bad.
I found comfort in his anger towards the difficulty of developing for current web application platforms. The situation is obscenely bad.
Has it ever been easier? Is there some hidden nostalgia for a world I'm not a part of that made application development dramatically simpler? Writing code is hard, no matter what the environment, one of Java's largest failures was 'write once, read anywhere'. Look at Joel's experience with .NET: http://www.joelonsoftware.com/articles/PleaseLinker.html. This article is just shrill yelling of 'square peg! round hole!' and apparently it works.
> Has it ever been easier?
Yes. I remember many years ago I wrote a web application for a swiss banks financial intelligence unit. It was only used by a handful of people and they wanted a really rich user experience, so I wrote -- in one day -- the complete application again as a fat client. It was simply better in every way. The main client said, "That's it! That's what we want!" The director of IT said, "That's a fat client. We can't have that in the bank." The web app was never terrible, but the fat client I made them was much better and easier to create.
Everyone here who is arguing that web applications are 100% as easy to produce as fat client applications are arguing out of ignorance.
Yes. I remember many years ago I wrote a web application for a swiss banks financial intelligence unit. It was only used by a handful of people and they wanted a really rich user experience, so I wrote -- in one day -- the complete application again as a fat client. It was simply better in every way. The main client said, "That's it! That's what we want!" The director of IT said, "That's a fat client. We can't have that in the bank." The web app was never terrible, but the fat client I made them was much better and easier to create.
Everyone here who is arguing that web applications are 100% as easy to produce as fat client applications are arguing out of ignorance.
I did read the article...
Web development these days is probably the easiest it's been, the only issue is IE, and that seems to be declining in usage thank goodness.
which one is easier?
1) Dealing with WinForms (or WPF) 2) Dealing with C#
vs
1) Dealing with Server-side code 2) Dealing with XHTML and CSS and JavaScript (and compressing them) 3) And dealing with IE, FF, Safari (let's leave Opera)
1) Dealing with WinForms (or WPF) 2) Dealing with C#
vs
1) Dealing with Server-side code 2) Dealing with XHTML and CSS and JavaScript (and compressing them) 3) And dealing with IE, FF, Safari (let's leave Opera)
I'd choose web development every time as the easier option.
"... 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.
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
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
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.
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.
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.
I think that your statement that you should build a web app first is absolutely correct: as long as you assume it will be the 'one to throw away' (http://everything2.com/index.pl?node_id=1011623). It will be a toy application and barely a proof of concept.
I've personally replaced dozens of those systems.
I believe that there are differences that are specific and salient to handheld devices that are still quite relevant today.
1. Processor Speed / Battery Life / Energy Density
Moore's law does NOT apply to batteries; they increase in capacity at about 3-5%/a. This means that the limiting factor on processing is NOT the processor, but the energy you can feed it (and that you can wick away as heat). Cutting edge handheld processors are still at about 400-600MHz and have been stuck there for many, many years.
2. Browser complexity and inefficiency
This is related to the first point. Browsers are among the most complex applications that run on desktops and handhelds. They tend to eat up obscene amounts of memory and use a lot of clock cycles interpreting languages (CSS, HTML, Javascript, Flash...). This chews through the available (slow) processing available on handhelds. You could limit what you use, but AJAX and its ilk are part of what make a web interface workable.
3. Security
This may only be relevant to the work I did in Healthcare. While I trust the SSL implementations, I don't trust the caching implementations on Handheld browsers. Given that these devices get lost, do you want to be liable for confidential patient data stored on them in a format that isn't under your control? Want to encrypt it with some clever javascript in the browser? See points 1 & 2.
4. Diversity
Developing for IE6/7/8, FF, Opera and Safari is one thing. Adding the proclivities of the browsers on the iPhone, WinCE, PalmOS (where there are several), RIM, and all other smartphones will make you go bald. Now imagine testing on all of them as well. The issue is more interesting. If your marketing dept gets wind of the fact that it works on a mobile browser, you're suddenly flooded with support calls the moment a new fancy phone appears on the market.
5. Novel User Interfaces: beyond the G in GUI
One of the cool things about these phones is that they have neat UI things to take advantage of: the 5-way scroller on the Palm, the rocker switch on the RIMs, multitouch on the iPhone, fingerprint, passcard and barcode scanners on some specialized devices. NONE of these are under your direct control if you build a web app. You're at the mercy of the common set of UI made available across the browsers and how each of those browsers interprets the gestures.
6. Constant connectivity
Again, this may be due to my work in the medical field, but I was shocked at how many installations were crippled do to lack of building-wide WiFi or huge dead zones. Like ALL of radiology. Or the entire wing that was put up in 1948 where the internal walls were plaster on chicken wire. Even looked at the size of chicken wire? Ever compared it to the wavelength of a 2.4GHz signal? It'd be hard to block signal more effectively. And if you're moving around a list of 14k ICD codes or 7k CPT codes, you're going to need that pipe to stay open.
Now, having ranted, lets look at the world as it stands:
- why were developers up in arms over the lack of an iPhone SDK?
- why isn't Android just a set of javascript libs?
- why are are ALL apps on the RIM fat, local applications?
- why did Google invest time/money/effort into creating local Java implementations of Maps and Mail?
- can you name a single, widely deployed mobile app that's purely on the browser?
I think the world has changed, but not nearly enough.
I've personally replaced dozens of those systems.
I believe that there are differences that are specific and salient to handheld devices that are still quite relevant today.
1. Processor Speed / Battery Life / Energy Density
Moore's law does NOT apply to batteries; they increase in capacity at about 3-5%/a. This means that the limiting factor on processing is NOT the processor, but the energy you can feed it (and that you can wick away as heat). Cutting edge handheld processors are still at about 400-600MHz and have been stuck there for many, many years.
2. Browser complexity and inefficiency
This is related to the first point. Browsers are among the most complex applications that run on desktops and handhelds. They tend to eat up obscene amounts of memory and use a lot of clock cycles interpreting languages (CSS, HTML, Javascript, Flash...). This chews through the available (slow) processing available on handhelds. You could limit what you use, but AJAX and its ilk are part of what make a web interface workable.
3. Security
This may only be relevant to the work I did in Healthcare. While I trust the SSL implementations, I don't trust the caching implementations on Handheld browsers. Given that these devices get lost, do you want to be liable for confidential patient data stored on them in a format that isn't under your control? Want to encrypt it with some clever javascript in the browser? See points 1 & 2.
4. Diversity
Developing for IE6/7/8, FF, Opera and Safari is one thing. Adding the proclivities of the browsers on the iPhone, WinCE, PalmOS (where there are several), RIM, and all other smartphones will make you go bald. Now imagine testing on all of them as well. The issue is more interesting. If your marketing dept gets wind of the fact that it works on a mobile browser, you're suddenly flooded with support calls the moment a new fancy phone appears on the market.
5. Novel User Interfaces: beyond the G in GUI
One of the cool things about these phones is that they have neat UI things to take advantage of: the 5-way scroller on the Palm, the rocker switch on the RIMs, multitouch on the iPhone, fingerprint, passcard and barcode scanners on some specialized devices. NONE of these are under your direct control if you build a web app. You're at the mercy of the common set of UI made available across the browsers and how each of those browsers interprets the gestures.
6. Constant connectivity
Again, this may be due to my work in the medical field, but I was shocked at how many installations were crippled do to lack of building-wide WiFi or huge dead zones. Like ALL of radiology. Or the entire wing that was put up in 1948 where the internal walls were plaster on chicken wire. Even looked at the size of chicken wire? Ever compared it to the wavelength of a 2.4GHz signal? It'd be hard to block signal more effectively. And if you're moving around a list of 14k ICD codes or 7k CPT codes, you're going to need that pipe to stay open.
Now, having ranted, lets look at the world as it stands:
- why were developers up in arms over the lack of an iPhone SDK?
- why isn't Android just a set of javascript libs?
- why are are ALL apps on the RIM fat, local applications?
- why did Google invest time/money/effort into creating local Java implementations of Maps and Mail?
- can you name a single, widely deployed mobile app that's purely on the browser?
I think the world has changed, but not nearly enough.
[deleted]
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.
Thanks for reiterating conventional wisdom, but the person missing something here is you.
Sure Google can computer more for less, but I already have a PC; why buy two (one for Google and one for me)? SETI@Home leverages... (wait for it)... the desktop!
Second, the point here is not about utility computing. It's about developing applications. Let's face it, web apps are struggling to the the things that most desktop apps do easily. (Ajax is a joke.) Certainly they both have their pros and cons. And there are certainly some situations where a web app makes more sense. Don't get me wrong. But when creating rich applications, the web sucks. And all your arguing here won't change that.
Sure Google can computer more for less, but I already have a PC; why buy two (one for Google and one for me)? SETI@Home leverages... (wait for it)... the desktop!
Second, the point here is not about utility computing. It's about developing applications. Let's face it, web apps are struggling to the the things that most desktop apps do easily. (Ajax is a joke.) Certainly they both have their pros and cons. And there are certainly some situations where a web app makes more sense. Don't get me wrong. But when creating rich applications, the web sucks. And all your arguing here won't change that.
No, you can computer more for less because of utility computing examples like Google. And I didn't say that having something that provides computing power in the home will go away, just that the value of you sitting down with your IBM PC-AT and running Lotus 123 will go away. When you claim that the desktop is better than the web, you had SETI@Home in mind?
And it is all about efficiently using computing power -- this will change your view on developing applications for the better. The sooner you accept that the web is a better path, the sooner you'll figure out to make web apps better, and we'll all appreciate your work.
And it is all about efficiently using computing power -- this will change your view on developing applications for the better. The sooner you accept that the web is a better path, the sooner you'll figure out to make web apps better, and we'll all appreciate your work.
For now, there are any number of advantages to desktop apps. Ten years from now, everything is going to be in the cloud.
I need a downmod.
I need 10 downmods for you sir. But alas ycnews in it's infinite wisdom has denied me a down arrow.
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.
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.
"If you think you can do a thing or think you can't do a thing, you're right."
Henry Ford
I guess there's a little less competition for those of us here who think we can.
Henry Ford
I guess there's a little less competition for those of us here who think we can.
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.
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.
I use google docs on a regular basis, and it pains me how bad it is sometimes. The worst part about it is that it's not the people writing the software, it's that the web is a really lousy platform for certain applications. I can't think of any other reasons a 10 line spreadsheet would bring a brand new machine to its knees.
On the flip side, I use google docs because it's free, works anywhere on any platform without installation, and it is way better for collaboration than office. Maybe once the improved standards and JIT javascript compilers come with the next wave of browsers these applications will really come into full force. At this point I don't care how good the desktop applications are, for certain tasks that don't require anything more than rich text editing I'll stick with online tools.
Web-based software also allows you to constantly update your software without even making the user aware that the software is getting updated. To my mind, that is one of the biggest advantages of web-based software and one of the reasons why it will ultimately kill most forms of "desktop" software.
Not to mention you can use webapps from your wii console, iPhone, etc etc. You get multiple platform support pretty much free.
Awesome! One less person i have to compete with!
Totally pointless. All arguments. They are one and the same.
Great comments everyone. If there's one thing I agree with the other on its the first line in one of his other articles.
"Nothing bothers me more than unchallenged ignorance."
http://metacircular.wordpress.com/2007/12/11/the-triumph-of-...
"Nothing bothers me more than unchallenged ignorance."
http://metacircular.wordpress.com/2007/12/11/the-triumph-of-...
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.
both Comet and Flash address that issue...
I can see the benefit of Comet in this case but I don't see the benefit of Flash. Please could you explain.
I thought like Comet, Flash can send data asynchronously. the client doesn't have to continually poll the server. Am I wrong?
Yep. Thats correct. Although, at the last point I looked into it, there were some firewall-related problems with using Flash for that purpose. I don't remember the details though...
So reimplementing Maya or Photoshop is a bad idea?
Reimplementing is a bad idea.
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.
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.
Not to mention our steam-powered bird-o-copters. As primitive as 1980's software looks from 2008, it will look twice as primitive just 10 years from now.
Gmail, anyone?
So, why did he use wordpress to write this, instead of a desktop application which outputs html pages or something?
Perhaps he used a desktop blogging client.
still involves a web app.
Not to mention we wouldn't be here talking about this were it not for a webapp by our friend paul...
Blogga, please.
Poster, question your presumptions. Wallowing frustration is your enemy. Things are much better than you imagine.
Poster, question your presumptions. Wallowing frustration is your enemy. Things are much better than you imagine.
"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.