For the longest time, I’ve been quite vocal about my aversion to web development. I never appreciated abstractions or the way many industry-standard tools handle websites and web applications. My disdain for JavaScript further distanced me from the idea of creating websites like Dimden.dev or Ikari Dev. However, as time has progressed, and I’ve gained a bit more wisdom, I felt the need to delve into the reasons behind my disapproval in detail. Rather than relying solely on preconceived opinions shaped by others’ complaints about the web and its current state — coupled with my sheer displeasure when working with JavaScript in the past — I decided to form my own perspective on why I should either embrace or reject these things.

Angular or React?

My choice of frameworks to learn was decided by looking at LinkedIn job postings and seeing the most common top javascript libraries and frameworks that employers are looking for. A lot of the frameworks in job postings were some sort of variation of React, with the most common of them being NextJS and Remix. Anglur came in second as the most requested for Android applications. So this narrowed down my choices to only two at the time.

When I first tried getting into web development again with a fresh perspective, I was immediately having regrets. I learn things by breaking them down to their core first to have a good grasp on how something functions, and to no one’s surprise, a lot of modern web frameworks never explain how they function to their users; their docs will just tell you “do this” or “do that” and call it a day, and in the context of React, their documentation is so bad that they assume that you know how to use npm by default and that you’ve already installed the official react package which is published under a mysterious user by the name of gnoff. You heard that right, the official react package is under some random user’s account and not under an official organization account of some sort.

The documentation of these frameworks/libraries wasn’t the worst part when starting however, the worst offence modern frameworks participate in is forcing you to download thousands of packages on your machine which all collectivity hover around 400 megabytes of junk. Granted, Angular is a bit more conservative with the junk they throw your way, with their core package only hovering around 20 megabytes at the time of writing; but it is still unacceptable when modern frameworks can be boiled down to document.createElement() with a JSX interpreter like Bable added on top of it. As someone who lives in a country with no unlimited internet and our ISPs charge extortionist prices for very limited 120-240GB quotes, every megabyte counts, and frameworks start to look like a money investment rather than just a time/mental investment.

As you might have noticed during the middle of my rant, I’ve broken down React for you.

<script src='./modules/react/umd/react.development.js'></script>
<script src='./modules/react/umd/react-dom.development.js'></script>
<script src='./App.js'></script>
<div id="app"></div>
<script>
    const pageRoot = ReactDOM.createRoot(document.getElementById('app'));
</script>

React is just two scripts, the react.development.js script and the react-dom.development.js script. Your website is built with components inside the App.js script, and the components are just functions that return HTML, so it would then run through a generator that creates these elements for you via React.createElement().. which is just document.createElement()

This is a needless abstraction with a lot of bloat, and if your goal is to create a very lightweight and fast interactive website or web application that scores 100s in light-house performance scores, just use vanilla javascript and learn how to interact with the DOM without the help of frameworks; and you might end up creating your own new framework in the process which will reset the framework day counter.

Don’t get me wrong, I understand why the average Joe would rather use these frameworks despite how stupid they are once you dig deeper into how they work under the hood; because the average Joe doesn’t care about performance or mastering a tool, they just want to watch a couple of tutorials on YouTube then immediately create a few flashy projects to put on their résumé, and start working in the tech industry. I’m however not an average Joe, and I’m an annoying arch Linux user (btw) who has to get their grubby hands deep into anything that ever touches their PC and understand how it works to its core. Also, I like to back my opinions with technical facts about the thing I’m complaining about so that the less tech-savvy cannot argue against me, and I can pinpoint the react andys who are worth my time to discuss or argue with. Ultimately, you cannot have a healthy conversation about frameworks with people who blindly worship them without understanding their flaws or how they even function.

Ultimately, I’ve mastered React by understanding how it works under the hood and making a website entirely from scratch without ever touching the CLI tool to automatically install all 1400+ packages that React tries to shove down your throat. But I was left unsatisfied with React’s workflow, and decided to stop learning it and go find something else to build a website with.

Alternatives

Long-time followers or friends of mine might remember that I’ve had 3 different websites before, back when I used to own the maxisjoe.ml domain before it got taken over by a scam redirect. I built those websites using these three methods:

• Inside a game engine
• Pure HTML/CSS
• Angular

The angular one was so bare bones and unfinished that we can honestly just skip talking about it and the Pure HTML/CSS is boring, so let’s talk about the eye-catcher:

I love the Godot Engine so much that I use it to write GUI applications. It is light-weight, has all the tools you can imagine to create any piece of software you could imagine, and is incredibly fast for nearly all tasks; and if you don’t like using gdscript or need to do more low-level stuff, you can always use Rust with it. So it is to no one’s surprise that for a long while, I’ve built my website inside Godot back when I used to host this website on 000WebHost.

The Godot website was amazing, it had an animated background of stars, and it acted like a direct card to all my socials. It was exactly what I wanted my website to be. So why abandon it?

In Godot 3.x, there was no easy way to strip down all the unnecessary bloat that came with .pck file that contained all of my website. As a result, my website was 30 whole megabytes! It doesn’t sound like an issue in the long run, especially with how I can only load the website once and then forget about downloading the entire .pck file again even after updating; but to me? that was simply unacceptable.

The constant jokes and 💀 emojis on unitystation’s discord server were not what made me reconsider finally making a proper website that’s not built with a WebGL game. It was the size.

At the same time as well, I wanted to prepare for the possibility of getting a job as a front-end developer; so understandably, I’ve decided to dip my toes once again back into frameworks.

I helped a bit with unitystation’s website, and I tried learning Angular; but in both instances, I simply hated the development workflow of these frameworks which resulted me in never finishing my projects with them. Until one framework stood out to me.

Svelte, my beloved.

If you want your future web development / JavaScript framework to catch the attention of experienced computer engineers and annoying (arch) Linux users like myself (btw), Svelte is the standard.

Yeah, Svelte is still yet another framework that abstracts stuff away from you, but it doesn’t try to hide those abstractions from you. From the very first hour you interact with it, Svelte and SvelteKit will leave a good first impression by explaining how things work via an interactive tutorial and detailed documentation and will even invite you to check out the source code of its inner workings.

But what attracted me to Svelte wasn’t the inner workings of it or how it teaches you how to use it. I was attracted to Svelte because of the unique way it lets you build websites without over-relying on JavaScript/TypeScript. You can build an entire website within Svelte without touching a single lick of JavaScript yourself, and when you do have to use it; it’s a breeze.

For starters, let us talk about how you can make a hello world in Svelte vs React.

// React
export default function MyApp(){
    return (
    <div>Hello, World!</div>
  );
}

// Svelte
<div>Hello, World!</div>

You might be wondering, “What in sam hell is going on here? Isn’t this just pure HTML?” and you are correct.

Svelte components, pages, and files are written exactly like HTML documents. There are no ugly function returns and each component is just its own svelte file that has its own functionality, layout, and content.

let me share with you one of my components here

<script>
    import * as maxheader from "$lib/maxheader"
</script>

<body>
    <header>
        <h1>Welcome to {maxheader.RandomName()}'s hideout.</h1>
    </header>
</body>

<style>
    h1{
        color: aqua;
        font-size: xx-large;
    }

    body{
        font-family: 'Handjet', cursive;
        font-family: 'Inconsolata', monospace;
        font-family: 'Source Code Pro', monospace;
        background-color: black;
    }
</style>

This is the header that you see on the main page, which is also used on other pages. The header component is stored in a file that is called header.svelte and is added to pages simply by writing <Header /> where I’d like the header component to be. Here’s an example on how it’s done in my home page:

<script>
    //Trimed down version of the home +page.svelte file
    import Fundbar from "../../../components/fundbar.svelte";
    import Header from "../../../components/header.svelte";
    import * as maxheader from "$lib/maxheader";
    import SocialIcons from "../../../components/socialIcons.svelte";
    import Newin from "../../../components/newin.svelte";
    
    $: hideAnnouncement = false;
</script>

<body>
    <header>
      --->  <Header />  <---
    </header>
    <div class="centerContent grid">
        <div class="text-2xl gap-4">
            <div class="flex justify-center text-center pb-2"><p>I'm a {maxheader.getAge()} year old Egyptian college student who loves open source software and video games.</p></div>
            <div class="flex justify-center text-center pb-8"><p>I created TWCRemake and I'm a full time maintainer/contributor on Unitystation.</p></div>
            <div class="fundbar"><Fundbar /></div>
        </div>
        <SocialIcons></SocialIcons>
        {#if hideAnnouncement === false}
            <div class="justify-self-center">
                <Newin windowTitle="Announcement" message="{announcement}" button1="ok" button1Action={() => hideAnnouncement = true}></Newin>
            </div>
            <div class="pb-12"></div>
        {/if}
    </div>
</body>

<style>
    //trimmed down css to only include the header class
    header{
        position: sticky;
        display: flex;
        justify-content: center;
    }

as you can see, Svelte components and pages are just super-charged HTML that can be divided into three sections, content, css, and scripts.

And the best part about scripts in Svelte is that you can choose what kind of javascript you want to use depending on the context of what you’re working on. Have a lot of objects, types, and promises? use <script lang="ts"> to use TypeScript to enforce types on everything. Want to use pure vanilla javascript? <script lang="js"> or just <script>.

This kind of ability to customize how you want to work with Svelte is great, and there are a lot of parameters to mess with in your config file to customize how you want your website to function which is always welcome in my opinion, personally, I never needed to change anything beyond the default config, so I just left it as is, and I’m sure most people will be happy with the default config as well.

Also, groups are amazing, and the fact that I can create one +layout.svelte component and make it share the same layout across multiple pages in a group is something I’ve struggled with elsewhere; but not in svelte. Because of this, I can do things like sharing components or data across different pages without losing them, and you might have already seen this in action on this website with how the mouse cats never disappear or change their states when you load new pages.

Overall, I like Svelte because it feels like it tries to innovate on an already existing concept rather than create an entirely new programming language (php cough) or move it to an already existing one (javascript). I like to work on HTML stuff as if it’s an organized HTML doc that has left the early 2000s and is now in like 2.0 version, not a javascript function that returns an object that represents HTML for a build process to use that abstracts things away from me.

You can argue that HTMX is probably that innovation since it doesn’t require all the abstractions that Svelte has to do behind the scenes, and in some technical sense, you’d be right. But I haven’t used HTMX fully yet, and I’m not a blind shill for new technologies that promise to be the next big thing without properly testing and critiquing them.

You might have noticed that in my entire rant, I have not mentioned any of the major pros that Svelte and Sveltekit have; like smaller sizes of applications and no virtual DOM ever. Because what I like about Svelte is not its shiny features or how it works behind the curtains, I like it because it is clean, fast, and fits my style. It is a proper solution to the problem that I’ve had with React frameworks and their libraries. Ultimately, you should choose your tools based on your needs, workflow, and how pretty the things you’ll be writing are; and remember, beauty is subjective, and in this instance, I think svelte is prettier than doing export function MyComponent() => return (garbage)

But wait, how do you define fast? From an objective and technical sense, we can go by performance metrics and graphs with numbers that go up and down; but that would cause the biased crowd to screech on the legitimacy of the conducted tests, so I won’t show this graph of some performance tests between multiple frameworks.

“

Instead, I will speak about how your proficiency in your tools allows you to work fast. If you know how to utilize your tools to their fullest and know their limitations, you will find it easy to do whatever you want with them; even if said tool is satan’s dildo, and said dildo is spiked and can only work by forcing you to wait 30 seconds every time you want to use it to recompile your code… I’m definitely not speaking about the Unity Game Engine here.

I feel like I’m proficient enough in Svelte and SvelteKit now that I don’t need to spend time looking through the docs to achieve something, and thankfully; Svelte doesn’t have a lot of limitations, and you can interact with the DOM directly to do whatever you want.

Should we all stop using React and start using Svelte?

My inner fan-girl for Svelte says “YES”, but the logical side of my brain says no.

Svelte is very early in its lifecycle -in my opinion- and is still adding features from other frameworks like react in the form of things like snippets. It is not going to gain a huge following despite it being easier than React (in my opinion) due to it falling behind in some aspects that React Andys will constantly point out to make it seem like Svelte and Sveltekit are inferior to NextJS and React.

But who cares about that one intern who posts a lot of hot takes within his circle jerk of tech Twitter users? The real world should be our only measurement for these sorts of things! Well..

If we look at the real world, nothing will ever beat React in terms of popularity and how many jobs are open for it. A lot of companies have poured so much time and money into putting react as its standard that most of them will simply refuse to go through changing their entire workforce or train them to use this new toolset that has an entirely different workflow than what they’ve been using for years now.

Not to mention that Svelte’s ecosystem is still small. It exists, don’t let people lie to you about it not being there, but it is not as expansive as other libraries and frameworks. Though, in my opinion, that is a good thing because you don’t have to learn multiple UI libraries and can just stick to something like skeleton or flowbite since that’s what most people will be using.

Svelte also doesn’t have the best error messages, making debugging issues very difficult in a lot of instances. If you’re like me, and think that Rust error messages should be the standard of how errors should be communicated to developers; then you’ll quickly get annoyed about how Svelte handles some errors, especially the ones that it refuses to even acknowledge or warn you about during rendering. There are a lot of cryptic problems that go on, and you’ll be blind to most of it at a time until you start noticing behaviors that don’t match what you’re creating or when the entire app just turns white.

I’ve also spoken highly about how SvelteKit is highly configurable, but for most people, this can seem more annoying at first when they’re learning due to the sheer amount options that you can mess around with. It would be better if you could just set things like if you want a server-side rendering or statically rendered pages from the CLI tool on start rather than having to open the docs and find the right parameters to configure this later on.

But despite that, I 100% recommend that you use Svelte if you’re building a personal website or a web application. If you are also someone who has a team that doesn’t have a lot of experience with web development, recommend Svelte as the first toy to test and learn because the interactive Svelte tutorial is masterfully crafted and will turn you from a noob who barely knew how their web browser even worked to someone who can build a reactive website/application quickly within minutes.

What I learned from all of this

My goal was to learn why all websites take forever to load now and why they need to download a bunch of garbage, and I learned that by dissecting every method that is available to us now to make these websites.

I can now accurately shit on React and NextJS, and during the process, I managed to finally create a personal website that I’m satisfied with because the tool I used to create it with ticks every box in my brain on how modern web development should be.

I think a lot of people don’t get how spoiled we are with how simplified everything is nowadays, which makes our understanding of these technologies very rudimentary and harmful to us. I don’t have a single React project on my portfolio, but I probably have mastered React more than most React developers by digging through its guts and trying to see every step it tries to do along the way.

Svelte on the other hand, was so captivating and powerful, that I spent more time with it creating than gutting through it.. but then again, it invited me to do that a lot of times and gave me exact pointers on where to look at. So I didn’t have to set aside some time to look under the hood, because I naturally did that while I was working on this website.

Back in the day, we didn’t have luxuries like npm and modern frameworks. I remember back in the day when we had to install Apache and do a lot of manual setup to get our php hello worlds running which could take minutes of installing, but hours of troubleshooting and configuring. While today we just have things like Svelte that configure vite servers for you and the only thing you need to run your website is a single command, npm run dev.

I think ultimately, the reason why a lot of websites are garbage nowadays; is because they are built by people who don’t understand the technologies they are using. They just mindlessly follow YouTube tutorials and oversimplified documentation that doesn’t build the necessary skills for developers to think critically about how they should build their apps or websites. And if more people looked at React more critically by exploring how it works under the hood, they’d probably realize they’re better off just simply not using it or finding another library or framework that tries to introduce something new that improves their workflow even if it’s at the cost of something else.

If you don’t care about your tools, I’m not going to say that you’re a terrible programmer, but I’m going to assume that you write code that disregards the users’ hardware and their time. You might think that performance is not an issue unless you’re working on very important backend services, but your lack of understanding of how your tools can affect your app performance can indirectly result in creating functions that have a negligible impact at the start, but balloon into massive headaches for your users or even your development team once your project grows in size over time. I’m not asking you to start learning assembly and install Cutter, but what I’m asking is that you start questioning how your tools do things and how can you work in harmony with your tools.

This might sound like I’m directing a message at you, but not really. All of these are things I’ve learned in the past five years, and the best way I can communicate this from my head to you is to make it sound like I’m addressing you. I don’t know how to properly communicate info to anyone which makes me sound like I don’t know what I’m talking about at best or an asshole at worst, but in this whole blog post, I hope you can see my points and my thought process on why I prefer Svelte overreact. If you think that this is all just the ramblings of some pretentious Linux user who wants to sound smarter than they might be; then good. I want to be confident and stupid because people can then be annoyed about my confidence and try to come and correct me. However, don’t take this as me accepting your corrections without a stubborn argument.

Note: I intentionally kept switching ‘library’ with ‘framework’ and vice versa to annoy people and weed out those who haven’t read the whole thing before complaining to me about it.