My Web Development No-Framework Lessons
I just wanted to rebuild my website and publish a few of my personal progressive web apps. Well, that turned out to be quite an adventure. Here are a few of my findings, problems, and how I tried to solve them. To seasoned developers some topics might seem obvious, but my point here is to reevaluate the status quo from the perspective of a fresh developer.
No Frameworks.
When building my websites and tools, I want to avoid unnecessary dependencies and keep it simple, stupid. That means no frameworks for me, sir, thank you! Probably I'd run into a few of these issues even if I'd be using a framework like React, Next, or whatever. Also, it's a great way to learn about the problems that those solutions try to solve at a fundamental level. Like with learning music, I don't want to learn songs. I want to learn the basic building blocks to make my own. That's just my personal gusto.
So, without any further justifications, here are a few topics that caught my attention during development, in no particular order:
Problem: Organizing a blog section and writing the content
Making simple static webpages with cool layouts is fun, until you have to change a few lines of code in 10+ files. Writing longer articles in pure HTML is also quite tedious and uninspiring, not to mention all the metadata involved. That might have been the only breaking point for me to dive deeper into static site generators like Gatsby or Jekyll. Luckily I found a sleek solution that I can customize for my needs.
Solution: Build Scripts and Markdown
Markdown is a more human-readable way to write structured content that can be parsed into other formats like HTML. You probably have used it in one way or another without even realizing it. A lot of online forms use markdown formating, and you might have come acrooss README.md files.
Using Markdown and a bit of NodeJS magic, I managed to put together a script that does what I need. It scans a folder for .md files, extracts metadata, converts them to HTML, and fills it into pre-built HTML templates. It also builds an RSS feed and a sitemap. Now, writing blog posts is fun!
I still want to improve the pipeline of generating or formatting images for my posts and make a tool that I can use on my phone when I'm on the road.
Problem: Browser cache ... omg, why?
This was scary, especially before I turned my web-based tools into PWAs. Modern browsers are notorious cache hoarders. It makes sense to reduce data usage and allow users to load pages that they have visited faster by storing transmitted data automatically. But for a developer, this causes a bunch of issues if you don't know if visitors are seeing the latest version of the page or app. Sometimes worse, if only some parts get updated and that messes up the final composition.
Most websites and web apps are built with an interplay of different technologies, with HTML, CSS and JavaScript files being the most common. But you also have type fonts, images, and maybe other files that you want to serve to the world. If these files get mixed up with older versions that are stored in the browser cache, things get messy. You can tell your web server to ask browsers not to cache certain files or give them an expiry date, but that is not very reliable or synchronized.
The most common solution seemed to be implementing so-called cache-busting techniques, like changing the name of files by adding a version number or hash string to each file. That would require me to rewrite file references to all those files. For that to be reliable, I would have to build something like my blog build script for the whole website and have to run that script each time I make a change. This adds way too much complexity, and I wanted to find a simpler solution.
Solution: Service Workers + .htaccess files
Simple might be a bit of a stretch, because I'll probably write a full article on this at some point. It is hard to explain all the initial confusion I faced when implementing service workers for the first few times. But to make it short, service workers are background processes that can do a bunch of cool things. One such thing is caching. By intercepting the browser's network traffic and preloading certain parts of the website, you can take full control over the cache ... almost.
In some cases I still ran into problems and edge cases due to the way I set up some apps. I did not want mobile users of some apps to use the swipe-down refresh, because I think it can be distracting and doesn't feel like a native app. This however, caused some problems where the service worker might have the new files, but they are not served to the actual page that is being displayed. In the end I built my own system that refreshes the app when it starts if there is a new version. There are many ways to handle this, and it's very app-specific on how to set up your service worker.
One main thing I can recommend when getting into service workers and debugging your implementation is to really understand their life-cycle mechanism.
Anyway, for now, service workers work great for me when combined with server-side settings for cache instructions.
Problem: CSS height: 100% or 100vh or what?
Back when I started making websites in the old days, I was happy to use percentages for everything. At the time responsive layouts were not even a thing. But I always wanted my pages to look good on any window size.
Now that should be fine, and it still works, except for one minor hiccup on mobile browsers. When the address bar disappears and pops back into view when scrolling up and down a page. Every browser seems to have their own way of interpreting some units, and I fell for using "vh" (view height) in some cases at first. Until I noticed a layout shift when refreshing the pages on my PWAs. Since I wanted my tools to be full-screen and feel just like a native application, this was pretty annoying. It took me quite a while to figure out that "vh" was the cause.
Solution: 100lvh (large view height)
After "vh" not solving the issue of skipping around when the address bar hides, there is a new unit "lvh" (large view height), that I was unaware of. Using "height: 100lvh;" seems to solve this problem for me, for now. Let's hope someday browser manufacturers can find more consistent implementations for interpreting unit sizes.
That's it for now. Thank you for reading this wall of text!
If you want to find out more about web design and how to build a system that works for your own needs, then drop me a message and we'll try to figure something out together!