Modified: 2022-10-31 Published: 2022-02-28

Make Svelte better

Logic blocks syntax

The current syntax is weird and hard to remember, especially for beginners.

{:else if}





Let’s use a simple and clean syntax like the example below.

{@else if}
{@endif} // OR {@end}

{@endeach} // OR {@end}

{@endawait} // OR {@end}

{@endkey} // OR {@end}



We use the $ symbol for stores, so I think it will be confusing for beginners if we also use it in aliases. Some may try using a store variable like this:

import { readable } from 'svelte/store'
const components = readable('/src/lib/components')
import MyComponent from '$components/MyComponent.svelte'

Let’s use the same @ syntax here too:

  import MyComponent from '@components/MyComponent.svelte'

This will make Brittney so happy😄.

class prop

I don’t know about the technical things. Let’s think about the simplest thing that the compiler can do. So, I’m a compiler and I look at this component:

	import MyComponent from './MyComponent.svelte'

<MyComponent class="my-class" />

	.my-class {
		display: block;

… and I see that there is a component with a prop named class. So, now I know that this is a class attribute. Now I need to don’t remove the .my-class styles and also make it scoped like a normal class attribute.


The problem is that you can’t write a comment inside another comment. The examples below will not work!

<!-- <p>
	<!-- <span></span> -->
</p> -->
/* div {
	/* display: block; */
} */
/* function add() {
	/* console.log() */
} */

What is the solution?

Make it possible to the above examples. Also, make it possible to use JavaScript comment syntax (//) in HTML and CSS too.

CSS scope

Styling in Svelte is kinda limited, read more here Svelte : 6972.


We absolutely need a feature to be able to disable all A11L warnings on the Frontend and the Terminal) from everywhere at once. And we may also need to be able to disable them one by one, so if there was a mistake with the warning, we can easily just disable it.


Manual refreshes

Sometimes when you change something in a layout file, it doesn’t automatically get updated on the browser, so you need to refresh the page manually.

Limited slot functionality

Right now you can only use the basics of slots, you can’t use named slots, slot fallbacks, optional-slots and slot-props.


Pass data between page and layout

You can’t pass data from a page to its layout or vice versa.


Change the name to something meaningful.

Dynamic classes

<div class:bg-brand={condition} />
  • ❌ It’s not standard because classes need to be added after the =.
  • ❌ Can’t use multiple classes so you need to use a different syntax for adding multiple classes.
<div class={condition ? 'bg-brand rotate-45' : ''} />
<div class="{condition ? 'bg-brand rotate-45' : ''} text-white" />
  • ✅ You can use multiple classes.
  • ❌ Boilerplate.
<div class="{condition && 'bg-brand rotate-45'} text-white" />
  • ✅ Clean.
  • ✅ You can use multiple classes.
  • ❌ If the condition doesn’t pass, then a false class gets added.

What is the solution?

It’s simple, just don’t add the false class if we use this syntax:

<div class={condition && 'bg-brand rotate-45'} />
<div class="text-white {condition && 'bg-brand rotate-45'}" />

Deprecate this syntax in Svelte v4:


Port is already in use

If you try to run multiple SvelteKit apps at the same time, you will get this error:

Port 3000 is already in use

Dynamic HTML tags

This feature is now available 👏.

  let tag = 'div'

<svelte:element this={tag}>

Change the this prop name to tag, because what if we also want to bind the element to a variable? Example:

  let tag = 'div'
  let element


It works, but it looks like we accidentally added a prop twice!


Documentation content and the design needs a rewrite and a redesign. There is a lot of content missing in the docs It’s the year 2022 and we don’t have a freaking Dark Mode! A proper way of accessing and searching content. Algolia sucks because it’s not accessible it some countries like Iran, so need to use a VPN to be able to use it!

Better error handling

It’s absolutely disgusting how Svelte handles errors! Basically, you don’t know what the hell is going on.


Wordpress is an old tool that doesn’t do a lot of things right, but here I see a lot of people talking about using JSON files for translations😐🔫. Read more here.

This is the way that I want to do translations:

  1. Wordpress way of handling the translations.
  2. I don’t want to use a JSON/JS file and add the translations manually.
  3. I want to use software like PoEdit to add/edit/remove translations easily with the power of the community’s previous translations, AI-like features, and Google Translate.
  4. I don’t want to use a syntax like {@t 'Hello, World'} because it’s hard to write and it’s not clean and not readable.

Basic example

<p>__('Hello World')</p>

It works the same as this:

echo __( 'WordPress is the best!', 'my-plugin' );

I don’t know about the second argument. We probably need it if there is any translation needed inside the public components and resources like that, so the translations won’t get messed up/mixed up with each other. If no text_domain(the second argument) were passed, use the default app translations (instead of not translating it like Wordpress), I guess.

Using with variables

<p>__('Hello {name}')</p>

It works the same as this:

  __( 'Your city is %s.', 'my-plugin' ),

But it will use the variable name as a placeholder instead of the %s nonsense, and it doesn’t need an extra function to wrap it around.

Don’t escape HTML

<p>_html('<span>Hello World</span>')</p>

It won’t escape HTML tags anymore, the same as {@html}. The same functionality needs to be available with other translation functions, for example, _x_html().

I was thinking, what if the user is able to use markdown for things like making the text bold, italic and etc? Just something to have in mind.


  'There is {count} item',
  'There are {count} items',

Disambiguation by context

<p>_x('Post' ,'noun')</p>
<p>_x('Post' ,'verb')</p>
<p>_u('Hello {name}')</p>

Allows us to have the same translatable strings with a different translations.

Not neeeded

Why this syntax is better?

  • It’s much more readable, clean, and easy to write and remember in comparison to other solutions.
  • It uses __ instead of t because it’s a known standard for translation.
Return to top