5 ms·

Web applications suck and they’re not worth creating

48 points by iamelgringo 19y ago

sammyo 19y ago
So reimplementing Maya or Photoshop is a bad idea?
- sabat 19y ago
  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.
  - horia314 19y ago
    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.
- tx 19y ago
  Reimplementing is a bad idea.
edw519 19y ago
"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.
- joeguilmette 19y ago
  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.
  - ashu 19y ago
    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.
    - axod 19y ago
      Not to mention you can use webapps from your wii console, iPhone, etc etc. You get multiple platform support pretty much free.
  - SirWart 19y ago
    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.
carpal 19y ago
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.
- marcus 19y ago
  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.
  - pchristensen 19y ago
    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.
    - marcus 19y ago
      Up modded both for merit and for making Greenspun a verb.
      - 19y ago
ice5nake 19y ago
Totally pointless. All arguments. They are one and the same.
DocSavage 19y ago
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.
sabat 19y ago
Blogga, please. Poster, question your presumptions. Wallowing frustration is your enemy. Things are much better than you imagine.
david927 19y ago
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.
- wvenable 19y ago
  So says a person posting to news.ycombinator.com! Go back to Usenet.
  - wallflower 19y ago
    Bitnet
- DarrenStuart 19y ago
  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.
- jksmith 19y ago
  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.
  - david927 19y ago
    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.
sanj 19y ago
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.
- deleted 19y ago
  [deleted]
- vlad 19y ago
  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.
  - sanj 19y ago
    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 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.
curi 19y ago
So, why did he use wordpress to write this, instead of a desktop application which outputs html pages or something?
- warwick 19y ago
  Perhaps he used a desktop blogging client.
  - curi 19y ago
    still involves a web app.
    - kajecounterhack 19y ago
      Not to mention we wouldn't be here talking about this were it not for a webapp by our friend paul...
xirium 19y ago
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.
- chaostheory 19y ago
  both Comet and Flash address that issue...
  - xirium 19y ago
    I can see the benefit of Comet in this case but I don't see the benefit of Flash. Please could you explain.
    - chaostheory 19y ago
      I thought like Comet, Flash can send data asynchronously. the client doesn't have to continually poll the server. Am I wrong?
      - tyler 19y ago
        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...
axod 19y ago
Who voted this up? I'm not sure it really merits a reply to be honest.
- imsteve 19y ago
  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.
  - scw 19y ago
    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 http://www.joelonsoftware.com/articles/PleaseLinker.html. This article is just shrill yelling of 'square peg! round hole!' and apparently it works.
    - david927 19y ago
      > 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.
  - axod 19y ago
    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.
mattjaynes 19y ago
"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) ;)
tyler 19y ago
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.
rms 19y ago
Gmail, anyone?
bootload 19y ago
"... 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 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 http://www.joelonsoftware.com/articles/fog0000000026.html
cellis 19y ago
Awesome! One less person i have to compete with!
pchristensen 19y ago
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.
thingsilearned 19y ago
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-open-source-or-walt-mossberg-is-an-annoying-self-centered-ignoramus/ http://metacircular.wordpress.com/2007/12/11/the-triumph-of-...

48 points by iamelgringo 19y ago

sammyo 19y ago

So reimplementing Maya or Photoshop is a bad idea?

sabat 19y ago
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.
- horia314 19y ago
  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.
tx 19y ago
Reimplementing is a bad idea.

edw519 19y ago

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

joeguilmette 19y ago
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.
- ashu 19y ago
  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.
  - axod 19y ago
    Not to mention you can use webapps from your wii console, iPhone, etc etc. You get multiple platform support pretty much free.
- SirWart 19y ago
  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.

carpal 19y ago

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.

marcus 19y ago
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.
- pchristensen 19y ago
  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.
  - marcus 19y ago
    Up modded both for merit and for making Greenspun a verb.
    - 19y ago

ice5nake 19y ago

Totally pointless. All arguments. They are one and the same.

DocSavage 19y ago

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.

sabat 19y ago

Blogga, please. Poster, question your presumptions. Wallowing frustration is your enemy. Things are much better than you imagine.

david927 19y ago

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.

wvenable 19y ago
So says a person posting to news.ycombinator.com! Go back to Usenet.
- wallflower 19y ago
  Bitnet
DarrenStuart 19y ago
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.
jksmith 19y ago
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.
- david927 19y ago
  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.

sanj 19y ago

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.

deleted 19y ago
[deleted]
vlad 19y ago
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.
- sanj 19y ago
  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 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.

curi 19y ago

So, why did he use wordpress to write this, instead of a desktop application which outputs html pages or something?

warwick 19y ago
Perhaps he used a desktop blogging client.
- curi 19y ago
  still involves a web app.
  - kajecounterhack 19y ago
    Not to mention we wouldn't be here talking about this were it not for a webapp by our friend paul...

xirium 19y ago

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.

chaostheory 19y ago
both Comet and Flash address that issue...
- xirium 19y ago
  I can see the benefit of Comet in this case but I don't see the benefit of Flash. Please could you explain.
  - chaostheory 19y ago
    I thought like Comet, Flash can send data asynchronously. the client doesn't have to continually poll the server. Am I wrong?
    - tyler 19y ago
      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...

axod 19y ago

Who voted this up? I'm not sure it really merits a reply to be honest.

imsteve 19y ago
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.
- scw 19y ago
  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 http://www.joelonsoftware.com/articles/PleaseLinker.html. This article is just shrill yelling of 'square peg! round hole!' and apparently it works.
  - david927 19y ago
    > 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.
- axod 19y ago
  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.

mattjaynes 19y ago

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

tyler 19y ago

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.

rms 19y ago

Gmail, anyone?

bootload 19y ago

"... 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 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 http://www.joelonsoftware.com/articles/fog0000000026.html

cellis 19y ago

Awesome! One less person i have to compete with!

pchristensen 19y ago

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.

thingsilearned 19y ago

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-open-source-or-walt-mossberg-is-an-annoying-self-centered-ignoramus/ http://metacircular.wordpress.com/2007/12/11/the-triumph-of-...