7 ms·

Computers Aren’t Fast Anymore (2013)

97 points by buremba 12y ago

JoeAltmaier 12y ago
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.
aristus 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
      - tormeh 12y ago
        Like the back-end of a compiler? JVM or LLVM?
      - seanflyon 12y ago
        http://xkcd.com/1367/ http://xkcd.com/1367/
      - danieldk 12y ago
        That's not so bad - all we need is some kind of consistent abstraction layer we can target on every platform/OS. Qt works fine for me!
    - tormeh 12y ago
      Or you could use JVM apps. Distributing LLVM intermediate representation code and doing the final compile on end hardware could also work. Building native versions on the developing end is a foolish idea not suitable for programs in general, and it is time we abandoned the approach. It made sense at the time, but much time has passed since then. Some software might benefit from the increased obfuscation, but other than that it's just shit.
      - sp332 12y ago
        LLVM helps, but it's not nearly enough. You need a standard library including network and GUI at least. (Edit: or statically-compile everything.) Java probably would have worked, but as I recall, Microsoft killed it.
        tormeh 12y ago
        Yes, that's true, it can't be done tomorrow, but I think it's the right approach. I'm not very familiar with Qt, but turning the more essential parts of it into a part of a LLVM standard library shouldn't take that many years, should it? And don't most standard libraries have networking now? I'm curious how Microsoft killed Java. I assume you mean Java on the desktop?
  - clarry 12y ago
    I'd rather have good software that just works. Don't fix it if it's not broken. Updates.. what are they? If it's not broken, it doesn't need updates. If it's broken, I probably won't be using it in the first place. Test before you release. Don't outsource testing to your users. Just like in the 90s... Web developers might think what they get to do is fun, but as a user the idea that software I use is going to change overnight without my permission is crazy. I shy away from web software. (Also, all of it tends to run far too slow on my system anyway)
  - derefr 12y ago
    You also need the sandboxing and zero-install properties of web software, though. Imagine if, say, we had a docker:// URL scheme, where you could click a link and it'd stream you a container image that would then start an ephemeral instance of itself with a linked persistent data container, taking the rest of the URL as its command line.
  - superuser2 12y ago
    ... and for everyone to be on the same OS configured the same way. Which, given current business climate, is non-negotiably Windows.
  - shaurz 12y ago
    We could have stub apps that download the latest code from the web (or use a locally cached copy), compile it for the local machine and pop up a native GUI. The local app could communicate with a server in the same way JavaScript client code does now. No need for the web browser. It just needs to be made easy and truly cross-platform and nobody has written the infrastructure and programming languages needed to support this in a sane, manageable and unified way (yet).
  - Detrus 12y ago
    We also needed tighter security for running untrusted code. And a way to run small snippets of code quickly. Tight security can be solved by some sort of sandboxing that takes a performance hit and a web of trust. Computers that ran the program can confirm that it is not malicious. Then an app can be run without a performance hit. This is the model of Apple's app store more or less. Except it's not a web of trust but a centralized authority and there is no way to run untrusted code. And it makes a lot of sense. Most apps that are worth using will be used often, no reason they should take a constant performance hit after trust has been established.
- Zigurd 12y ago
  We are in the process of "going back." Mobile devices are designed to host a new generation of apps. The Web is great for expedient universal access, but it won't be a universal multi implementation runtime that works better than platform native runtimes. The Web is a pre-touch legacy platform as much as Windows. Take any tablet and try using it as a touch Web device without using native apps to get a feeling for the scope of the problem.
mcav 12y ago
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.
protonfish 12y ago
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.
- frandroid 12y ago
  Many of your Android apps are web apps that have been further wrapped into a Cordova wrapper :)
- clarry 12y ago
  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 12y ago
    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.
    - 12y ago
Joeri 12y ago
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.
- vlunkr 12y ago
  One advantage of web apps is that they don't require an installation process. It's easier to convince someone to use your software if all they have to do is visit a link. But as the author said, your code is now running at a layer far from the hardware.
  - seanflyon 12y ago
    And running in a sandbox, they are (mostly) unable to harm the users computer, which is big part of why it's easier to convince someone to use it.
- astrodust 12y ago
  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.
  - agmcleod 12y ago
    I think you're right, and I like web applications and think they are a good avenue. However, looking at mobile apps and how updates work there, it is a nice middle ground. No doubt it's more essential as we're talking about phones, not desktops. But I think this sort of computing has come back in some ways.
rheide 12y ago
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.
nash11 12y ago
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.
TehCorwiz 12y ago
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.
Pxtl 12y ago
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 12y ago
  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 12y ago
    To be fair, executing today's Javascript web apps on that hardware would be much worse.
    - frik 12y ago
      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.
  - Pxtl 12y ago
    They kept saying "it runs fast" which completely missed the point. The GUI toolkit was painfully slow, as was the JVM start-up. If they'd compromised on run-time performance in exchange for fast start-up and they'd re-thought the terrible GUI, it could have worked.
- smadge 12y ago
  "web-app war" threw me off for a second, because the file type for java server applications is .war for Web Application aRchive.
frandroid 12y ago
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 12y ago
  It takes a lot of work to get that right, but I agree with you it is essential to making a quality mobile app.
bluedino 12y ago
>> 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 12y ago
  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 12y ago
    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.
- makeset 12y ago
  You wouldn't crunch numbers with it, but it was responsive and fast enough for most purposes, and had simple interfaces to faster native libraries for a lot of the rest.
- Shorel 12y ago
  It was much faster than python. smirk
mwcampbell 12y ago
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 12y ago
  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.
menacingly 12y ago
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 12y ago
  >Web apps aren't fundamentally slow Computers aren't fundamentally slow, either. The point is that they are slow in practice.
jseliger 12y ago
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-today-and-i-dont-care-because-in-the-beginning-was-the-command-line/) http://jseliger.wordpress.com/2011/07/20/mac-os-10-7-is-out-...). 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?
petercooper 12y ago
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..
- SixSigma 12y ago
  Hang on, I just need to load my browser from this C60 cassette tape.
- sliverstorm 12y ago
  I agree that everything has gotten faster than 30, 20, or even 10 years ago. But I am a little annoyed in the past year or two that web pages seem to have gotten slower. I suspect with the explosion in large complicated web pages, rendering overhead outpaced hardware development for a couple years.
- _delirium 12y ago
  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.
jgable 12y ago
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/
spindritf 12y ago
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.
ef4 12y ago
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.
acd 12y ago
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.
mmagin 12y ago
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.)
chillingeffect 12y ago
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 12y ago
  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.
programminggeek 12y ago
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.
cshung 12y ago
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.
cshung 12y ago
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.

97 points by buremba 12y ago

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.

aristus 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.
    - tormeh 12y ago
      Like the back-end of a compiler? JVM or LLVM?
    - seanflyon 12y ago
      http://xkcd.com/1367/ http://xkcd.com/1367/
    - danieldk 12y ago
      That's not so bad - all we need is some kind of consistent abstraction layer we can target on every platform/OS. Qt works fine for me!
  - tormeh 12y ago
    Or you could use JVM apps. Distributing LLVM intermediate representation code and doing the final compile on end hardware could also work. Building native versions on the developing end is a foolish idea not suitable for programs in general, and it is time we abandoned the approach. It made sense at the time, but much time has passed since then. Some software might benefit from the increased obfuscation, but other than that it's just shit.
    - sp332 12y ago
      LLVM helps, but it's not nearly enough. You need a standard library including network and GUI at least. (Edit: or statically-compile everything.) Java probably would have worked, but as I recall, Microsoft killed it.
      - tormeh 12y ago
        Yes, that's true, it can't be done tomorrow, but I think it's the right approach. I'm not very familiar with Qt, but turning the more essential parts of it into a part of a LLVM standard library shouldn't take that many years, should it? And don't most standard libraries have networking now? I'm curious how Microsoft killed Java. I assume you mean Java on the desktop?
- clarry 12y ago
  I'd rather have good software that just works. Don't fix it if it's not broken. Updates.. what are they? If it's not broken, it doesn't need updates. If it's broken, I probably won't be using it in the first place. Test before you release. Don't outsource testing to your users. Just like in the 90s... Web developers might think what they get to do is fun, but as a user the idea that software I use is going to change overnight without my permission is crazy. I shy away from web software. (Also, all of it tends to run far too slow on my system anyway)
- derefr 12y ago
  You also need the sandboxing and zero-install properties of web software, though. Imagine if, say, we had a docker:// URL scheme, where you could click a link and it'd stream you a container image that would then start an ephemeral instance of itself with a linked persistent data container, taking the rest of the URL as its command line.
- superuser2 12y ago
  ... and for everyone to be on the same OS configured the same way. Which, given current business climate, is non-negotiably Windows.
- shaurz 12y ago
  We could have stub apps that download the latest code from the web (or use a locally cached copy), compile it for the local machine and pop up a native GUI. The local app could communicate with a server in the same way JavaScript client code does now. No need for the web browser. It just needs to be made easy and truly cross-platform and nobody has written the infrastructure and programming languages needed to support this in a sane, manageable and unified way (yet).
- Detrus 12y ago
  We also needed tighter security for running untrusted code. And a way to run small snippets of code quickly. Tight security can be solved by some sort of sandboxing that takes a performance hit and a web of trust. Computers that ran the program can confirm that it is not malicious. Then an app can be run without a performance hit. This is the model of Apple's app store more or less. Except it's not a web of trust but a centralized authority and there is no way to run untrusted code. And it makes a lot of sense. Most apps that are worth using will be used often, no reason they should take a constant performance hit after trust has been established.
Zigurd 12y ago
We are in the process of "going back." Mobile devices are designed to host a new generation of apps. The Web is great for expedient universal access, but it won't be a universal multi implementation runtime that works better than platform native runtimes. The Web is a pre-touch legacy platform as much as Windows. Take any tablet and try using it as a touch Web device without using native apps to get a feeling for the scope of the problem.

mcav 12y ago

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.

protonfish 12y ago

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.

frandroid 12y ago
Many of your Android apps are web apps that have been further wrapped into a Cordova wrapper :)
clarry 12y ago
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 12y ago
  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.
  - 12y ago

Joeri 12y ago

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.

vlunkr 12y ago
One advantage of web apps is that they don't require an installation process. It's easier to convince someone to use your software if all they have to do is visit a link. But as the author said, your code is now running at a layer far from the hardware.
- seanflyon 12y ago
  And running in a sandbox, they are (mostly) unable to harm the users computer, which is big part of why it's easier to convince someone to use it.
astrodust 12y ago
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.
- agmcleod 12y ago
  I think you're right, and I like web applications and think they are a good avenue. However, looking at mobile apps and how updates work there, it is a nice middle ground. No doubt it's more essential as we're talking about phones, not desktops. But I think this sort of computing has come back in some ways.

rheide 12y ago

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.

nash11 12y ago

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.

TehCorwiz 12y ago

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.

Pxtl 12y ago

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 12y ago
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 12y ago
  To be fair, executing today's Javascript web apps on that hardware would be much worse.
  - frik 12y ago
    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.
- Pxtl 12y ago
  They kept saying "it runs fast" which completely missed the point. The GUI toolkit was painfully slow, as was the JVM start-up. If they'd compromised on run-time performance in exchange for fast start-up and they'd re-thought the terrible GUI, it could have worked.
smadge 12y ago
"web-app war" threw me off for a second, because the file type for java server applications is .war for Web Application aRchive.

frandroid 12y ago

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 12y ago
It takes a lot of work to get that right, but I agree with you it is essential to making a quality mobile app.

bluedino 12y ago

>> 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 12y ago
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 12y ago
  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.
makeset 12y ago
You wouldn't crunch numbers with it, but it was responsive and fast enough for most purposes, and had simple interfaces to faster native libraries for a lot of the rest.
Shorel 12y ago
It was much faster than python. smirk

mwcampbell 12y ago

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 12y ago
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.

menacingly 12y ago

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 12y ago
>Web apps aren't fundamentally slow Computers aren't fundamentally slow, either. The point is that they are slow in practice.

jseliger 12y ago

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-today-and-i-dont-care-because-in-the-beginning-was-the-command-line/) http://jseliger.wordpress.com/2011/07/20/mac-os-10-7-is-out-...). 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?

petercooper 12y ago

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

SixSigma 12y ago
Hang on, I just need to load my browser from this C60 cassette tape.
sliverstorm 12y ago
I agree that everything has gotten faster than 30, 20, or even 10 years ago. But I am a little annoyed in the past year or two that web pages seem to have gotten slower. I suspect with the explosion in large complicated web pages, rendering overhead outpaced hardware development for a couple years.
_delirium 12y ago
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.

jgable 12y ago

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/

spindritf 12y ago

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.

ef4 12y ago

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.

acd 12y ago

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.

mmagin 12y ago

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

chillingeffect 12y ago

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 12y ago
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.

programminggeek 12y ago

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.

cshung 12y ago

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.

cshung 12y ago

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.