Written November 27, 2007 in webdev

I’m helping the developers of a web-based game, SpaceHamsters, restructure and rewrite their codebase to make it work with the web. They had tons of experience writing desktop applications, but none writing webapps… there are some remarkably different basic concepts between them, especially when working with a language that can do both like the .net framework. I wrote a series of articles to help them figure out what they needed to do and to explain to the game community, which I’m hosting at http://shblog.katzke.net, what went wrong and what’s going to happen next. If you are interested in game development, check out the dev blog on that site — there’s a ton of good information.

In real life, I’ve been a web developer for the past seven years or so. That’s why Scavenger and the team called upon myself and Xhamulnagul to help out — we’ve both got gobs of experience with playing games and developing web applications.

I’m also a huge fan of education. By education I mean telling people how things work, even if they think it’s above their heads, so that they understand what’s going on and can help guide everyone else when they see a problem. An educated community is a smart community. I’m going to make a series of posts that will get kinda technical and don’t pertain directly to the game, but do pertain to technology and web applications and games on the web in general. A lot of these posts came directly from conversations among Spacehamster’s developer group. I promise that I will not use any acronyms or real techie speak in these posts … at least without explaining what it means in honest english.

The fundamental problem with Spacehamsters during the beta is the reason that a lot of web application developers who started out in the commercial software world will fail their first time out: Developing for the web is fundamentally different than developing a computer application for a desktop or server computer.

In a desktop application, the program runs in a ‘loop’. A loop is a process that runs over and over again until it’s told to stop. In your typical program, inside the loop are switches and settings that the user changes and the loop processes to do things. The loop always runs, and is always watching for the user to change something so that it can do something else.

In a web application, the loop is ’synchronous’ — that means that the user sends a request, which starts ONE iteration of the loop, and the response heads back out to the user. In between, other users are triggering loops of their own, which then need to be written to a central storage area (Typically a database of some sort) so that other users can see what happens.

This model, with it’s synchronous single-iteration loop and only one source of events, is tough for some software developers to understand. Software developers that are used to programming regular computer applications typically depend on keeping most processing in application memory, and only talking to the database when it’s absolutely necessary. This is exactly right if you’re programming a client-server application; you only want to contact the root database when someone else triggers something that other users need to know about. What many developers who are used to coding client/server desktop applications mess up on is that the user’s *browser* is the client, not the application running on the web server… and the applications that build web pages aren’t made to retain that much information in memory or to do that kind of ‘loop’ processing — they’re used to handling a user’s request from a browser as a single iteration of a loop.

Of course, there’s plenty of ways around that problem. Next time, I’ll talk about handling events that happen when a user’s not online. After that, I’m planning on covering ways to ‘break’ the synchronous loop model, but still stay within the capabilities of web servers and browsers.


Related:

Yes, those are amazon links. Why? Bandwidth’s expensive, this article’s getting a lot of reads, and yet I don’t feel I’m worth a tip jar. I selected some books that are related to the article. Thanks for clicking!

No comments on ' Web Applications and Why They’re Difficult '

  1. No comments yet.

Leave a comment

name (req'd)

email (req'd)

website