Return of the Stateful Client

We used to write thick clients, fat happy Swing apps that executed application logic and business logic on the user’s computer, and connected to the server mostly for data access. Then we moved toward service-oriented architecture and the thin, browser-based client. This solved all our deployment problems, and it moved the business logic back to the server.

Now that browsers are more powerful, more of the application logic is moving back into the front end. Instead of calling the client “thick,” we now call it “rich.” Where is this going? Toward stateful, browser-based apps. Forget maintaining a session on the server — store all the state in JavaScript.

Think about apps that run in a browser, but aren’t dependent on constant network access.

Now think about developing these apps. Think about reloading to bring in a JavaScript or CSS change… and starting over. With all the state in the JavaScript, reloading a page means restarting the app. More than that: reinstalling the app. That’s harder than reloading one thin page to see changes, or running that Swing app from your IDE. So what’s to be done?

Bring the IDE into the browser. With even more JavaScript, dynamically reload pieces of the application.

Last night at STLJS, Bill Edley from Technical Pursuits Inc. demonstrated his TIBET library, which makes the browser into the IDE. Change your application while it’s running. Type commands in the little in-app REPL. The library also handles asynchronously getting data back to the server, abstracting temporary disconnections (motto: “There is no server, there is no server, there is no server”). It provides a richer OO framework for JavaScript as well.
What’s the negative? 3 megabytes. yikes! and it’s not out yet, so you can’t play with it.

But hey, the thick rich client is back, still functional when the server is unavailable, and it is integrated into the IDE (Smalltalk lives!). Just think, no session data on the server — that smells like freedom. We’re bringing the code to the data again, where this time the data is user input. This bodes well for responsiveness.