Public Learning

project-centric learning for becoming a software engineer

Week 14: A Recap

Previously, on 200 OK

Theory is only good if it holds up in practice as well. So last week’s resolve to use Preact for my dynamic frontend pages was put to the test. Since Preact has a React-compatible API, I was able to leverage all the learning resources available for normal React, including Fullstack React, a Frankenstein-esque compilation of chapters from many different authors. It’s a strange book, and I didn’t like it much. It felt like a disjointed experience, badly layouted and obviously updated in a select few places over time to reflect recent developments in the React ecosystem.
It might just have been a bad time to try and learn modern React syntax. Hooks are clearly the new idiomatic way to write components, but it feels like all learning materials are stuck in one of two places: they either teach the old class-based syntax from the ground up or they treat teaching hooks as additional learning if you’re already familiar with the old way of doing things. I fit into neither of those two groups. My understanding of traditional React is not as strong, but I’m also tired of starting yet another React learning path that assumes I have never written a single line of JavaScript in my life.
In the end, I was still able to make sense of React Hooks and their (admittedly pretty clever) functional approach, even though most of my actual learning came from the official React tutorials and the documentation.

My decision to reach for Preact came with two significant advantages compared to standard React. First, I was able to keep my existing template-driven HTML rendering for scaffolding the initial page. The Preact/HTM library I mentioned last week is just an additional JavaScript package to be served by the Express backend, and any Preact code gets then included in addition to that, creating a rich, dynamic frontend without the need for a separate single-page application with its own entry point and compilation/transpilation pipeline.
And it’s small! With the framework at 12 kB size doing the heavy lifting, my components live in sub-1 kB files that get only loaded on their respective pages (so that there’s no dashboard code on the request inspector and vice-versa). Working with such a small footprint goes to show how ridiculously bloated frontend JavaScript can become.
But not everything was joyful with the tiny, minified Preact/HTM package. Debugging became a nightmare thanks to the minification: every error thrown by Preact referenced the single line of its JS source file and some obscure, minified variable name. Plus, the helpful Preact Developer Tools, a browser addon to inspect component state, doesn’t work with that particular library, essentially creating a black box framework whose internals were really hard to inspect. Tht’s not an ideal learning environment. More than once I was scratching my head at some obvious infinite render loop (sending my laptop fans into a spinning frenzy) that was impossible to debug. The DOM gives no hints as to what happens in Preact‘s VDOM and I can only resort to console.loging stuff to narrow down the search for the error. I may have been a bit stubborn in my decision to not add a build step to my frontend code, but I was determined to not let those comparably small parts of 200 OK become bigger than they needed to be.
In the end I managed to complete the actual implementation of both the dashboard and the request/response inspection tool and the live version at is now fully functional in that regard.

A good amount of time was also spent on trying to solve a mysterious timeout issue with the server-sent events. While they worked great, after 60 seconds of idle time, Firefox always reported that the HTTP connection used for transmitting events was closed. This was strange, because it turned out that this didn’t seem to be a Node-related issue. Node sockets time out after 120 seconds by default, but even after configuring those settings, the timeout persisted. Since I’m not an advanced networking programmer, I ran out of ideas, since I wasn’t even able to determine with confidence whether the timeout occurs client-side of server-side. My (ingenious) solution was to implement a regular heartbeat, that sends an empty comment line every ten seconds from the server to the client, keeping the connection open.
If it works, it works.

Coming Up Next

This week is starting a bit slow, but I’m determined to finish the endpoint behavior customization for APIs and implement most of the backend functionality that is still missing. That will hopefully leave me with bugfixing and refactoring as well as the looming task of writing my case study. I’m really not looking forward to that.



Time spent this week: 38.5 hours