
Computers Aren’t Fast Anymore (2013) - buremba
http://evincarofautumn.blogspot.com/2013/02/computers-arent-fast-anymore.html
======
Joeri
I say this as a web developer: web apps are worse than native desktop apps in
almost every way. They are slower, less usable, less accessible, less
integrated with other software and they are harder to develop (although
because most web developers never wrote desktop apps they don't realize how
pitiful their tools are).

This is all true (or debatably conceivable), so why are so many apps web apps?
Well, in my opinion, it's this: they are easier to deploy, easier to adopt,
easier to bill, and much harder to pirate. Web apps are worse for end users
and developers, but better for everyone else: the people who sell them, the
people who buy them, the people who deploy them, and basically anyone who
holds purchasing power.

~~~
astrodust
They are "slower" in that actions take longer, mostly because so much data has
to be serialized, encoded, shipped long distances, decoded and deserialized
before rendering, but they're "faster" in that updates happen instantly and
transparently.

Desktop software used to be very quick to respond locally, but updates would
take weeks, months, or even years to get pushed out. Some applications, once
sold, would never, ever get an update. You'd just buy the new version whenever
that came out.

~~~
krschultz
Flip side of that last one, sometimes you would even buy a program, and it
would still work long after the company that wrote it went out of business.
These days, when a company pulls the plug on a web app, you are SOL.

~~~
astrodust
I'd take a software-as-a-service solution that I can replicate the data from
in an open standard format like JSON or XML over a closed-source application
with an impenetrable binary file format any day.

~~~
mwcampbell
That seems like a false dichotomy. There are SaaS applications with no data
export option, and there are closed-source locally installed applications that
use textual data formats (e.g. XML), if only as a matter of convenience for
their developers.

~~~
astrodust
I mean this by way of comparison to applications that were distributed on
floppy such as WordPerfect, dBase, FoxPro and so on, where the data format was
proprietary.

It's only relatively recently that we've seen open-source and open-data
applications. These are arguably better but relatively rare.

------
mcav
We built tools that allow us to create and distribute applications and
information at an incredible pace. The web, and the technologies surrounding
it, emerged quickly, with bitter fights (Netscape v. Microsoft) and competing
standards. Now we pay the price for that speed of innovation.

Fortunately, things are looking up: As the web stabilizes as a platform, and
browser developers have time to pay back their code debt, applications will
respond more quickly. Similarly, we're starting to see better toolkits like
React and Om, which treat the browser more as an application platform and less
like a document viewer.

I wholeheartedly agree with the sentiment behind this post. We developed the
web quickly; as the web stabilizes, so can we step back and optimize the slow
parts. And we are: HTTP 2.0, Servo, WebGL, asm.js, better JavaScript engines,
better rendering engines, and better applications.

The browser isn't inherently a slow layer of abstraction; we just haven't
refined the technology to a point where it's simple to create performant
webpages. I think we're on the right track, but progress is slow when you're
trying to upgrade everyone in the world.

------
aristus
We're still in the middle of a shift. _The_ killer feature of the internet is
that you can give everyone the same version of your software at the same time,
and even give them all _different_ versions (eg A/B test buckets) at will.
That was why we threw out decades of infrastructure and rewrote it all again
in the browser. We're still learning how to make that fast. Windows 2000,
believe it or not, was a kind of apotheosis of desktop programming. By that
time the era was closing.

Maybe we'll go back, but I kind of doubt it.

~~~
snarfy
It sounds like all we really ever needed was a universal package manager that
could auto update your app.

I'd rather a native app speak the network than my network-speaking browser try
to be a native app.

~~~
sp332
You still need to build native versions for every platform your app will ever
run on. If you had that, the package manager would be easy.

~~~
dangerlibrary
That's not so bad - all we need is some kind of consistent abstraction layer
we can target on every platform/OS.

wait.

right.

I see the problem.

~~~
seanflyon
[http://xkcd.com/1367/](http://xkcd.com/1367/)

------
petercooper
_Hello, doctor. I am only 22 years old, but I think computers used to be
faster._

As someone who has been using a computer almost daily since the mid 80s, I
don't relate to this whatsoever. I remember waiting for programs to load for
_minutes_ in the 80s and numerous seconds even in the late 90s. Even fast DOS
apps would hang for seconds to save something to disk.

I remember even early, simple versions of Photoshop taking a minute to load
and then forever to run simple effects.. now it's about 2 seconds to load from
scratch (and then milliseconds once in cache) and almost everything I do in
the app feels instant despite being significantly more complex.

Even software operating way lower down the abstraction tree decades ago felt
and acted slower to me than most JavaScript apps today.. things are only
getting better IMHO, about the only limit on today's app seems to be network
speed which in some cases is not much slower than disk speeds just over a
decade ago..

~~~
_delirium
Some stuff feels faster to me, especially compute-heavy stuff like you mention
(waiting forever for a Photoshop filter to complete while it chews up your RAM
and starts swapping). But quite a few things feel slower, particularly
anything where latency for normal, lightweight interactions is the most
noticeable aspect. For example Gmail feels quite sluggish to me compared to
what I used to use for years, Pegasus Mail, at least for basic operations like
opening a mail, opening a reply window, etc. (Gmail probably does scale to
large number of messages better, and its search is faster). Anything that
involves serious text manipulation in a browser also feels just high-latency
enough to be painful, at least on my connection; I spent much of today writing
in writeLaTeX and the experience was somewhat frustrating.

It's not _unprecedented_ slowness, but a lot of things about webapps remind me
of running remote X apps on an underpowered X terminal connected to a powerful
server: compute-heavy stuff is generally handled nicely, but clicking on
anything at all has a little bit of latency attached to it.

------
JoeAltmaier
So right on everything. Web apps are often unresponsive and temperamental,
only their mother can love them. Mouse responses are idiosyncratic (does it
change to a wait-mouse when waiting for the server? almost never). Pages
change drastically with a simple button press, instead of fluidly updating.
Pages get drawn in pieces so you have to check the status bar or tab to see if
they're done yet.

Any of these problems in a game for instance would keep it from releasing -
Quality Assurance would never pass it! Yet web apps are given a pass on
anything. Why? Because there's no simple way to fix them - the tools are too
far from the behavior on-screen. You're not in control of your mouse, or your
widget behaviors, or your server responsiveness.

------
Pxtl
It is utterly _stunning_ how badly Sun screwed the pooch with Java.

Java could have won the web-app war, with a little more foresight. But a
terrible GUI framework, terrible updater, terrible deployment, etc. killed it.

They knew exactly what they needed to make back when the idea of web-apps was
still nascent - you can see the scaffolds laid in the history of Java. A zero-
installation platform for cross-platform GUI apps.

But they just made so many painful errors that their platform was unusable.

~~~
bluedino
Java got such a bad a reputation when it came out for slowness. And it was
rightly deserved. The VM took forever to start up, especially on a consumer
machine. Download speeds were still too slow. Performance was just terrible
from start to finish.

~~~
blt
To be fair, executing today's Javascript web apps on that hardware would be
much worse.

~~~
frik
That's not true. GMail was always JS heavy and run fine back in IE 6 and
Firebird 0.7 (now Firefox) in 2004/05.

Where as the Java 1.4 consumed too much memory and every now and then a lot of
CPU cycles for its garbage collection cycle. 512MB RAM memory was the minimum
for Java VM to execute a single Java app and consuming almost all memory
resources.

------
mwcampbell
The problem of software feeling slow even though hardware gets faster is not
limited to web applications. Wirth's law
([http://en.wikipedia.org/wiki/Wirth%27s_law](http://en.wikipedia.org/wiki/Wirth%27s_law))
precedes the widespread use of the Web as an application platform. Also,
Stanislav Datskovskiy's rant "Going Nowhere Really Fast" ([http://www.loper-
os.org/?p=300](http://www.loper-os.org/?p=300)) doesn't even mention the
browser. So the web stack is not the root of the problem.

~~~
hsitz
Yes, web layer right now just happens to be the one people notice slowing
things down.

Go back to early 90's and you will find lots of complaints about how moving to
Windows and GUI was backwards step from character-mode DOS because of the
extra layers Windows added, the sluggish UI response, general slowness of
Windows apps, and increased complexity and difficulty of developing for
Windows. Of course, despite this, there were lots of obvious advantages of
moving to Windows from DOS. Eventually the slowdown added by Windows
abstractions became pretty much a non-issue, shortly before the move to web
development gained critical mass and started the cycle all over again.

------
chillingeffect
No one is pointing out that software today is _doing_ more. Did any apps in
the old days run spellchequers _constantly_ in _every_ window? No. Did apps in
the old days automatically gentle, genevieve, generate typeahead suggestions
in nearly every window? No. Did apps in the old days check for new versions on
startup and in the background? No. (well okay one or two of them did).

I'm a cranky EE with a background in routers and even I don't blame "teh web"
for making apps clunky. It's just that we're doing more, more colors, more
background stuff, more compositing, more buttons on GUIs, more simultaneous
file formats - it used to be every program had approximately ONE file format
it supported, maybe two. What about running with many different library
stacks/APIs underneath? All that shit takes time and memory.

And we _are_ in a transitional period. We're maximalists with respect to
amount of features and compatibility we cram into every app (and platform),
but maybe soon hopefully eventually evolution will cool a bit and things will
start to run as tightly again as Deluxe Paint III on the Amiga 500.

~~~
mobiuscog
They may be doing more, but they're not solving more problems or adding much
more value or productivity.

Most new 'apps' just re-brand the wheel and make it more 'fashionable'.

I used to blame the web, but know the same 'push software out to make monies
fast' mentality is even hitting desktop software which is far more bug-ridden.

Software engineering is largely dead. We're in a world of throwing apps at the
wall to see what generates money as quick as possible and move on to the next
thing.

The web (and mobile devices) will kill personal computing as it alllows
corporations to take all of the control away. Sure, you can customise your UI,
but it's already been dumbed down.

It's evolution I suppose. I don't have to like it.

------
jseliger
_I write this very psychiatric confessional blog post within a WYSIWYG editor
running inside a web browser. (Sorry, doctor, but you’re just a figment of my
overactive rhetorical imagination.) In the browser lies the problem. Almost
all of the erstwhile proper applications that I use on a daily basis are now
web applications._

Interestingly enough, this is one reason I still write blog posts in Textmate
and longer documents in Word (laugh all you want, but Word for OS X on an SSD
is actually very fast). I still use Mail.app, which is very fast for
composition and searchable even offline. I'm running 10.6 instead of 10.9 or
10.10 (can't remember the latest number; allegedly the most recent versions
are slow on the hardware I'm using
([http://jseliger.wordpress.com/2011/07/20/mac-os-10-7-is-
out-...](http://jseliger.wordpress.com/2011/07/20/mac-os-10-7-is-out-today-
and-i-dont-care-because-in-the-beginning-was-the-command-line/\))).

Many things can still be done on fast hardware. Most people choose not to do
them, however. Do users drive developers or do developers drive users?

------
TehCorwiz
I remember a time when Java tried to be the alternative to native
applications. When the power of Java was the byte-code that promised write-
once run-anywhere. This was about the time the web was becoming big and I
guess in battle between html+js & java...well, java lost. I wish someone was
still pursuing that dream though. Oh, wait, Unity.

In any case the browser is intrinsically easier to operate than a package
manager. I mean really, it can go from displaying a simple static content site
with no formatting or CSS all the way to impressively complex web-apps like
Google Docs. Not to mention the work of Three.js and the WebGL community. And
all I have to provide is a single well-formatted string of no more than 2,083
characters.

------
menacingly
Rants that boil down to implementation concerns always come across as whiny.
Web apps aren't fundamentally slow, we're just ironing out the details of this
free, basically ubiquitous, basically compatible platform that no one is
forcing you to use.

~~~
pessimizer
>Web apps aren't fundamentally slow

Computers aren't fundamentally slow, either. The point is that they are slow
in practice.

------
ef4
We're actually undergoing massive and dramatic improvements in the tooling,
speed, and capabilities of web apps. Even the gap between now and two years
ago is startling.

If you haven't given any of the newest tools a spin, you may not have noticed
yet. For me, we crossed a tipping point in the past several months where an
environment like Ember (with ember-cli as the toolchain) is actually nicer in
every way than writing a more traditional server-rendered app backed by Rails
or equivalent. And I say that as someone who suffered through the early days
when there were serious growing pains as the whole ecosystem matured.

Now, the experience for both developer and end-user is a major improvement. It
makes you appreciate how crazy and convoluted traditional web application are,
given the way they need to thread state across pages. Rails is a testament to
how far you can go despite those crazy constraints. But once those constraints
are gone and you're writing a real, persistent client that's only loosely
coupled with the server, you achieve a new clarity.

Up until very recently, the tooling all sucked hard, and so the net benefit
wasn't very compelling. That has changed, and even if you're still not
impressed just give it another year, because the improvements are still coming
fast.

------
jgable
I completely understand the author's point, but I always find myself annoyed
at these kinds of posts. Maybe it's simply a matter of emphasis. Yes, we have
backtracked in so many ways from the speed and functionality of native
applications. However, I'd prefer to accept that the web will be the dominant
programming platform from now on, and use the capabilities that we had with
native applications as inspiration to make the web stack better. Yes, It can
be annoying to hear people breathlessly describe the responsiveness of some
new javascript framework as if it's something that native apps haven't had for
ages. However, I don't think that should make us want to go back. We need to
work hard to bring that speed and functionality to the web while taking
advantage of the unbelievable capabilities that the web offers that we didn't
have before.

Besides, the browser as a user interface is only going to last a little while
longer. Have you used Janus VR [1]? Have you used it with an oculus rift? It
is crude. The graphics are simplistic. But it is AMAZING. It represents the
future. The metaverse is almost here, and this is a very exciting time.

[1] [http://janusvr.com/](http://janusvr.com/)

------
cshung
The problem of web app being in general less responsive than desktop app is
just one of the many instances of unifying abstraction lowering things down.

We witnessed that with virtual machine, the industry invented multiple OS, and
turn out we need to be able to run different apps on different OS at the same
time and we invent (process) virtual machine to bridge the gap like Java
Virtual Machine, or even VMWare or Hyper-V.

And then we have different databases, and then we have different data access
abstraction layer out of it making it hard to use the best bit for each
database vendors.

And then we invent phones, and have different types of phones, and then again
we re-invent phonegap to unify the different phones, and paid the price for
that.

Who knows what's next - the history is simply going to repeat itself, we
create variations, and then we create performance losing unifying
abstractions...

And such trend seems to be in this industry only, you never see someone build
different building and then find a way to generalize building and make worse
master building out of them.

Just knowing such a trend is rather useless, there is nothing we can do to
stop that either. As long as there are multiple big vendors around that just
won't stop.

------
programminggeek
The browser is the common client app runtime that the JVM/Swing platform
always wanted to be.

Native will always feel better, but the browser gives us a way to express
cross platform designs much better/faster/cheaper than most native toolkits
do, and far better than any cross platform toolkit that I've seen.

The tradeoff is performance in a big way.

Think of it this way, it's like the web is like OnLive or Galaki streaming to
play a game and native is like playing a game on your local device. Streaming
game performance is inherently worse, but at some point might be good
enough/great for most people such that the investment in native games on local
hardware no longer makes sense for certain games.

I think most people don't realize or think through the fact that they are
making that performance tradeoff in exchange for other things.

Maybe people should have that discussion.

------
rheide
It's partly, or even mostly, a problem of trust. Back in the wild days of the
internet you just couldn't trust a website to have a lot of control over your
computer. You could argue that this is no longer the case since we're slowly
building up the 'web of trust', but I think we're not quite there yet. Since
there used to be less facilities to write speedy online software (secure
offline storage, closer-to-the-metal 3D APIs) people were stuck with the old
HTML+Javascript and never really evolved out of it. It's not the right way to
go, but it's a necessary step to develop the infrastructure that'll be
necessary for the next big leap.

------
frandroid
My big pet peeve is that many mobile apps don't keep any local data; every
time you load up the app is like an ST:TNG episode reset, as if nothing
happened before. Save the data locally, serve that to me when I load up the
app, and only once you've done that, check out the backend to see if the data
needs to be refreshed. Even though most apps have many clients/endpoints
nowadays, most users still access them from only one end-point, so load data
locally first makes things much faster. The same can be done with web apps and
localStorage.

~~~
krschultz
It takes a lot of work to get that right, but I agree with you it is essential
to making a quality mobile app.

------
protonfish
Most of the apps that run on my android phone are some of the most clunky and
unresponsive applications I have ever had the displeasure to use, so I don't
think you can place this blame on web apps.

Still, grumpy old non-web developers love to blame their favorite whipping-
boy. If pretending that web dev is an inherently poor quality technology makes
you feel better, please carry on. Whatever gets you through your day, man.
Just please don't start thinking your thoughts are clever or constructive.

~~~
clarry
So who or what is to blame then?

If web applications run like shit and give me a poor user experience compared
to native software? I can't blame anyone or anything? Is the web so perfect
despite all its flaws?

Oh sure, there is poorly performing "native" software out there too. But in my
experience, pretty much all web software performs poorly.

~~~
mattgreenrocks
What irritates me about this "soon it will be great" attitude is the utter
passivity implied. We are supposed to _wait_ for the Great Browser Makers to
bestow upon us:

* performance

* decent tooling

* native capabilities

This has all happened before with Swing, and will all happen again. You won't
understand or empathize with comment until you've had your chain jerked around
enough in the past. You probably feel like the pace of progress is so fast and
furious that _soon_ we'll fix all these problems. You might feel that the Web
is the ultimate platform that cannot be upstaged ever. Except it will, and it
might require a new medium, but it will. All platforms are transient.

In a way, I can't be too mad at the Web because it made me realize I want
nothing to do with consumer-grade tech. That side of the industry seems to
revel in half-solutions and commoditizing developers.

~~~
clarry
> In a way, I can't be too mad at the Web because it made me realize I want
> nothing to do with consumer-grade tech. That side of the industry seems to
> revel in half-solutions and commoditizing developers.

I had a somewhat similar realization. Actually it made me drop out of high
school and completely forget about going for comp-sci and a career in IT.
Working in IT is still a possibility but if I do it, I will do it on my own
terms (or at least in very good company). In the meanwhile, I'll keep
programming as a dear hobby so I can focus on what I think is good and right.

------
acd
I think it misses the point that we use thousands of computers everyday that
we connect to through the internet. So although the CPU in your mobile phone
is not that fast the search engine it talks is very very fast. So if you take
into account the network effect then things have speeded up a lot.

------
spindritf
It's not just web apps.

I sometimes switch to tty, and am always surprised how responsive it is
compared to my gnome-terminal which never feels slow on its own. In the tty
characters seem to appear before I even fully press the key.

------
cshung
Another fun thing to do is to use old software on new box, they are now
amazingly fast. We can use old text editor, or word, or even Windows XP.

------
mmagin
The horrible thing is that the pain of user interface latency never gets any
respect, and everything either has: 1. network latency (the "cloud"!), 2.
stupid GPU eye-candy, or 3. plain-old bad design (everyone should read
_Programming Pearls_ and the sequel sometime.)

------
bluedino
>> We programmed on them in VB6. And let me tell you, for all its downsides,
VB6 was screaming fast.

>> These crappy amateur applications were downright speedy.

Compared to what? Visual Basic performance was a joke, even when you compiled
it to native code.

~~~
mattgreenrocks
This is about user perception of performance: startup time, UI responsiveness,
etc. Not raw CPU speed. It did fine on all those counts, even if you'd never
let VB do your DSP work for you.

~~~
mwcampbell
On this topic, Chad Austin's essay "Logic vs. Array Processing" was quite
illuminating for me.

[http://chadaustin.me/2009/02/logic-vs-array-
processing/](http://chadaustin.me/2009/02/logic-vs-array-processing/)

Granted, the platform surrounding VB6 arguably had too much hairy logic
related to COM and ActiveX, and the fragile system that existed for
registering such components before Windows XP introduced side-by-side
assemblies. If you really want to pine for the old days, consider Delphi,
where you could compile everything into one executable; just map that hunk of
code into memory and go.

------
nash11
It's just the trust you have for the doctor to invent a pill for every problem
you face. But sadly that's not the case anymore nor in real human life and
neither in the world of technology.

