## Rant

"Hey look, I like Svelte, but the ecosystem is smaller than React, so that's why I'm not going to use Svelte (SvelteKit)". This is the same message you might find on Reddit, Twitter, or even YouTube comments - the same copy pasta. (Not exactly word by word, but the idea remains.) It begins to become annoying and frustrating when you give people options to choose from, and their only argument is the "smaller ecosystem." And the truth? That is mostly a lie. SvelteJS ecosystem isn't even that small compared to React. Yeah, you are correct if you say that Svelte doesn't have that many UI component libraries, but even for that, there are options (SkeletonUI, Flowbite Svelte, Svelte UI, DaisyUI). And if you want to have more UI component libraries, go make your own UI component library in Svelte, publish it, and then wait for someone to find it and say, "Hey, this UI component library is bad, I'm going to create a better one."


## State Management

But let's forget for a minute about UI component libraries and move closer to the real problem. Let's take it bit by bit. Now, when I'm going to start my ReactJS project, what libraries do I need to import first? Tailwind? That is a generic library, so it works on SvelteJS. Oh, I know, a state management library. No one wants to use useReducer, so let's get a better library.

In ReactJS, there are so many options for state management: Redux Toolkit, Jotai, Zustand, MobX, and a lot more. In SvelteJS, we don't have that many state management libraries, but we have svelte/store, a lightweight state management API that comes built-in with SvelteJS. From the start, we get a solution for a problem. Instead of searching for a solution, we can use that time to build something useful.

## Styling

Okay, we solved state management, let's move to some styling. Now I want to scope my styling to a component so that we keep it up backed with the components we write. React has a solution for this: CSS modules. But we are cool and hype, and we want to have the styling in the same files as our JSX. To solve this, we need to choose a library from the list of CSS-in-JSS libraries. Let's see our options: styled-components, CSS-Modules, Emotion, JSS. With Svelte, we get this directly built into the framework, the `<style></style>` block.

## Transitions ?

I want to have some cool transitions for my dream startup page. Let's see our options in ReactJS: React Transition Group, React Motion, React Move... For Svelte, we don't need a library because the framework comes with a transition API right from the start.

You probably start to see a pattern here. SvelteJS doesn't have that many libraries because most of those problems are solved by the framework itself.

## Other JS libraries

But maybe what I said before is a half-truth. Our app needs more than state management, style libraries, UI components, transitions libraries. Maybe we want to use some custom library.

Let's see how hard it is to use some random library inside Svelte JS and compare it to React.

### ag-grid

I've chosen ag-grid as the first example.
The example on the `README.md` looks like this:

And our implementation in SvelteJS isn't that different from the one in the `README.md`

<script lang="ts">
  import { Grid } from "ag-grid-community";
  import { writable } from "svelte/store";

  const rowData = writable([
    { make: "Toyota", model: "Celica", price: 35000 },
    { make: "Ford", model: "Mondeo", price: 32000 },
    { make: "Porsche", model: "Boxster", price: 72000 },
  ]);

  let gridOptions = {
    columnDefs: [
      { headerName: "Make", field: "make" },
      { headerName: "Model", field: "model" },
      { headerName: "Price", field: "price" },
    ],
  };

  let gridElement: HTMLElement | undefined;
  let gridObject: Grid;

  $: {
    if (gridElement != null) {
      gridObject = new Grid(gridElement, {
        ...gridOptions,
        rowData: $rowData,
      });
    }
  }
</script>

<div class="ag-theme-alpine grid" bind:this={gridElement} />

We are following the example almost bit by bit, and we just added a way to create the grid object when the gridElement reference is obtained, and a way to manage the state reactively. And we didn't need a React wrapper on top of the base library to make things work.


### chart.js

Okay, we got data tables, what about some charts? If you need charts in React, you probably are going to use react-chartjs-2. We don't need a wrapper in Svelte; we can just use the library as it is.

<script lang="ts">
  import Chart from "chart.js/auto";

  let ctx: HTMLCanvasElement | undefined;
  let chartObject: Chart | undefined;

  let data = [12, 19, 3, 5, 2, 3, 10, 20, 3, 9, 200, 9, 1, 2];

  $: {
    if (ctx != undefined) {
      if (chartObject != undefined) {
        chartObject.destroy();
      }

      chartObject = new Chart(ctx, {
        type: "bar",
        data: {
          labels: [
            "Red",
            "Blue",
            "Yellow",
            "Green",
            "Purple",
            "Orange",
            "Purple2",
            "Val2",
            "Graph2",
            "Dap",
          ],
          datasets: [
            {
              label: "# of Votes",
              data: data,
              borderWidth: 1,
            },
          ],
        },
        options: {
          scales: {
            y: {
              beginAtZero: true,
            },
          },
        },
      });
    }
  }
</script>

<div>
  <canvas class="chart" bind:this={ctx} />
</div>

You see, it isn't exactly hard to use the library as it is. We just need to take into account the reactive model so we can destroy and recreate the Chart object when our data set is changed. And even that isn't hard to understand. No useState, no useEffect, no useMemo.

## Conclusion

I could probably write a book just about comparing React wrappers to simple library usages in SvelteJS. And I'm sure that most of the points presented could be easily "owned" by someone smarter than me, but the truth is that with React, you don't learn to use the underlying library, you learn to use the wrapper. We keep writing wrappers for things that already exist, then we go on Twitter and make memes about how many JS libraries appear per minute. Then we make more ReactJS wrappers that use other ReactJS wrappers, and in the end, we have a Jenga tower where just one brick needs to fall for everything to collapse.