
Web applications suck and they’re not worth creating - iamelgringo
http://metacircular.wordpress.com/2008/02/04/web-applications-suck-and-theyre-not-worth-creating/
======
DocSavage
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.

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

------
carpal
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
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
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
Up modded both for merit and for making Greenspun a verb.

~~~
icky
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)

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

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

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

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

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

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

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

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

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

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

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

------
edw519
"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
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
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
Not to mention you can use webapps from your wii console, iPhone, etc etc. You
get multiple platform support pretty much free.

------
cellis
Awesome! One less person i have to compete with!

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

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

------
xirium
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
both Comet and Flash address that issue...

~~~
xirium
I can see the benefit of Comet in this case but I don't see the benefit of
Flash. Please could you explain.

~~~
chaostheory
I thought like Comet, Flash can send data asynchronously. the client doesn't
have to continually poll the server. Am I wrong?

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

------
sammyo
So reimplementing Maya or Photoshop is a bad idea?

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

------
rms
Gmail, anyone?

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

~~~
warwick
Perhaps he used a desktop blogging client.

~~~
curi
still involves a web app.

~~~
kajecounterhack
Not to mention we wouldn't be here talking about this were it not for a webapp
by our friend paul...

------
sabat
Blogga, please.

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

