mvolkmann

Sorry, I didn't know that.

This article is a collection of tips on terminal usage.

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

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?

@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.

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.

I haven't tried that.

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...

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

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...

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.

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.

You said "My personal view is that the 'what' in frontend development generally isn't super interesting and most web frontends are very similar." I think if you take a serious look at Svelte you will see that it is much simpler than the current popular web frameworks.

If your most pressing issue is making managing state easier, you should run to Svelte! Take a look at how Svelte supports "stores", "context", and state within a component. Those are so good that I predict nobody will ever feel the need to write a state management library for Svelte. It's already very easy!

Here is the issue that describes what the Svelte team is doing to add support for TypeScript: https://github.com/sveltejs/svelte/issues/1639

Not true. That section mentions several other "Whys" including this: "Svelte dramatically simplifies component and application state management. Contributing features include context, stores, and module context, each of which is covered in detail later."

If you want to get up to speed on Svelte quickly, read this! https://objectcomputing.com/resources/publications/sett/july...

If you like templates and framework-specific syntax for conditional logic and iteration sprinkled into your HTML then you will love Vue. If you prefer the JSX approach and relying on JavaScript for conditional logic and iteration then you will love React. Vue does support JSX, but it is not the idiomatic way to use Vue.