Svelte is a language (opens in new tab)

> I don’t follow… in what sense is this JavaScript? > <button on:click={incrementCount}>

it's not. it's html. incrementCount is a pointer to a javascript function.

> Or what about this… is this JavaScript? > $: doubled = count * 2;

Yes. $: is a javascript label. We use it to indicate that a function should be reactive - if the count variable changes, the right hand will be rerun and double updated.

> <button on:click|once={handleClick}> Click me </button>

html again. the |once is a modifier to click which detaches the handler after a single use. It's a directive in the html markup (still valid html) which the compiler picks up and converts into node.removeEventHandler.

Author means explicit after compiling.

Reminds me of Angular

I've got mixed feelings about this and I'm sure I'm in the minority. Those adapters are usually supported by the commercial company that wants you to use them. But, for example, the static or node adapters often don't work great with the important parts of svelte kit like SSR, and feel like second class citizens.

I love svelte but I'm having a hard time getting the same development ergonomics out of svelte kit. It's probably just me.

Infrastructure adapters are becoming table stakes for frontend frameworks.

Never been excited in the least by it. Being too clever imho. Problem is: I don’t often get to dictate what we use so there I am, caught in the web.

not everybody was excited about the virtual dom. people who looked closely at it weren't particularly excited.

Browsers are not the same as they were ten years ago.

Agreed, I want markup in my logic — not logic in my markup

I've done a lot of contracting jobs and I get to see a lot of codebases and had the exact opposite experience, Whenever I see react or vue code, and in particular react, I feel like I have to relearn everything because the combination of external state libraries and to top it with translation specific code and libraries makes it such that each code base is very different from the other. It almost feels like you are learning a new framework altogether. The other issue is not directly related but because there are so many external dependencies, there is this constant slog work to keep everything updated due to constant vulnerabilities that keep popping in our CI tool.

Familiarity wise Angular has been probably the easiest to jump into and maintain long term, but it is a pain to work with due to the amount of ceremony involved to do even the simplest of things.

Svelte codebases due to the very nature of Svelte are simpler and very straightforward to get into, there are some svelte specific things but they aren't too many of them and are simpler to reason about when compared to codebases built on hooks, and even worse are hooks in combination with junior Devs. It is very very easy to write bad react code and you see this way way too often. Most react code out in the wild is badly written, you don't see problems because the browsers and modern computers are performant enough to hide them away but you do notice as the codebase grows and you realize it too late that the very foundation was wrong.

I don't mind Vue and just see svelte as a nicer DSL over it.

You can create a shared store and mutate it from any component, not sure what’s missing there.

Big ball of mud. The muddiness is always exacerbated when increasing the number of developers, especially when they disagree on Hooks.

One thing is that sveltekit is a “batteries included” opinionated framework. Everything you need is there, the docs are excellent, you don’t need to make any decisions to get the fundamentals of routing, stores, directory structure, and other basic things working. This is the opposite of the traditional nodejs / JavaScript ecosystem of selecting a hodge podge of libs to get even a minimal thing going.

react didn't invent that syntax. This is a standard piece of C like syntax that most (but not all) languages with curly braces share. JSX/TSX used in react don't make this choice for you, you can use any javascript syntax which can be used when passing a value (eg in a function invocation, or variable declaration). If you don't like it, you are perfectly free to declare a variable and set its value using a regular if / else block and use it directly from the template.

My point is this is not a syntax decision that React made, but svelte's syntax was (as far as I can tell) a decision.

I don't know should I stick to mustaches (it can be dictated by other reasons), but if I should: {#if expr} {#elseif expr} {#endif}

I much prefer keeping everything XML-ish:

https://www.solidjs.com/docs/latest/api#switchmatch

I think it is a shame that the Observable proposal [1] still seems somewhat stuck in Stage 1. It's a better idea than just raw event emitters because of composability (if no other reason). Making Observables "first class" could go a long way to unifying a lot of reactivity patterns in various frameworks, in theory at least.

To be fair, Observables and especially Observable composition has a rough learning curve and many frameworks like Svelte intentionally prefer implict reactivity and avoiding things like explicit Observables because they are seen as too complex/"too hard" for the average developer.

(Then you get awful worst of both worlds frameworks like Angular that sort of rely on Observables but yet also don't trust teaching Observables and wind up with code that isn't properly Observable and so also has all the code for implicit reactivity and is full of nasty escape hatches that cause all sorts of composition problems and unnecessary side effects.)

[1] https://github.com/tc39/proposal-observable

Certainly I've had a lot of fun with wiring mobx up to various things that provide render functions (react with mobx viewstate classes is way nicer than hooks to me).

Svelte I've never quite got the hang of to the point where I feel comfortable expressing an opinion about it (and I haven't spent enough time experimenting to claim my not having got the hang of it yet means anything either).

Event emitters/listeners are entirely too magical and borderline impossible to write automated tests for imo.

I don't think that's a good direction to go.