Hacker News new | past | comments | ask | show | jobs | submit login

Maybe I'm conflating several of my issues with webapps in the word "toy". One thing is ergonomics, bloat and lag issues. But the other thing is that webapps trying to fill in the role that originally belonged to desktop apps are more often than not pretty dumbed down. There are several reasons for that - one is performance, which makes you unable to add more complex features without making the entire webapp unbearably slow. Another is the business approach of sticking to MVPs and not really progressing beyond them.

Also, lag issues are not really limited to high-end graphics / video editing. Sure, lag/low performance makes those tasks basically not doable in the browser. But even "ordinary" webapps - like word processors or issue trackers - are annoyingly slow. Take Jira for example - I'm probably wasting a few (billable) hours every month just because it's not a desktop app. So are all of my co-workers. It's most likely also the reason people tend to batch time reporting and do it once a week or so (it's much less distracting then), which as a result precludes management from having access to up-to-date information about time spent on tasks.

Trivial inconveniences can have non-obvious impact.




> Take Jira for example - I'm probably wasting a few (billable) hours every month just because it's not a desktop app.

I think you'll find that Desktop apps often have to communicate with with centralized servers as well.


I definitely get what is being said here about web apps feeling slower. I've personally found desktop apps to in general be more responsive / quicker than web apps, and I think it's more than the communication layer. (Actually, I think REST is far more responsive than some of the previous middle tier communication methods used by desktop apps...).

From what I've heard (no in depth knowledge so I welcome corrections), the DOM / CSS model itself really wasn't designed for fast, responsive applications and thus tends to under-perform in that department. So even a fully internal network app with comparable communication speed may seem slower on the browser from the get go.

Many web apps often also tend to be a little bit laggy just based on their cloud based nature. Load a random spreadsheet on Google docs, and you are probably talking 100-200 requests and (depending on your network) perhaps a 5-7 second delay. Change a tab, and you probably have another 2-4 second delay. Compared to the 1 second load time of a spreadsheet and nearly instantaneous tab switching time on a native spreadsheet app, it feels slower... especially for the power users, I'm sure...


Communication overhead (which could be reduced with some additional caching client-side) is not the only source of the lag. User interface is a problem too. Sure, with enough work you may be able to overcome the problem in this (and similar) cases - but web apps are usually developed around a particular style, which involves AJAXing around way too much data way too often.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: