{"metadata":{"title":"I almost sort-of like frontend web development these days(?!)","date":"2024-05-20","author":"Teddi"},"content":{"html":"

This is not a sentence I thought I would ever say.

Warning: generally development-based blog ahead.

Early Days

I first got involved with web development back in… 1998? 1999? I was doing some weekend activities club thing that basically served to give my parents something to do other than having to keep an eye on me during the weekend. Back then, HTML was only just hitting version 3 with CSS 2 only having just been released. There was no React, no Angular, no Vue, no Svelte, no Bootstrap, no Tailwind, nothing. Just HTML, CSS and in super rare cases, JavaScript. Websites were usually designed using tables rather than divs or the better semantic HTML5 elements we have today.

Web pages didn’t need to be responsive; they generally just needed some basic styling and that was it. So, armed with bugger all knowledge, my first introduction to web dev was quite literally Notepad and being told the most basic of tags (html, head, and body). Over the years, web dev got more and more complex. With the introduction of CSS 2.1 (and eventually 3) alongside a global push recommending the use of divs, web dev for the average person became fairly manageable. Throw in jQuery and you had some fairly decent sites! Websites you’re familiar with, like YouTube, Facebook, and so on, were all very much built and ran on these technologies.

However, in the name of progress, engineers everywhere were always looking to make web dev smoother. Eventually, Google came out with AngularJS and a few years later, Facebook entered the race with React. These were frameworks designed and built to solve Google and Facebook-level issues, not the average developer’s problems. The only problem is everyone was enamored by the latest and greatest and as such all the trend-hoppers were insisting this was the way forward: having to learn entire frameworks and their framework-specific languages just to build a website.

Gone was the idea that you could and maybe should render your logic on the server. Instead, many a stupid practice was adopted with many security issues along the way, such as disabling CORS or using local storage for sensitive data.

All of this is to say, web development for someone like me who is primarily a systems/back-end engineer has sucked. It’s been a pain in the arse to keep up with the latest and greatest, to have to learn a new framework every 6 months, to have to learn what feels like a new language every 6 months. It’s been a pain in the arse to have to learn a new way of doing things every 6 months. So I avoided it like the plague. And you can tell I avoided it like the plague because over the years, the majority of BB designs when it came to the web space have been completely and utterly terrible.

I really wanted a system that could do component-based web development similar to that of React and Vue but without the need to learn a new language or framework. A few years ago, a potential candidate appeared.

Enter Svelte

Svelte is a framework that promises a few core concepts.

Write using HTML, CSS, and JavaScript, no need to learn a new language for framework-specific syntax (for the most part).
No virtual DOM; instead, it compiles your code into vanilla JavaScript.
It aims to be flexible to your needs.

Svelte first caught my eye around 2018 with Sapper, which was designed to transform the output of Svelte projects to different formats (such as static sites). I tried out their REPL and found it generally an absolute joy to use but it still wasn’t really ready for use in the way I wanted it.

Late last year, I revisited Svelte and found they had finally launched SvelteKit, which was a more mature version of Sapper. I initially used it to rewrite the rules page and found it as straightforward as ever. I then figured I’d try to make a static blog system out of it, which is how we now have this current version of the blog! Svelte has been used in multiple places but it hasn’t been plain sailing.

GMod 32 Bit

Garry’s Mod is still by default a 32-bit application using Chrome 18 for its web engine. It was revolutionary back in the day (as the default Source engine HTML panel was trash), but these days it brings just as many problems as the original panels had, if not more. One of the bigger issues is that it isn’t compatible with modern web standards at all. By ‘modern,’ I mean anything from 2015 onwards. Sure, you can sort of use polyfills to work around a number of issues - but not all of them.

I updated the loading page with a Svelte-based system and found that 32-bit GMod didn’t like it at all. The rules page gets away with it because there’s no JavaScript being used, but the loading page has a reasonable amount of it (mostly for the videos).

So, what does this mean going forward?

The Future

It’s likely that almost all web-related tasks going forward will be some sort of Svelte-based project. It helps me out massively and has allowed me to be productive in a way no other frontend system has really ever allowed for before. However, it does scupper my idea for a Svelte-based wiki, because our 32-bit GMod users aren’t going to be able to see it.

Oh well, web development is forever a pain.

","css":{"code":"","map":null},"head":""},"slugPath":"/posts/2024-05-20-sort-of-like-frontend"}

We're lazy. Yep.

Historical Posts