Abandoned Ship

Made a large decision a week ago. I decided to abandon my 2 1/2 week excursion creating a Single Page Application. For those that aren’t familiar with a single page application, think Gmail on a web browser. Once you open the Gmail web page, you’re on it and you don’t leave it. It feels and behaves like a normal application running on your computer. When you click to open an email, it doesn’t reload the entire page. You can work on an email or two at the same time, while seeing new emails come in. Overall, typically provides a good user experience.

Single Page Applications (SPA) have been around for many years now. They’re probably considered to be the ‘latest hype’ when it comes to web development. In the end, I fell for it. I decided to create an SPA for RTCritical. Figured the worst that could happen is I abandon ship after gaining some additional experience with them using the newer React framework (actually using Re-Frame, a clojurescript framework that wraps the React framework). As it turns out, the max downside is exactly what happened. After a couple weeks, I stopped to reflect. Looked at my progress, analyzed the code I had developed (and I’m pretty meticulous about Clean Code). Realized that while I solved many of the hard issues up front, I still had MANY more features to add to the product, it was breaking browser history and navigation (still had to figure out how to get this working), and the code was so decoupled, thanks to Javascript and event processing, that it was hard to debug, hard to reason with, and unpredictable what would be executed next. And more, it was hard to maintain, and getting harder to extend. And that’s with me usually keeping things clean and well organized.

So after analysis, I decided to go back to the old school route of a Regular Web Application. Each tab you click refreshes the page. Each form you need to use, opens a new page. Certainly not the latest hype. Thought I’d give it a day or two, and see what progress I’d make this route, and then decide whether I should continue on with the SPA, or this new route.

Turned out, it was so much easier to develop the Regular Web App. It was just so simple, I thought I was going back to the basics. When it comes to a complicated world…simplicity has it’s merits!

Took around a day to re-arrange my code base. Created a new project specifically for the web app, where it will be decoupled from the Core backend server. Then, the next day, got in the zone and a full day of programming, had the main tabs/navigation for the site in place, and a data table in place for each tab that was pulling data from the Core Server through it’s API. Thought to myself…man…this was So Much Easier, and Faster! The code was clean. I could easily debug. Life is good. So I continued on this path, thinking the SPA is Out of Here! Trucked for 5 more days, and authentication is hooked up, forms built, additional changes to the backend Core Server’s API was made for more complex queries necessary for the Web App, and I have a half complete web app. Another 5 days on just the UI, and the web app will most likely be complete. The more features I add, the more I refactor commonality out of the code (into my own library/utilities), the simpler my code gets. Reflecting on performance, it’s outstanding! I love working with Lisp and macros for html generation. It gets compiled down, so at runtime, it simply concatenates a bunch of strings, with data from the database in between. Without database queries, from start to finish, it’s something like 3 to 5 milliseconds for page generation, on a Complex Page, with the JVM in debug mode. And that’s mostly all overhead of the server itself, and NOT my custom code creating the pages. So much better IMHO than using templates, then having to have caching systems for performance, etc. This route equates to very low memory usage, with very high performance. More with less. I love it!

Regarding user experience, the web application will NOT rely on a the user’s computer or iphone for computation. It will not have to download MEGA Bytes of data for this SPA to finally display. Instead, depending on the size of the environment for the database queries, I suspect an average of 200-500 millisecond response times with very large databases, perhaps up to a second. This is quick enough to where I simply don’t see it being an issue. In fact, when the browser reloads and the majority of the background stays the same, you only notice the part of the page that is changing, just like an SPA (at least that’s been my observation).

When necessary, I’m adding minimal javascript for additional functionality towards a Rich Internet Application on very narrow focused components. Like the data tables that need to be refreshed. You can simply choose from a dropdown how often you’ll want it the data to be refreshed, and after that amount of time, the browser will automatically refresh the page. Simple works. At least for now, at this stage of the start up! The future may hold something different, but our customers may just want other features prioritized instead!

Leave a comment

RSS
Facebook
YouTube
LinkedIn