Dev-Zoo Reboot 2025
Once upon a time around 2004 I had a vision for this domain. It should be a home for creative minds to showcase their work and share their knowledge. I tried and failed. After that I chose to just use it as a personal portfolio for my own 3D-Art and games.
But that initial vision kept creeping into my head every time I updated this website. So this time I'm trying to get one step closer to that original idea. I'm not planning to build another social network or anything like that. However, I hope to be able to share more of my journey and maybe get a few others to join the ride.
Why no pre made solutions?
Building a website without website builders, WordPress, or frameworks in 2025 can seem like reinventing the wheel, but to be honest, the current wheels just don't roll smooth enough for me.
Those tools are designed to help people that have little to no knowledge about how the web works, and they try to cover almost every possible use case. That is quite a challenge in itself but also comes with a lot of overhead and bloat. Other solutions are designed to handle massive amounts of data and multiple page authors that want an easy-to-use interface for editing content.
I went down the rabbit hole of using content management systems and paying for plug-ins and themes for a personal website, and I don't want to go there again.
The Bloat Web and No-Framework Movement
Just like the DAWLESS (DAW stands for Digital Audio Workstation) movement in music production is trying to get back in touch with haptic tools and instruments, there is a movement in web development called No-Frameworks. The basic idea is that the heavy focus on pre-made, one-solution-for-all-needs approaches of recent years has led to what is called the "bloat web," where some web pages require 20+ MB of data just to display a single page. This is not just bad for users with limited data and slow connections. It also has an impact on the overall energy consumption for processing.
A good example is the AI chatbots you can find on many pages nowadays. These little instances of large language models (like ChatGPT) on websites require a lot of processing just to answer simple questions, and often they don't even do a good job.
Since I do know a bit about web architecture, design, and programming, and I'm always thirsty for expanding my skills, I've decided to tackle this project and find my own solutions to common problems.
What is the issue with pure HTML?
While making a website in pure HTML (Hypertext Markup Language - the original syntax of the WWW) is still possible, it will become quite painful to manage and look cool. Even if CSS (Cascading Style Sheets - the syntax used to define the "look" of web pages) and JavaScript (the most widely used programming language used to make interactive elements on the web) join the team, the task is still not easy and can introduce a lot of friction when producing new content.
So how can I do it?
I've been making websites (on the side) since early 2000, so I have a bit of experience to draw from. Getting up to speed with modern technologies took a bit of research and a few online courses to get my JavaScript knowledge up-to-date.
Since I knew what I don't want (for example, dynamic content loading from a database or framework dependence), I looked into static site generators and discarded them for also having too much overhead. I don't want to learn a framework if I can spend that time learning the foundational building blocks and make my own.
For a start I like to go with a "make it exist first, then make it cool" type of approach.
So I started to build a basic structure with pure HTML and CSS to see how far I could get. Yes, just start doing it! Sure, mistakes will happen, and you might spend some time reworking a bunch of files (Pro Tip: use the search and replace function), but this will lead to deeper understanding of the how, what, and why.
I use VS Code for programming and GitHub for versioning and backing up my work. I enjoyed working with SVG (Scaleable Vector Graphics) in code and using Inkscape a lot. It reminds me of Flash ActionScript and game development.
Accessiblility and Progressive Enhancement
I also tried experimenting with custom web components (a way to dynamically load parts of a webpage using premade chunks) and dumped the idea again because I want the baseline of my pages to work without JavaScript. But I will probably be using that technology for features at some point. That is a design principle called progressive enhancement. The website and its navigation should work on a basic level without bells and whistles. The "making it cool" part should only be an added layer and not a requirement.
When diving into web development basics, you will find a lot about semantics, accessibility and other principles that are foundational ideas of the World Wide Web and I am trying my best to incorporate them into my process. After all, there have been, and still are, a lot of clever minds involved in defining the standards for an informational network designed for all humans.
The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability. W3C - Accessibility
There is a wealth of information out there on these topics, and whole books have been written on each, so I won't go further into them here. Just to make it short: there are best practices for making content and publishing it, and it's worth following them as close as possible since they tie into what developers seem to care about the most these days...
SEO (Search Engine Optimization)
There is nothing worse than pouring your heart and soul into something and wanting to share it with the world, and then... nothing. I guess I could write a bunch of books, poems, and songs on that. So this time I want to at least not self-sabotage my efforts by ignoring how content can be found on the internet: search engines and web crawlers.
What I think most folks get wrong about this is: build websites and share content that you care about, and build them for humans. Not to play search engine optimization games. Google on SEO
It's important, however, to allow search engines to understand what your content is about by following some basic rules like adding meta content, structured data, and descriptions. But once you start thinking more about how to get more and m0000r - that's where a lot of folks start going down a dodgy path.
So I'm sticking to the basics: clear, well-structured, and crawlable pages with meta descriptions and structured data where it is appropriate. Most of all, I write and produce my own content about what matters to me and what I feel is worth sharing.
But what about this blog?
I knew that static, handwritten HTML files won't be good for maintaining a growing set of information like a blog. So I did some more research and developed a few scripts that can compile text written in Markdown to HTML pages using NodeJS. Thanks to this blog post that I found: Building a Simple Static Blog
That was a bit of a learning curve, but that blog post at least set me off to a good start. Thank you, Matt Segar! For now it works pretty well, and I hope to expand on it in the future.
File cache and service workers
Once I started testing the site on different devices and updated my CSS files, I noticed that they would not update on mobile browsers. The old files had been stored in cache, and the only way to see the changes was to delete the browsing data. This is not ideal because I want to make sure that visitors to my website always get the most recent version.
There are many different solutions, like cache busting and appending version numbers to the files. But I don't want to change file names all the time and update them in all references. From developing my web apps, I knew that I could use service workers for this.
The service worker I built is pretty simple. It caches the most important files, like CSS files, fonts, logos, and main pages. It also manages a little extra cache on the fly. Like this, I can tell the service worker if there is an update available, and it will serve visitors with the fresh files.
What is next?
Finally I can do what I wanted to do for years: share my thoughts with YOU and my imaginary audience!
I'll be writing blog posts when I feel like I have something worth sharing and be working on improving my PWA tools. I have a few plans to optimize writing blog posts on the go and hope that I can get a few guests to write some content too.
Thanks for reading!
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!