There is currently a huge disconnect between the needs of Web applications and the frameworks that support them. Admittedly, we have come a long, long way from the days of CGI, but we still have a long way to go. I am not quite ready to say that we need a new language aimed at Web development.

I think that the problems are not any more language specific than any other programming difficulty. But I do think that the current frameworks inadequately address the needs of a developer writing an actual application that has all of the same power and functionality as a client/server application, a mainframe application, or even a basic, disconnected desktop application. For the sake of discussion, I am going to stick with mainstream frameworks — J2EE, ASP.NET, and PHP. (I would love to include Ruby on Rails in this discussion, and maybe some of the readers can help with that, but my knowledge of it is just not high enough to write about it competently, and it definitely is not “mainstream” yet.)

Thread safety within the framework’s shared objects

Point number one is the automatic parallelization of Web code. Whether most Web developers realize it or not, their code always runs the risk of simultaneous execution, even at the individual user level. In other words, imagine if you were writing a desktop application, and every button click, drag/drop action, and so on immediately executed the event handler in a separate thread. It would certainly change how you handle issues like data concurrency, the private variable access within classes, and so on, wouldn’t it? This is exactly what you are facing while writing a Web based application. I am not necessarily saying that Web servers or Web frameworks should serialize all requests (although it would be nice if that was a configurable option, particularly at the user session level). Current Web frameworks pretend to handle this differently, but they rarely do in optimal or configurable ways. For example, the Microsoft ASP.NET documentation has this small blurb on the issue of session states and concurrency:

Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (that is, using the same SessionID value), then the first request received gains exclusive access to the session information and the second request will execute once the first request completes, or until the exclusive lock on the information is freed due to the first request exceeding the lock timeout. If the EnableSessionState page directive is set to ReadOnly, then a request for the read-only session information does not result in an exclusive lock on the session data. Read-only requests for session data may still have to wait for a lock gained by a read-write request for session data to clear.

In other words, the session data locks, but it is essentially an exclusive lock at the call level. The session object in ASP.NET does not support a mode or methods to grant locks for an entire page or section of code. It is up to the developer to do something like wrapping any code that calls the Session object in a critical section to keep that data safe.

PHP takes an entirely different tack. While the documentation does not formally mention the data concurrency challenge (another stellar example of what I mean when I say, “PHP’s documentation is lousy”), a friendly visitor was nice enough to post some revealing information about the issue (see the comments in that documentation). If this user is correct, the use of sessions will lock on a call to the session object, which automatically forces the serial processing of pages; this is not exactly optimal, but at least it is guaranteed safe. The developer is forced to jump through some hoops to do anything else, according to that post.

And finally, the J2EE documentation for the HttpSession object does not mention the topic at all. Way to go, Sun! On a side note, it is interesting that Microsoft, who is traditionally slammed on documentation, discusses the issue better than anyone else does.

The page model

In general, the idea of “pages” in a Web application makes sense, particularly for historic reasons. Sadly, the page model is also rather broken for the purposes of writing an “application.” Users do not call “pages” when using an application — they click buttons, drag items, and so forth. In other words, they are performing data manipulation. AJAX was born out of the need to think about an “application” as an event-driven model in which each user action triggers a discrete piece of code. While I think AJAX is a bad idea as it stands (because of JavaScript issues, exception handling, debugging difficulties, too many HTTP requests, and so on), at least it has the right idea. Without using AJAX, it is nearly impossible to have a Web “application” that acts anywhere near an “application” while still using HTML. Let’s face it, folks, HTML is designed expressly for read-only operations, with only marginal support for data manipulation.

This is where the difficulty with the page model lies. Technologies like ASP.NET’s Web Parts and J2EE’s Faces is a great start. Let the “page” act as a container for these small chunks of functionality. It certainly comes much closer to the component writing and reuse that revolutionized desktop development ages ago. While the current frameworks are addressing this issue, there is still too much of the page model that needs to go, right down to the way the IDEs like Eclipse and Visual Studio conceptualize an “application.” They are still geared for the page model that has proven itself to be poor for “applications.” PHP, with its root so closely intertwined with CGI, lacks these kinds of tools. Instead, a PHP developer who wishes to do something similar fills their code with a lot of includes and such, which creates a complete mess as far as code is concerned.

Client/server interactions

The current “state of the art” is to throw data and a bit of client-side code over the HTTP server’s fence and see what comes back. While this is technically accurate and has the force of historical precedence behind it, it is counterintuitive to an application developer. It is very difficult to seamlessly debug the client-side code and its interaction with server-side code, for example. I have not used Eclipse enough to judge or touched Visual Studio “Orcas,” but I know that I have yet to see a tool that lets me set a breakpoint in JavaScript, step through the code, and land at the beginning of the request for data from the server. The current frameworks simply have not yet institutionalized the client-side code or started to consider it an equal partner. In a desktop application, it is very easy to discover, for example, what user action triggered the event that is being handled. In a Web application, it is impossible. If a search engine follows a form’s destination or if a user follows it, there is no difference. This can cause problems for the user and security risks. I can think of no application in which a user can arbitrarily trigger methods and functions that the visible windows have access to (without some quality developer-type tools and a build that includes debugging symbols, of course), yet this is the exact nature of a Web application. Without much care in the coding, a malicious user can fuzz the application much more easily than they can with a desktop application. This is a direct result of the way current Web development frameworks approach the client/server interaction.

Conclusion

This is really not about desktop apps vs. Web apps, but it also is in a way. Users and product managers are expecting more and more from Web applications. After all, most of us have the idea that Web applications are going to replace all of our client/server and mainframe applications (personally, I don’t buy it). The problem is, the applications that Web apps try to replace have had seamless development models for quite some time now. The functionality capabilities of Web apps are still well below 1990 (if not 1985) levels in the desktop world. If Web apps are going to replace desktop apps, developers need the tools to build them just as good. And I really do not think that any of the current, mainstream frameworks come close.

J.Ja