Lessons from writing a dynamic CMS for static hosting

or: How I Learned To Stop Worrying and Love the Code

So, what’s this about?

First things first, the #codenewbie tag is tad misleading, I have been coding for a short while already. But recently, I have blasted through a Udemy course on web-developmen…

or: How I Learned To Stop Worrying and Love the Code

So, what’s this about?

First things first, the #codenewbie tag is tad misleading, I have been coding for a short while already. But recently, I have blasted through a Udemy course on web-development. Aside from learning a lot about silkie chickens, I got to standardize and bring up-to-date my knowledge in a structured learning environment (in other words: I’ve binged the videos in correct order). And what better place to put new skills to use than in a personal project for my portfolio?

(the answer is: at a paid job, but anyway)

So what is it that I made?

A CMS engine made in pure JavaScript, running entire logic client-side. No installation and setup (beyond editing config and content files, and uploading to webhost), no backend setup, no database. Can be hosted on a static host and serves dynamic content.

Here’s the shameless plug part: you can find the repo at https://github.com/turowski-k/litesite-cms-js. The code leaves much to be desired and is a result of manic, caffeine-boosted typing from midnight till sunrise, but it works. It’s demo-able (-ish).

Why did I do it?

  • It was fun to create
  • Why not?

How did I do it?

  • I might write a piece on it
  • Some day
  • Maybe

The lessons learned

It’s about time we moved onto the clou of this article. The main takeaway. The final nail in the coffin that will prove it’s not just an Impostor Syndrome and I’m simply a horribly inept software developer who can’t write clean code.

Making it means understanding it

Litesite’s engine is kinda like Express.js, only running in the requestee’s browser. It comes with several downsides (ex. all files are ripe for scraping) and it’s a… bunch of code held together with spit and duct tape. I didn’t wanna create a product able to compete with anything widely used, but I sure did learn a lot.

And not just things I would learn doing webdev the usual, modern way – bunch of npm i commands followed by combining building blocks together and configuring them. Not that there’s anything wrong with this way. It’s more reliable usually and speeds up the process tenfold.

Dunno about you, dear reader, but I always felt a lot of angst when working with these frameworks and modules. Because I didn’t understand them, I had to rely on these mystery boxes – put in something, take out something new, pass it around to the next mystery box.

After publishing the preview version of Litesite, I realized this anxiety is now gone. I’ve written routing, rendering and – frick – even very basic Markdown parsing. Is it efficient? No. Am I now more confident about working with modules? Yes, perhaps because now, in case of fire at the npm repository, I will be able to write all of this myself. Even if to plug it in only temporarily.

It makes you learn interesting things

Bit obvious, innit? To make something you’ve never done before, you have to learn a lot. It’s not the point, tho.

I touched on things I wouldn’t even have to worry about when creating a good ol’ Express.js webapp. Routing for example, you just plug in the endpoints strings and callbacks into your app and let the framework handle it.

Previous point touches on getting yourself more comfortable with the “how does this interact with that?” part, boosting your confidence. But it’s also about learning “what makes this tick?” and even “how do I make it tick?”. And about overcoming the challenges.

See, Litesite runs client-side, so I couldn’t implement actual routing. For all I know, there’s probably a regular http server running on the host. I send a GET to the endpoint, and I get what? The index.html if there’s one in the dir path of my “endpoint”. Or a 404, which is more likely. So how can one get around this?

Using hash routing. Which isn’t a new concept, but not something I would’ve thought of in the first place. Obviously, after merely completing a single Udemy course (even if it proudly calls itself a “Bootcamp”), I didn’t know where to get the current url from.

Alas, a single google later, I was equipped with the knowledge about window property. Basic knowledge, I realize that. Your friend’s grandma’s dog knows about window.location, but I didn’t – and I didn’t know about many other concepts I learned along the way.

The joy of coding

When coding Litesite, I could have pulled some Node modules or embedded bunch of JS scripts off the Internet. Frick, the entire functionality covered by Litesite can be outsourced to an existing solution – like WordPress or Drupal or even (closer to what my app is) Jenkins.

But that’s not the point!

This project is (was, more like, cause the most fun part is done) pure, unrestricted, manic coding. Sitting in front of the keyboard until wee hours of the morning and tapping away (not thocking, unfortunately, I’m a filthy membrane user, sue me) line after line after line of code. All I’ve had was a very simple idea on how things should be glued together and a lot of empty space to fill it up with my creativity.

And I loved it! Every second of it! Each night felt like it was 30 minutes long!

But the article is about what this project has taught me. Let’s just say it also reminded me how ridiculously fun programming can be.

And it absolutely can be fun, when it’s not about creating yet another endpoint to pull data off the DB or changing the size of a modal so it fits client’s requirements. Worse yet, by using !important rule, because the codebase is 10 years old and nobody understands what part is responsible for what. Like we’re bunch of code monkeys stuck in a cage, not really understanding why we’re not allowed to climb the ladder.

Engineering/architecture experience

This is another obvious point and I don’t really have a witty comment about this one. 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 is nowhere near cleanly written or perfectly designed, but…

Experience comes from making bad decisions. And with experience, comes perspective.

Summary

Honestly, I don’t really know how to summarize this stuff I’ve somehow managed to write down (and be happy about the quality of the writing). It’s not that long, go read it if you haven’t, there’s no tl;dr.

So, I made a thing and I’ve had a lot of fun. But I also learned a lot. Like, a lot lot. Am I happy with the end result?

Meh, yes and no.

Yes, because it was really fun to see the app come to life as I envisioned it (mostly). And it even works (-ish) too. No, because equipped with my new experience, I see how I could’ve done this or that way better.

But here’s the kicker – I wouldn’t be equipped with said experience if I didn’t commit the crime of writing Litesite in the first place.


Print Share Comment Cite Upload Translate
APA
Kacper Turowski | Sciencx (2024-03-28T13:03:24+00:00) » Lessons from writing a dynamic CMS for static hosting. Retrieved from https://www.scien.cx/2022/09/21/lessons-from-writing-a-dynamic-cms-for-static-hosting/.
MLA
" » Lessons from writing a dynamic CMS for static hosting." Kacper Turowski | Sciencx - Wednesday September 21, 2022, https://www.scien.cx/2022/09/21/lessons-from-writing-a-dynamic-cms-for-static-hosting/
HARVARD
Kacper Turowski | Sciencx Wednesday September 21, 2022 » Lessons from writing a dynamic CMS for static hosting., viewed 2024-03-28T13:03:24+00:00,<https://www.scien.cx/2022/09/21/lessons-from-writing-a-dynamic-cms-for-static-hosting/>
VANCOUVER
Kacper Turowski | Sciencx - » Lessons from writing a dynamic CMS for static hosting. [Internet]. [Accessed 2024-03-28T13:03:24+00:00]. Available from: https://www.scien.cx/2022/09/21/lessons-from-writing-a-dynamic-cms-for-static-hosting/
CHICAGO
" » Lessons from writing a dynamic CMS for static hosting." Kacper Turowski | Sciencx - Accessed 2024-03-28T13:03:24+00:00. https://www.scien.cx/2022/09/21/lessons-from-writing-a-dynamic-cms-for-static-hosting/
IEEE
" » Lessons from writing a dynamic CMS for static hosting." Kacper Turowski | Sciencx [Online]. Available: https://www.scien.cx/2022/09/21/lessons-from-writing-a-dynamic-cms-for-static-hosting/. [Accessed: 2024-03-28T13:03:24+00:00]
rf:citation
» Lessons from writing a dynamic CMS for static hosting | Kacper Turowski | Sciencx | https://www.scien.cx/2022/09/21/lessons-from-writing-a-dynamic-cms-for-static-hosting/ | 2024-03-28T13:03:24+00:00
https://github.com/addpipe/simple-recorderjs-demo