What's this about
This is a rewrite of an article I published on dev.to back in the late 2022.
It's a full-blown remaster, enhanced with new perspective and experiences that I've gained thanks to... well, more work experience that I got. And a burnout, too. But hey, happens to the best of us.
The year 2022 was an interesting one, that's for sure. For me, it was filled with a lot of personal stuff I had to go through, some particularly heavy and some... heavishly uplifting, I guess? I faced an emotional breakdown in the first half of that year, definitely the biggest one until then. I won't delve into the details of that, because it's not why you're here, so let's focus on the important bit:
I made it through. 🎉
What followed a few months later was a moment of extreme clarity and mental focus. It wasn't "oh wow, it's just like I felt before", though. It was six weeks of my brain working in overdrive mode, for whatever reason. I decided to use that to the fullest and so I did, blasting through a silkie-chicken-filled Udemy course on web development.
For the first time in quite a while, I got to standardize and bring up-to-date my knowledge in a structured learning environment. Or, in other words, I've binge-watched the videos on 3x speed and somehow absorbed it all.
And what better place to put new skills to use, than a personal project never meant to bring me any success?
(the answer is, obviously: a paid job, but nevermind)
And boy, did HTML change a lot since the last time I truly touched it... Before that, I was still absolutely convinced we're supposed to close the singular tags, like this: <br/>.
The fruit of my work
So, what was the thing that I created? A- an-
Uh...
Well, I'll admit it: it's hard to define what that thing was exactly, but it had a bit of everything in there.
Think of it as a Temu version of Express.js, with routing, a templating engine similar to EJS, and a Markdown renderer - but written all by myself, in pure JavaScript, running entire logic client-side. Yup, read that right: client-side. I call it a frontend backend framework. Cause it's a backend... but it runs on the frontend.
Originally, I called it LitesiteCMS, a lightweight CMS engine coded in pure JavaScript, but it definitely wasn't a CMS.
Because, you know, it had no content management system whatsoever.
But I think we can stick by the name Litesite, and if I'd ever rewrite it, I probably would do it under that name. So, let's refer to it this way.
So... why did I do it? Simple:
- Fun.
- Why not?
As I'm rewriting this article, I am indeed thinking about redoing Litesite from scratch, righter way this time. One module after another, and maybe publishing articles about the development here - where everyone can see the idiocy and pointlessness of my idea.
Now, before you jump to conclusions such as "Man, that guy sure loves to crap on himself," consider this:
Pointlessness is the point of Litesite and similar projects. There's something almost punk about them. They're not "portfolio pieces", but exorcism rituals of the impostor syndrome and love letters to just doing the damn thing, even if it's architecturally abominable.
Because hey: maybe it's not something you could ever push to prod, but it sure is something that feels liberating.
The lessons learned
The project was an amazing exercise that allowed me to learn through doing, and not just about JavaScript but also about how things work. More importantly, it reminded me of something important: the reason why I even started coding in the first place. So, let's focus on those lessons the title promises, one by one.
Making it means understanding it
Litesite's engine is kinda-sorta like Express.js, except it's running fully in your browser. That comes with more than a handful of downsides (e.g. all files are ripe for easy scraping and you can't really implement any security or backend privacy). Also, it's just a bunch of code held together by spit and duct tape. But it was never my goal to create a product able to compete with anything widely used. My goal was to learn, and learn I did - a lot.
And not just things I would learn by doing web dev the usual, modern way - a bunch of npm install and brew or pnpm commands, followed by combining Tailwind building blocks together into components and views, sprinkling some Lodash niceties on top of it, and configuring it all to respond to some backend. Not that there's anything wrong with that approach. Quite the opposite, it's definitely more reliable and speeds up the process tenfold.
But... dunno about y'all, but I do feel a lot of anxiety when working with these frameworks, packages, and modules.
I don't understand them, at best I know how to use them, so I need to rely on them blindly. They're sort of mystery boxes - I put something in, take out something new, and pass it around to the next mystery box. Eventually, I end up with a whole website, and while I do have a vague understanding of what's happening and where... I don't know any specifics.
But after finishing the early version of the original Litesite, I realized this feeling of dread was greatly diminished. I've written my own routing, rendering, and even very basic (also: very wrongly tackled) Markdown parsing. Is it efficient? Heck no. But am I more confident about working with libraries that do these things? Yes, perhaps because now, in case of fire at the Npm Repository Inc., I will be able to write all of it myself - even if only to plug it in temporarily.
Now, obviously, this won't ever happen. Npm is too big to not have a thousand fallbacks, load balancers, and geo-redundancy nodes across the Earth and perhaps some more populated areas of the Moon, too. And for each and every package, there's a dozen alternatives. But anxiety cares little about such minute details.
It makes you learn interesting things
Seems bit obvious, doesn't it. Doing things you've never done before means you learn those things by doing them.
It's not my point, though. I've delved into topics I wouldn't even have to worry about when creating a good ol' Express.js web app. For example, when working out routing, you just plug in the endpoints and callbacks into your app, and let the framework handle it.
Previous bit touches on getting yourself more comfortable with "How does this interact with that?" part, boosting your confidence. But these kinds of projects are also about learning "What makes this tick?" and even "How do I make it tick?". And about overcoming whatever challenges the thing throws at you. And there will be challenges, rest assured.
See, for example...
Litesite runs client-side, so I couldn't implement actual routing. For all I know, there's probably some Apache server running on the host I'd be theoretically using. If I send a GET request, what do I get? Whatever file my request points to. So, how do you get around this?
"By using hash routing" was the correct answer.
Which isn't a new concept, of course - but it's also not something I would've thought of in the first place. After completing a single Udemy course (even if it proudly calls itself a "Bootcamp" of all things), you don't learn everything there is to know about JavaScript. But a single google later, I was equipped with the knowledge of the window property. Basic knowledge, I realize that. Your friend's grandma knew about window.location back in the 80s, sure.
But I didn't, just like I didn't know about many other concepts I learned about along the way. I don't think there's anything bad about not knowing every nook and cranny of the stack you use at work. Nobody knows all of it, and it's not about being some unbeatable guru with unshakeable confidence.
It's about being open to broadening and honing your skillset.
And I think there is a lot of anxiety around that concept. Many companies try to seduce you with their "learning budget", but somehow you end up feeling guilty about not knowing something that someone deems basic knowledge. Well, screw that. In reality, nobody should care about whether you know a single specific thing or not, as long as you're able to catch up on whatever skill or concept is needed to tackle your Jira tickets.
Engineering and architecture experience
It's another seemingly obvious one, but designing entire systems instead of tiny modules is an important milestone in the journey of becoming a senior developer. Here, I've had to plan out the entire app and write it myself, making sure everything connects with other parts correctly. Well, "correctly" might be a bit of an overstatement. The project was nowhere near cleanly written or perfectly designed, but...
Experience comes from making bad decisions. And with experience comes perspective.
This brings up to the singlehandedly most important lesson learned for me, a cherry on top for this article.
The Joy of Coding
When making Litesite, I could've pulled some Node modules or maybe embedded a bunch of JS scripts hosted on the web. Or, let's be honest, the entire functionality covered by Litesite could be outsourced to an existing solution. Expess, maybe WordPress or Drupal... or, closer to what Litesite is, Eleventy and Gatsby.
But that's not the point!
This project was pure, unadulterated, unrestricted manic codding. Sitting in front of the keyboard until the wee hours in the morning, tapping away (not thocking, I'm a filthy membrane peasant, sue me) line after line of code. All I've had was a very basic idea about how things should be glued together and an entire empty Git repo to fill up with my creativity. And heavens above, I loved it - every second of it.
Each night felt like it was 30 minutes long. It came, it went, and then I was like, "Crap, the daily standup starts in 2 hours, and I haven't slept at all." Good thing I wasn't decaf back then.
So, this project reminded me how ridiculously fun programming can be. When it's not about creating yet another endpoint to pull data from the DB or changing the size of a modal so it fits the client's requirements, of course. When it's not about staring at an !important directive stuck in the CSS because the codebase is 10 years old and nobody understands what part is responsible for what...
Like we're all just bunch of code monkeys stuck in a cage, not really understanding why we're not allowed to climb the ladder and grab the banana labeled "clean code".
But this here? This was the reason why I started programming in the first place. It's like rediscovering LEGO sets in your attic, ones you've played with as a kid. And finding out that you don't ever get "too old" to get creative.
Outro
I crashed, rebuilt, found joy:
dumb projects none care about
but myself alone
I made a thing back in 2022 and I've had a lot of fun doing it. I learned a lot, too. But... am I happy with the end result? Yes, because it was really fun to see the app come to life as I envisioned it. Also, kinda no, because equipped with my experience, I see how I could've done this or that way better.
But here's the kicker: that's exactly the reason why I made Litesite in the first place.
So, do yourself a favor. Write something dumb at least once every now and then. Something completely for your own enjoyment, something unrestricted by any rules, something not meant to fulfill any purpose.
Don't err on the safe side, break some things, make the server die or leak the data - in a controlled environment. Away from prod. You don't have to build something useful here. Just build something that's yours, and see how fun it can be.
Resist that Silicon Valley compulsion to ALWAYS be making the Next Big Thing. ✊
Not because we shouldn't strive to create big things. But because
all work and no play makes Jack a dull boyall work and no play makes Jack a dull boyall work and no play makes Jack a dull boyall work and no play makes Jack a dull boyall work and no play makes Jack a dull boyall work and no play makes Jack a dull boy
And then, I promise you this:
You'll notice your serious job, where you care about the code quality, about the best practices and security (and you should care about those things, don't get me wrong!), will suddenly feel a bit more fun.
I'll leave you with a quote by Giovanni Giorgio Moroder.
"Fuck around and find out", said Father of Disco, the Godfather of Electronic Music. Who are we to question his wisdom?