I have been spending a fair bit of time recently thinking about web-apps, what the difference is to a website, and how one should be designed.
The concept of web applications are not new. When I started in the business in 2000, it said "Application Designer" on my business card. As soon as you could start having web pages be something else than static HTML, people started coming up with neat things to do with them.
At the moment, the hip thing to do seems to be single page applications, and using RESTful backends. There is nothing wrong with that, I find it pretty interesting myself, but there seems to be a slight tendency to make everything fit into this mould, and just using it for the sake of using it. If all your doing is a website that is doing rest calls to fetch every page when you open it, you should perhaps ask yourself what the point is.
Lately there has started to exist this divide between the "Application" and the "App". The "App" is most often a mobile application that usually have a specific purpose. Watching YouTube, navigating to somewhere or calculating something. It's supposed to have one or a few things that it does well, and be fairly self contained. This is a Good Thing™. Web pages, or web applications are usually the opposite. They are large things, that have a lot of information and functionality crammed into it. The are usually really hard to navigate and find things in. And they do a lot of things. Sometimes there is a need for this, everything can't be simplified down to the bare minimum without losing a large part of what makes it useful.
Now, there is a lot of new interesting technology to build web stuff in. As someone who have designed web application during the time when all that was around was HTML4 without CSS, I must say that HTML5 and CSS3 is making me feel really warm and fuzzy inside. It's more or less everything I spend 10 years waiting for. And if you are building "Apps" for the web, the stuff you can do nowadays is so, so nice.
This brings me to the main point of this post. When building an "App" for the web, or even just some extra functionality for a site, perhaps the biggest challenge is figuring out what technology should be used and how it should be designed. One thing that usually surprises me is, if you use a RESTful backend, how often people tend to make calls to it. My philosophy is that memory is cheap, bandwidth is cheap, but latency is not. This is especially true for mobile. The users action should as infrequently as possible trigger a network request that the user must then wait for a reply on. There are of course times when you have to balance this. Consider an auto complete function for an input box, say a register of user names. If that register only contains a few hundred names, the smart thing is probably to pre fetch all of them. 1kB of data doesn't take long to fetch even over mobile, and is not a problem to keep them all in memory. And the user experience is so much better when to field can start suggesting names right away. This is of course no longer practical for a register with 100 000 names, there the data should be fetched based on what the user has typed thus far. But even then, there is no need to fetch the dataset again, unless the base criteria for the fetch changes.
What I'm getting at is that modern browsers have a lot of capability to store data locally, and you can process that data really fast. If you are intent on writing a single page application, remember that there is no need to tie the users actions or the page renders to backend calls. And I would even go so far as to say that if you're doing it that way, you are probably doing it wrong. There is no need to emulate the way you do stuff in classic server side web applications.
As usually, this became a bit more incoherent than I had intended, but perhaps someone finds it interesting. I was planning on writing about the whole "Webapps as native" thing as well, but that probably deserves a post of it's own.