Web applications suck and they’re not worth creating
metacircular.wordpress.com
metacircular.wordpress.com
"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.
Fortunately, enough guys get over these setbacks to propagate our species (and create web apps, build startups etc) ;)
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.
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.
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.
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.
This guy doesn't even fully understand the topic that he is ranting about.
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.
I found comfort in his anger towards the difficulty of developing for current web application platforms. The situation is obscenely bad.
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.
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)
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
About 15 minutes of discussion put that to rest. I can dig up my bullets if anyone cares.
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'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.
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.
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.
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.
Henry Ford
I guess there's a little less competition for those of us here who think we can.
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.
"Nothing bothers me more than unchallenged ignorance."
http://metacircular.wordpress.com/2007/12/11/the-triumph-of-...
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.
Poster, question your presumptions. Wallowing frustration is your enemy. Things are much better than you imagine.