DEV Community: RATIU5

I Don't Like Existing CMS Options, So I'm Building a New One

RATIU5 — Wed, 18 Dec 2024 02:30:01 +0000

Here is a ~~complete~~ incomplete list of ~~all~~ most CMS solutions:

Why the Heck Are You Building a New One Then?

Good question. There are a plethora of CMS options to choose from, and many of them are free. What's the point in creating a new one? Can't you just make any one work for my use case?

That's it! I have to make it "work for my use case", which really means I need to bend and twist existing solutions until they fit perfectly with what I got. Or I need to pick a CMS and use their recommended technology stack. At some point, you have to ask yourself: wouldn't it be more efficient to use something that aligns with my workflows and technology stack?

I sure have. And that's where the idea came from: Why not add another to that list?

The Current Ecosystem

(Photo by ben o'bro on Unsplash)

Honestly I didn't think that was a good idea at first. Each CMS that's out there already solves a problem, but they all seem to solve it with their own set of trade-offs and compromises. After years of working with different systems, I've noticed a pattern: we keep accepting these compromises as "just the way things are" instead of questioning whether they need to exist at all.

I'm not going to build some magical perfect CMS that does everything for everyone. After time and time again fighting with CMS solutions that either don't understand component-based development or force me to completely change how I work, I'm building something different. I want a CMS that actually gets how we build modern websites and fits naturally into our workflow, not the other way around. I want components, man!

"Hey, what about Builder.io or Prismic?" I hear. "They let you build components and schemas right out of the box!" And you're absolutely right - these platforms have made huge strides in the right direction. I've used both, and there's a lot to love about their approach.

But here's the thing that keeps nagging at me: while they're great for certain use cases, they start showing their limitations once you scale up: their cost per page view or per user. Plus, even with all their features, I still found myself wanting just a bit more control over how everything worked together.
Don't get me wrong - they're solid platforms. But I think we can push this idea further without requiring developers to empty their wallets just to handle growing traffic.

"But wait, what about Payload? It's open-source and has all those features you mentioned!" I hear you. I've been down that road. And yes, Payload is impressive, I actually really like the work their team has done. I just wish I could love it. On top of many issues I faced getting it setup and working for me, I noticed a trend with Payload as well as many others: any CMS that tries to be super flexible while also being simple to use ends up sacrificing something. I've yet to find a CMS that manages to thread that needle perfectly, and honestly, maybe that's okay. Maybe we need to accept that different tools serve different needs, and we need to find the best tool for the job.

Nope, not me. I think we can do better.

My Proposition

Call me crazy, I think there is a better solution. A solution that already exists in different forms, but has proven its worth in other areas of development: composability. The idea that small, focused pieces can be combined to create powerful systems that are both flexible and maintainable.

Let me introduce to you (if you haven't already met), Astro and Medusa. These are two amazing feats of engineering. These two projects are built around modularity, especially Medusa. It's simple: you start with a core foundation that handles the essential functionality, and then you can plug in exactly what you need, when you need it. No bloat, no unnecessary features weighing down your project.

This is exactly the kind of thinking we need in the CMS space. Instead of trying to be everything to everyone out of the box, be a solid foundation that developers can easily extend. A CMS that follows these principles could start lean and grow precisely in the direction any project needs, without forcing developers to work around features they'll never use or features they require.

Quick shout-out moment!

If you have not tried out Astro as a modern web development solution for your site, give it a try! Medusa is an amazing product for a complex or custom e-commerce experience! This CMS would not exist without heavy inspiration from these two tools.

What Will Make This CMS Stand Apart?

(Photo by Ashkan Forouzani on Unsplash)

As I stated before, it all revolves around the principle of modularity and composability. Small, independent pieces that fit nicely together, like a puzzle. This core detail will help shape the future of this and hopefully many more CMS solutions.

Let's look at what core modules I'm planning to feature:

Objects: Small key-value pairs of any standard data type: strings, numbers, booleans, arrays, and of course, other objects. This provides the foundation for anyone to create any data type.
Documents: Documents are essentially larger objects, with special formatting and extra features. Documents are made up of a custom template or schema, which define what data fields will exist. Data can be entered for each of those fields, specific to their own data type.
Media: Simply put, file uploads. A perfect place to store images, videos, documents, and more all with metadata and attributes.
Widgets: Widgets are pieces or sections of a website. They can be considered as documents with a twist: they have a custom renderer. This renderer enables a widget to be converted from a component template (ie. Astro, React, Vue, Svelte) into rendered HTML by the framework of your choice.
Pages: Pages work will with widgets, allowing you to put together documents and widgets to form a page, perfect for any modern site. Pages also can be rendered to output page previews with whatever technology stack you are currently using.

These modules will provide the foundation for many new and unique data structures defined by the developers, all of which are extendable via plugins.

What's In It For Me?

This is an ambitious project, and I'm well aware of the challenges that lay ahead. I've decided to document every step of this journey openly, from the initial architecture decisions to the inevitable roadblocks I'll face. My experience has taught me that even failed projects can be valuable learning opportunities for the developer community. When I was starting out, I learned lots of valuable lessons from other developers who were open about their struggles and decision-making processes.

I'm putting my heart into this project because I genuinely believe it can succeed. My goal isn't to build another CMS, but to demonstrate that we can challenge the status quo when we see problems worth solving, even if we are the only ones with that problem (honestly, if we've faced a problem before, I can almost guarentee someone else has faced that same problem ;) ). If this CMS takes off, that's fantastic. But even if it only serves to inspire other developers to tackle ambitious projects they care about, or helps someone else build a better solution down the line, I'll consider that a win. After all, every innovation in our field started with someone looking at a problem and thinking "I believe there's a better way." Which leads me to the actual project.

Introducing LuxeCMS

The project has taken the name of LuxeCMS, and will be a 100% open-source project.

https://github.com/luxeCMS/luxe

Just to be transparent, this is still in its early stages and nowhere near ready for real-world use yet. But I'm excited to connect with other developers who've faced the same CMS frustrations I have. My hope is that together, we can build something that actually addresses the pain points we've all experienced firsthand.

If you are excited about the potential future of this project, consider giving it a star! And if you're interested in contributing to or sponsoring this project, reach out to me on our Discord server and let's chat!

I'm excited for this opportunity to grow as a developer, and to build a community of like-minded individuals to bring something new to the world! If you've experienced pain points of existing CMS solutions or are excited about this project, comment down below!

If you want to follow updates on LuxeCMS, consider following us on X/Twitter.

Implementing Signals from Scratch

RATIU5 — Thu, 28 Sep 2023 00:45:34 +0000

What Are Signals?

Recently, the JavaScript community has been buzzing about signals. Their rise in popularity can be traced back to Solid.js, which drew inspiration from Knockout.js' Observables to craft their version of signals. Not long after, prominent frameworks like Preact, Angular, and Qwik integrated signals into their core. Vue 3 introduced its distinctive take on signals with ref and reactive (although they are not signals in the same context as Solid.js' signals), while Svelte 5 unveiled the Svelte Runes which is fundamentally built on this type of reactivity. For the purpose of this article, I'll use the term "signals" to describe these reactive systems. With that said, what the heck are signals?

Signals are basic units of data that can automatically alert functions or computations when the data they hold changes. This alerting capability allows parts of a system to automatically and immediately update when the data changes, making the system feel dynamic and real-time. The problem this solves is updating something visually when some data changes behind-the-scenes.

When data changes, a function is triggered to update a specific element on the DOM. Solid.js achieves this with fine-grained reactivity. This ensures that your code directly updates only the specified value, avoiding unnecessary side effects or redundant re-renders of other DOM elements. With a defined reactive system in place, you can build large-scale and maintainable web applications with ease.

How Do Signals Work?

Let's look at how signals work under-the-hood. I will be referring mostly to Solid's functional approach of signals, although a class-based solution wouldn't be too different. The signal function we will be creating today isn't going to be as performant or feature-full as with many frameworks, but should serve instead as a starting point to understanding signals at a low level.

Functions and Closures

Before we look at signals, it's important to have a grasp of how JavaScript handles functions. Let's dive deep into how those work, starting with the following code:

function createSignal() {

}

Let's dive in. The function createSignal is stored in JavaScript's global memory. Simple enough, right?

Next, we'll embed a variable within our function and return another function to retrieve this value.

function createSignal() {
  let value = "Hello, World";
  return function() {
    return value;
  }
}

Our function now gets a little more complex, and shows the creative inner workings of JavaScript. By invoking:

let signal = createSignal();
signal();

We initiate a fresh execution context for createSignal. Within that context, the string "Hello, World" is assigned to our context's memory under the value label. When we return the new function, a closure is created that holds the value data, and is stored alongside the returned function. This allows us to have persistent storage of our value across execution contexts.

Upon invoking the returned function, JavaScript sets up a new execution environment. Since it doesn't immediately spot the value variable, it consults the closure, locates value, and duly returns it.

Now, let's modify our function. We will now return an object with a setter function and the value. Then we will add a parameter that receives a default argument for our value as well.

function createSignal(initialValue) {
  let value = initialValue;
  return {
    value,
    set: (v) => { value = v; },
  }
}

We have one problem. Because we are returning the value variable within our object, it remains unchanged even after calling our set function. This happens because the value we pass to the object is a copy of the value at the point in time where we return the object from the function. Hence we need to write a dedicated getter function for the value.

function createSignal(initialValue) {
  let value = initialValue;
  return {
    get: () => { return value; },
    set: (v) => { value = v; },
  }
}

It's coming together! Let's try using it.

let signal = createSignal(10);
console.log(signal.get()); // 10
signal.set(20);
console.log(signal.get()); // 20

One thing that stands out is the need to call a set and get function each time we read or write to the value variable. Let's improve this by using JavaScript's get and set functions.

function createSignal(initialValue) {
  let _value = initialValue;
  return {
    get value() { return _value; },
    set value(v) { _value = v; },
  }
}

Now we can use our function as such:

let signal = createSignal(10);
console.log(signal.value); // 10
signal.value = 20;
console.log(signal.value); // 20

A bit more readable, eh? We still have one problem: it's not reactive. No "effect" happens aside of the _value changing states when we call the set function. This is where we will create a subscriber.

Subscribers

A subscriber will "subscribe" a function to run some code whenever our _value changes. To do this, we will be making use of our get function.

function createSignal(initialValue) {
  let _value = initialValue;

  function notify() {

  }

  return {
    get value() { return _value; },
    set value(v) { 
      _value = v;
      notify();
    },
  }
}

What's happening here? Whenever the set function is called (aka. we reassign the value signal.value = "hello";), we will run a function. This function will then call the subscriber function... which means we also need a subscribe function as part of our return. While were at it, let's accommodate for multiple subscribers and then call them within our notify function.

function createSignal(initialValue) {
  let _value = initialValue;
  let subscribers = [];

  function notify() {
    for (let subscriber of subscribers) {
      subscriber(_value);
    }
  }

  return {
    get value() { return _value; },
    set value(v) { 
      _value = v;
      notify();
    },
    subscribe: (subscriber) => {
      subscribers.push(subscriber);
    }
  }
}

The Finished Signal

And with that, we have a (very) basic signal! Let's see how we will use it:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>Signals from Scratch</title>
</head>
<body>
  <span id="mySpan"></span>
  <script>
    function createSignal(initialValue) {
      let _value = initialValue;
      let subscribers = [];

      function notify() {
        for (let subscriber of subscribers) {
          subscriber(_value);
        }
      }

      return {
        get value() { return _value; },
        set value(v) {
          _value = v;
          notify();
        },
        subscribe: (subscriber) => {
          subscribers.push(subscriber);
        }
      }
    }

    const mySignal = createSignal("");
    mySignal.subscribe((value) => {
      document.getElementById("mySpan").innerHTML = value;
    });

    mySignal.value = "Hello World!";
  </script>
</body>
</html>

What's happening here is we defined a variable mySignal to hold our reactive signal. We call the subscribe method on our returned and bind a function that will be called whenever our value setter is called which will in turn update the DOM. Now whenever we set the value of our signal, our subscriber is notified and the DOM is updated!

At the root, this is what's happening with signals. Of course, frameworks implement lots of additional features like derives and effects. In Solid's case, they make use of additional improvements to performance with the use of subscriber cleanups and a compilation step to check where you use the getter within your JSX and create the fine-grained update code from that.

That's it! If you notice any mistakes, please let me know in a comment and I will do my best to fix it. Feel free to give your thoughts and improvements to this as well!

Beginners should use a preconfigured Neovim distribution

RATIU5 — Wed, 23 Aug 2023 19:52:06 +0000

I believe that beginners to Neovim should use a preconfigured distribution. I'm talking about distributions such as LunarVim, NvChad, AstroVim, or LazyVim, among others.

I've used everything from my own minimal configurations to huge, sometimes bloated, distributions like LunarVim. From my experience, I still believe that those starting out should look toward using a preconfigured distribution and at a later time tailor their own.

A Whole New World

Coming from a "managed" editor, newcomers may get overwhelmed with the sheer number of choices that come with Neovim. Unless you use Arch (btw), then you're used to it. A preconfigured Neovim setup lightens the configuration load.
My main complaint about the ecosystem is that it's too vast; the countless plugins, unlimited configurations, and the knowledge needed to get started is bewildering. That's where a preconfigured distribution comes into play.

These configurations act as curated showcases, offering a glimpse of what plugins and configuration types are available. By trying different distributions, you figure out which plugins and settings resonate with your unique coding style and requirements. It's like finding the right pair of shoes in an infinite store; each fits and feels differently, and you'll never truly know what's comfortable until you've tried several.

Monkey See, Monkey Do

The exposure to different types of configurations helps guide newbies on different ways to write their own. I know that after looking at several different formats I found what stuck to me. Yes I am referring to using other's configurations as a reference too. Try them out first, then delve in deep and see how it was done.

By exploring different Neovim configurations, you get inspiration from the tried-and-tested configurations. After some time, it is easy to modify the configurations a little more to your liking.

Don't Stop There

I still believe that after trying out multiple Neovim distributions, is to write your own. At this point, you know what exists, and what you like. You've seen examples of how everything is glued together. And you've graduated from Beginner Academy. A super easy way to start would be to use Kickstart.nvim. This configuration is very minimal and all contained within one file, meant for a launchpad for your own configuration.

I don't think that sticking with one distribution forever is the best idea. You get used to another person's particular setup and feel, which may not reside completely with you. When you write your own, you get an even deeper understanding of your editor and how it all works. When something goes awry (and things are bound to do so, what do you think this kind of work is about?), you can figure out pretty quickly how to resolve it since you built it.

This is my opinion, I am not responsible if your feelings were wounded throughout this read.