Just as planned, I continued to work on the technical implementation of the new gen-3 UI.
As I am sure I discussed before, this new generation of the game’s interface does most of its work on the client-side (meaning in the browser), while it fetches the data it needs to render pages from an API on the server-side. In contrast, gen-1 and gen-2 do almost all of their rendering on the server-side and there’s no extra step to fetch data.
Why am I telling you this? Well, like everything in engineering, the above is a matter of tradeoffs: Doing many things on the client means you often get a much snappier experience (because only data needs to be fetched from the server, not the whole UI) and it’s easier to implement more fine-grained interactions on a single page. Gen-1 would always reload a whole page and gen-2 would do a lot of complicated magic (I don’t like magic) under the hood to allow for partial page updates (often requiring full page loads anyway). The downside is that client-side frameworks have to do much more of the heavy lifting in terms of deciding what data to load, often causing cascading calls to the API to render complicated data (depending on API implementation). If one isn’t cautious, this can have performance and UX implications, like pages littered with “load animations”, flickering UI elements or stale data.
In the particular case of AirlineSim, there’s another challenge: Gen-1 and gen-2 aren’t going anywhere anytime soon. While replacing the remaining gen-1 pages as soon as possible is very high on my list of priorities, any solution needs to deal with the fact that they’re going to be around for many more months, more likely years. At the same time, I really need to avoid code duplication beyond the amount that already exists in the codebase.
Case in point: Both gen-1 and gen-2 render the header and footer you see on every page, but they do it in wildly different fashions. If I - say - add a new item to the main navigation, I have to add it twice. To not make the same mistakes as my 2009-me, my first development goal is to implement both header and footer in gen-3 so I can get rid of them in gen-1 and gen-2. As said last week, that goal is_purely technical_. Ideally, there won’t be any design changes for now.
But to cut an already far too long story short: I got a bit ahead of myself and I wanted to alleviate some of the downsides of a client-side framework (see above) by using some of the more advanced features of a library I used (not magic per se, but complex). To that end, I worked with my new buddy Claude on an implementation that would provide these benefits for gen-3 while maintaining a unified pipeline that still generated the output required for gen-1 and gen-2. But after working on this for two days or so, I had to pull the plug and decide that the (relatively) meager benefits weren’t worth the added complexity, the fragility of the setup and the effort to make it work (and keep it working).
So as a warm-up, I used the setup I had before and whatever time I got left to make the footer work as a shared component between all generations of the UI. I’ll continue on that the following week to hopefully get the whole page frame working. I am sure you’ll read about me trying to tackle the above mentioned downsides in some other way, too…