This article is a collection of tips on terminal usage.

You aren't supposed to self-promote on HN

Sorry, I didn't know that.

Sapper provides a great option for routing. I view that as the official routing solution, but there are other options too.

But Sapper is server side, no?

I absolutely love Svelte ... and Sapper too! Here's a talk I gave recently on Svelte. https://www.youtube.com/watch?v=PXOE7oZyaBA

Testing for Svelte does exist! See my writeup on it here: https://objectcomputing.com/resources/publications/sett/july...

Oh, great! Thanks for the link. I had it on my to-do list to try something similar to what you did. Glad to learn from someone else's exploration.

I understand if you really want TypeScript support, but why do you feel the component model is hacky? I find it beautifully simple.

I elaborated below. A mix of the strict one component per file rule and the definition of props as a sequence of independent variables prevents a lot of patterns I use on larger projects.

The testing story just hasn't been well documented yet in the official docs. I have documented both unit and end-to-end testing with Svelte here: https://objectcomputing.com/resources/publications/sett/july...

Great link! Were you able to get unit tests with `context` working? Last time I tried (I believe with @testing-library/svelte) it didn't work because each component is compiled separately and don't share a runtime.

I haven't tried that.

Yes, but it is so much easier to implement Svelte components than components in Angular, React, or Vue. So much less code to write. No need to write classes, just plain functions, so no need for "this". Automatically scoped CSS. Very easy state management, both inside components and shared between components. And Sapper adds even more cool things like server-side rendering and code splitting with no configuration required.

A Svelte store can hold a deeply nested object. It's up to you how fine-grained you want the stores to be, anywhere from one store per value to one store for the entire application. I think a middle ground is best.

Yes you can, I didn't say otherwise. (I did criticize Vue though)

My point is that Svelte stores are tedious and ironically seem to go against Svelte's filosophy of lean code.

Here are the docs if anyone wants to take a look:

https://github.com/sveltejs/rfcs/blob/master/text/0002-react...

You can do complicated things with Svelte stores, but in my experience most of the time you only need something like this using a writable store:

<script> import {writable} from 'svelte/store'; const person = writable({name: 'Mark', zip: 63304});

  function handleChange(event) {
    const name = event.target.value;
    person.set({...$person, name});
  }

</script>

<input on:input={handleChange} value={$person.name} />

<div> Hello, {$person.name} at {$person.zip}! </div>

Of course if person is only used inside this component, you would not use a store. If it is used in other components, you would typically define and export the store in another .js file and import it everywhere it is needed.

My point is that this is a very simple way to share state between components and nowhere near as complex as the page you shared might indicate. That's because you do not need to use derived stores or custom stores. The simple writable store works in most cases.

Right but this is still a lot of code for changing the name of a person.

Also, this works with pojos and primitive values. What happens when you add class instances, relationships, children, etc?

For example in a project I was working I had geometrical figures in my reactive data model. With classes I could simply do:

    rectangle.getArea()

With MobX this was super simple to implement. If I wanted to change the position of the rectangle I would simply modify the x and y observable properties.

@pier25 You got me curious about this. I've never seen this done with Svelte, so I decided to try it. Check this out: https://github.com/mvolkmann/svelte-with-classes/blob/master....

The key is that when you update a Svelte store you must return a new value. It's enough to just return the value you updated. You see that happening here on lines 16 and 21.

I take your point that this is not as transparent as when using observables. But at least you can use classes that have relationships and call methods that modify the objects when those objects are in Svelte stores.

Exactly but this could become complicated pretty quickly.

Right now you have 1 update operation for an XY translate. What if you wanted to be able to change multiple properties of more complicated classes? You'd need more boilerplate for each update.

Like I said in a previous comment, my favorite approach right now is what Mithril and Imba do: no reactivity. You change your state and when you're done you tell the rendering engine that the state has changed.

https://mithril.js.org/redraw.html

https://www.imba.io/guides/essentials/state-management#state...

Since this is all vanilla you can do pretty much anything you want with your state. Mutable, immutable, etc. You don't need to add the weight and overhead of something like MobX/Redux/Vuex and you can add as much or as little bureaucracy/boilerplate as the project requires.

It seems like both Mithril and Imba do some form of DOM diffing. It’s easy because you just tell it to update the DOM using the latest state. Imba in particular says it has a really fast way to do that. But isn’t it that case that no matter how fast they can make it, it is still doing way more work than an approach that can determine what parts of the DOM need to be updated without DOM diffing?

Mithril uses a vdom so yes it's doing diffing. It's certainly slower than Svelte but it's still plenty fast for most use cases.

https://krausest.github.io/js-framework-benchmark/current.ht...

Most importantly Mithril is very lightweight. Check the startup metrics on those benchmarks. This is not a totally fair comparison since Mithril includes a router and an http client and the others do not. Still, it manages to be among the best.

Imba uses memoization and, much like Svelte, direct DOM manipulation.

https://www.imba.io/guides/advanced/performance

Imba was used to build Scrimba (an online code tutorial/editor) which is very impressive.

https://scrimba.com/

I couldn't get past the Ruby-esque syntax, but it is a very impressive effort.

You can create a custom store in Svelte and do almost the same:

import { writable } from 'svelte/store';

export default function(state) { const { subscribe, set, update } = writable(state);

  return {
   subscribe,
   getArea() { ... }
  };

};

HTML/CSS/JavaScript has no builtin state management and no two-way binding between state and form controls. Svelte makes those things very easy.

If you are referring to my article, "small footprint" is not the main point for me. The main point is ease development due to features like easier component state management, app state management with stores and sharing data between components with context.

To be fair to you I clicked on the article expecting a summary review rather than a technical run through and got as far as Why Consider Svelte on my small phone screen before googling. I can see on a revisit on my tablet it is rather more comprehensive.