Forem: v-moe

A comparison of CSS handling in popular JS frameworks

v-moe — Tue, 28 Mar 2023 13:58:54 +0000

Having been a Vue developer since the early Vue 2 versions has't prevented me from diving a bit deeper into a comparison of the trending new JS frameworks, especially Svelte and Solid which I both love for implementing the disappearing framework paradigm, pioneered by Svelte, refined by Solid, and announced to be available soon in Vue as well as Vapor mode. It's funny how so many developers say they prefer Svelte to the alternatives just because of it's elegant API, and Solid just because of the signals (available in Vue long before). Feels quite superficial to me ... But anyway, that's another story. Today I want to highlight one thing that in my opinion is a really strong argument to prefer Vue. Feel free to find it just as superficial ;-)

Imagine you have two components where one uses the other one. You want the root element of the consumed (child) component to come with an own class but be able to add classes from the consuming (parent) component

Class merging in Vue

It is as simple as this in Vue

// ComponentA.vue
<script setup>
import ComponentB from './ComponentB.vue'
</script>

<template>
<ComponentB class="a" />
</template>

// ComponentB.vue
<template>
<div class="b">Hello B</div>
</template>

Will lead to the desired html

<div class="a b"></div>

This happens thanks to the fact that any non-prop attribute passed to a component will be applied to the root tag of the used component plus some extra logic for the class attribute. It's worth noting that this behavior is highly customizable, for those who don't like it.

CSS class merging in Svelte

If you try to do the same thing in Svelte, it simply won't work

// ComponentA.svelte
<script>
  import ComponentB from './ComponentB.svelte'
</script>

<ComponentB class="a" />

// ComponentB.svelte
<div class="b">Hello B</div>

Typescript tells you why (if you are using it)
Type 'string' is not assignable to type 'never'
In other words, class is not a prop key of ComponentB

So you would like to fix it like this

// ComponentB.svelte
<script>
export let class;
</script>

<div class="b">Hello b</div>

But that doesn't work, class is a keyword in Javascript!

So what you have to do is change the prop name, let's follow a popular frameworks' naming:

// ComponentA.svelte
<script>
  import ComponentB from './ComponentB.svelte'
</script>

<ComponentB className="a" />

// ComponentB.svelte
<script>
export let className = '';
</script>

<div class="b">Hello b</div>

That still doesn't work (and wouldn't even work if class was not a keyword) since we have to merge the classes now.
I switch to typescript so that we don't forget to mention that in TS land you also have to tell the compiler it's a string, unless, as in this case, you have the empty string as default value and get inference as a nice side effect.

// ComponentB.svelte
<script lang="ts">
  export let className: string = ''
</script>

<div class={`${className} b`}>Hello b</div>

Quite some boilerplate, isn't it? Sure, if boilerplate does not scare you and you like the explicitness about where the props come from and where they go, no problem. But what if you have to consume someone else's component, imagine ComponentB coming from a library and having to author ComponentA. You can sure say that a component library that does not offer any API to add CSS classes to its components is flawed and that pull requests and issues can be filed, but this is always a slow process.

CSS class merging in Solid

The situation here is not essentially different from Svelte.

const ComponentB = (props: { class?: string }) => {
  return <div class={`${props.class || ''} b`}>Hello b</div>
}

const ComponentA = () => {
  return <ComponentB class="a" />
}

At least we may call it class here.

The solutions in a popular component library

The same problem applies to the style attribute for both Svelte and Solid (and also React, by the way), whereas Vue again smartly auto-merges with well defined behavior.

In MUI, the popular React material components library, the customization problem for inline styles is solved with the sx property. But try to add a class to the root element to an MUI component ... not so straight forward.

Conclusion

If you, like me, think that speed of development when adding classes to html tags is more important than having total explicitness about the props that determine the CSS of your components at the price of more boilerplate, you should consider this an important difference when choosing your framework for your next web app. Personally, I have never experienced that it was hard to debug where CSS classes or styles came from in Vue apps, so I can't imagine any benefit in doing it the way other frameworks do it.

Reducing JS code in your Vue bundle

v-moe — Fri, 27 May 2022 13:13:07 +0000

I recently got a typical task for a UI component library.
Creating an atomic video component.

Not hard to achieve, take an embed url for example one of those from Youtube and set it as the src attribute of an iframe.

As a requirement there should be a default width-to-height ratio on the iframe and the possibility to customize it.

The following code examples are simplified.

My first approach is probably what would occur first to every Vue dev put in front of this problem.

<script setup lang="ts">
interface Props {
  url: string
  ratio?: [number, number]
}
withDefaults(defineProps<Props>(), {
  ratio: () => [776, 437],
})
</script>

<template>
  <iframe
    :src="url"
    :style="{ aspectRatio: `${ratio[0]} / ${ratio[1]}` }"
  />
</template>

This exposes a nice API, wehere the customer can customize the ratio like this

<UiVideo url="somewhere" :ratio="[3, 1]"/>

But we have added a prop and silently a computed prop just for a CSS property value.

Not a big deal in an SPA but what if you are building a site where you want your JS to be as small as possible?

Well we could use Astro of course ;-)

But what if not?

A teammate came up with a great idea, it avoids the JS at the price of a tiny little bit of extra CSS!

<script setup lang="ts">
interface Props {
  url: string
}
</script>

<template>
  <iframe :src="url" style="aspect-ratio: var(--video-ratio, 776 / 437)" />
</template>

The extra prop is gone!
Consuming the component and customizing the ratio will now look like

<UiVideo url="somewhere" style="--video-ratio: 3 / 1"/>

You can also create a CSS class and apply that instead of using an inline style of course.

Really convenient! While I think that the first version is still a bit more developer friendly (TS + your IDE will suggest ratio as a prop when you start typing <UiVideo ...) the second does everything you actually need and is even cleaner from some point of view (CSS from style or class, data + logic from props)

In a big SPA where initial page load performance is not an issue, I would still prefer the first version though, maybe I still have to get used to this great pattern that leverages the power of CSS custom props.

Good documentation and a reliable CSS props naming strategy is absolutely necessary to make this scale and not become messy.

Two-way data binding for concise APIs in Vue. The dialog example.

v-moe — Thu, 19 May 2022 14:46:39 +0000

Two-way data binding is a controversial thing. Keeping the flow of data to be only from parent to child, is a beneficial thing when the time comes when you have to fix a bug in a complex application.
React has always been very strict about this, which leads to a pattern seen very often, for example in the popular Material UI library.

Imagine the situation where you want to create a component library, with a dialog component.

For simplicity our example will only have a button to close the dialog.

The parent component will have an additional button to toggle the open state of the dialog and the dialog component will be able to "close itself".

This is typically how this component would be used in React.

import React, { useState } from 'react'
import EasyDialog from './components/EasyDialog'

function App() {
  const [open, setOpen] = useState(true)
  return (
    <div>
      <button
        onClick={() => {
          setOpen(!open)
        }}
      >
        Toggle the dialog
      </button>
      <EasyDialog
        open={open}
        onClose={() => {
          setOpen(false)
        }}
      />
    </div>
  )
}

export default App

And this would be the component's code:

import React from 'react'

function EasyDialog({ open, onClose }) {
  return (
    open && (
      <div>
        <button onClick={onClose}>Close me</button>
      </div>
    )
  )
}

export default EasyDialog

It feels wrong that you have to tell the dialog to call onClose, a prop passed down from the App component to the dialog, doesn't it?

In my honest opinion this boilerplate is even worse than two-way data binding, here the child is de facto executing a method from the parent!

In Vue this problem does not exist, since we can create our custom two-way data bindings, also known as custom v-models.

This is how the equivalent app looks in Vue

<script setup>
import { ref } from 'vue'
import EasyDialog from './components/EasyDialog.vue'

const open = ref(true)
</script>

<template>
  <div>
    <button @click="open = !open">Toggle the dialog</button>
    <EasyDialog v-model="open" />
  </div>
</template>

Isn't this API a lot nicer? No need to pass any function to the child component, it's the child that emits:

<script setup>
defineProps(['modelValue'])
defineEmits(['update:modelValue'])
</script>

<template>
  <div v-if="modelValue">
    <button @click="$emit('update:modelValue', false)">Close me</button>
  </div>
</template>

So much more concise ...
Vue allows to do it, Svelte allows to do it, React probably never will introduce such ergonomics.

The React team has its reasons to do so and most React developers feel comfortable with this approach, so as a Vue developer I sure won't question this decision and just be a happy guy :D

Extracting reactive component logic in Svelte and Vue

v-moe — Fri, 13 May 2022 16:22:27 +0000

After having worked with Angular 1, React and Vue and following all the updates for a very long time I thought nothing would make me change my mind that Vue offers the best developer experience, both with options API and composition API.

Nevertheless, everybody who's not talking about Nuxt 3 coming soon or Remix or concurrent mode in React, well ... is talking about Svelte. And I must admit, after testing it out with the official tutorial I thought that this is the next leap forward until I thought OK, where are the mixins/composables/hooks?

A lot of articles out there explaining how to reinvent React's built-in hooks with Svelte but what about custom hooks or, since I am the Vue guy, custom composables?

While it's obvious that we can always fall back to a pure JS utils module for everything non-reactive, the value of reactive component-logic reuse that custom hooks or composables provide is an important factor when choosing your framework from a DX point of view.

So I chose a simple task to compare the code that needs to be written for having

a reactive object, with two props x and y, both numbers
a reactive computed value, the sum of x and y
a function that reactively doubles x and y
three reactive strings, a, b and c
a reactive computed value, the concatenation of a, b and c
a function to make all three strings a concat of themselves

Simple enough right? Could be some Vue composition API tutorial. And in fact it's very basic in Vue.

Why is it so hard to find similar examples for Svelte? Maybe because it's not the strong part of this in many respects great framework. Here is how I would do it.

import { writable, derived } from 'svelte/store'

export function useXY() {
  let a = writable('a')
  let b = writable('b')
  let c = writable('c')

  let word = derived([a, b, c], ($values) => 
      $values[0] + $values[1] + $values[2])

  function longer() {
    a.update((value) => value + value)
    b.update((value) => value + value)
    c.update((value) => value + value)
  }

  let xy = writable({
    x: 10,
    y: 20,
  })

  function doubleIt() {
    xy.update((value) => ({
      x: 2 * value.x,
      y: 2 * value.y,
    }))
  }

  let sum = derived(xy, ($xy) => $xy.x + $xy.y)

  return { xy, doubleIt, sum, word, longer }
}

Not so different in Vue

import { ref, reactive, computed } from 'vue'

export const useXY = () => {
  const a = ref('a')
  const b = ref('b')
  const c = ref('c')

  const word = computed(() => a.value + b.value + c.value)

  function longer() {
    a.value = a.value + a.value
    b.value = b.value + b.value
    c.value = c.value + c.value
  }

  const xy = reactive({
    x: 10,
    y: 20,
  })

  function doubleIt() {
    xy.x *= 2
    xy.y *= 2
  }

  const sum = computed(() => xy.x + xy.y)

  return { xy, doubleIt, sum, word, longer }
}

So what is my point here? If the difference here is not in the module file, is it in how it will be used in the consuming component?
This is the Svelte way:

<script>
import { useXY } from './store/xyStore.js'

let { xy, sum, word, longer, doubleIt } = useXY()
</script>


<h2>{$xy.x} {$xy.y}</h2>
<h3>Sum: {$sum}</h3>
<h3>Word: {$word}</h3>
<button on:click={longer}>Longer !</button>
<button on:click={doubleIt}>Double it!</button>

And this is how to use it in Vue

<script setup>
import { useXY } from './composables/useXY'

let { xy, sum, word, longer, doubleIt } = useXY()
</script>

<template>
  <h2>{{ xy.x }} {{ xy.y }}</h2>
  <h3>Sum: {{ sum }}</h3>
  <h3>Word: {{ word }}</h3>
  <button @click="longer">Longer !</button>
  <button @click="doubleIt">Double it!</button>
</template>

Not so different either, except for the ugly $s, funnily the Vue reactivity transform likes the $ too.

But what I think is really annoying in the Svelte model is that if you want to refactor your code and move this logic back into your component you actually have to rephrase it all.
And moving the logic out of the component logically has the same problem, just the other way round.
This is what it looks like:

<script>
  let a = 'a'
  let b = 'b'
  let c = 'c'

  $: word = a + b + c

  function longer() {
    a += a
    b += b
    c += c
  }

  let xy = {
    x: 10,
    y: 20,
  }

  function doubleIt() {
    xy = { x: 2 * xy.x, y: 2 * xy.y }
  }

  $: sum = xy.x + xy.y
</script>

<h2>{xy.x} {xy.y}</h2>
<h3>Sum: {sum}</h3>
<h3>Word: {word}</h3>
<button on:click={longer}>Longer !</button>
<button on:click={doubleIt}>Double it!</button>

For the Vue version you literally just copy paste and remove the export/return boilerplate lines!

<script setup>
  import { ref, reactive, computed } from 'vue'

  const a = ref('a')
  const b = ref('b')
  const c = ref('c')

  const word = computed(() => a.value + b.value + c.value)

  function longer() {
    a.value = a.value + a.value
    b.value = b.value + b.value
    c.value = c.value + c.value
  }

  const xy = reactive({
    x: 10,
    y: 20,
  })

  function doubleIt() {
    xy.x *= 2
    xy.y *= 2
  }

  const sum = computed(() => xy.x + xy.y)
</script>

You don't even need to change the template as opposed to the Svelte version!

I have to admit though that the Svelte version really does look more elegant if you don't have any need to extract this logic anyway.
But if you are developing a complex app in an incremental way, extracting your component logic to an external module to be reusable by other components is what you will do on a weekly or even daily basis.

Talking about the learning curve ...

At first sight Vue seems to be a lot more convenient, learn once, use twice. But then ... very soon you will need to learn how to deal with global reactive state and then ... you will have to learn a new thing, most likely Pinia if it is a new project.

In Svelte instead all the same syntax used for the logic extraction is also used for stores! Just let your components share one writable and you're done.

That said, in Vue you can do just the same thing and use a global shared reactive as a store. Having Pinia (and the great Vuex before it) is a powerful tool to scale up! Svelte without a dedicated store solution ... don't know if that is easy to keep as structured when the project starts to need a lot of global state.

To wrap it up, if I had to choose between the two frameworks just based on developer experience (not the technical stuff like bundle size, performance, execution model etc.) I would surely go with Vue if I needed many, many composables and with Svelte if I had none and no need for them.