All Javascript frameworks may become implementations of SAT solvers, where rendering and state are scheduled constraints, i.e. tiny operating systems.
NPM uses CSS as a query language - https://news.ycombinator.com/item?id=33136843 - 9 months ago
Then apps may be instantiations of the framework.
No different from what most non-frontend developers want by the way.
Problem is; that is not yet possible at all, because ‘the spec’ is too vague and strictness generated from vagueness will either be just vagueness (cannot find any constraints to throw into a solver so just leave it) or too strict (where many cases simply are suddenly forbidden that were actually feasible cases by the author).
<button on:click={incrementCount}>
Or what about this… is this JavaScript?
$: doubled = count * 2;
{#if user.loggedIn}
<button on:click={toggle}> Log out </button>
{/if}
<button on:click|once={handleClick}> Click me </button>
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.
Take the ability to reference functions in HTML - this is simply not possible in normal HTML, where inline event handlers instead are passed Javascript expressions to evaluate. It's definitely a useful feature, but it's very clearly outside of the normal realm of HTML.
This goes further with Javascript: here the semantics differ considerably, with labels in normal Javascript doing nothing except when dealing with loops, and labels in Svelte are a form of reactivity. You've also got things like dollar signs interacting with stores, and other semantic differences.
As Rich Harris says, Svelte is a language.
I think this is the crux of the gp's question. The browser doesn't support explicit behaviours for "on:click" or "|once" (the "$" label is a cool trick I'd forgive the gp for not recognising as native JS) - it may be "valid" HTML but it's not "just HTML" (nor just JS), it's a DSL.
I love svelte but I'm having a hard time getting the same development ergonomics out of svelte kit. It's probably just me.
This is funny because it's exactly the reason I prefer react
Centering JS has always been like putting the cart before the horse.
Two great things about this "thinking inside the box" approach are:
1. You're encouraged to use native APIs because they're highly unlikely to clash with the framework.
2. You can a legible stack trace. After all, the only thing the compiler does to your JavaScript is add some instrumentation here and there.
I've converted my company website to svelte-kit from first Angular, then Vue.
But for SPA it's bad. If you use oidc auth. There's only Auth.JS and it's a confidential client, for Svelte Kit.
If you're not using svelte-kit you can use vite to create a Svelte SPA. There you can use your PCKE client as usual and burden the load on the client.
I have yet to experiment with how well it works with a graphql client. Apollo has its own cache but I'm not sure there is a svelte version of it. There is for Vue. Does it even need one? The default is for React. Is Apollo even needed? Questions over questions.
Why Svelte? Performance. Performance matters, a lot.
Svelte being a "language". First time using a template system? I have to wonder.
This makes tooling complicated and a debugging that works out of the box for both server and client side is non existent even in SvelteKit 4.
When I'm picking up SvelteKit, it's only for its routing which isn't so great either with file based arrangements, things get out of and pretty fast.
I was excited about svelte, but have found that coming back to my svelte project after a month or two of not using it was arduous because of all the myriad language level things. There are just too many little svelte specific things to keep track of in head.
In contrast coming back to a react/vue project is much easier for me, because even if I forget something at the end of the day any vue-directive or react hook is just another js/ts api I can easily lookup.
In particular, I find the DX that volar+vscode offer in a project with vue3, composition API & pug templates to be better than anything else I have seen in the FE ecosystem in last 5 years.
I also don't find the enhancements for local reactivity to be major value additions because most of the times my state resides in a shared store. I find the vue reactivity model to be simpler to deal with because I can create shared stores which can be (deep) mutated from any component and it all just works seamlessly.
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.
Last I checked (and things may have changed since) is that svelte didn't support transparent reactivity for deeply nested objects. So something like `$myStore.foo.bar = "baz"` wouldn't trigger a component update, you need to remember to use .set, .update etc. You could assign to local reactive variables but you couldn't assign to stores.
I am sure the library authors made these trade offs thoughtfully, I was just disagreeing with the blanket statement that Svelte is generally a major improvement over Vuejs.
I'm currently finally doing a big React project, and boy, the complexity is spiraling a bit out of control. It's certainly not DRY.
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.
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.)
The main issue is, that it becomes a nightmare to transmit and compose meta-information. An example would be the fetchStatus of ReactQuery [1].
I way too often end up in situations like this:
.map {
unwrapMetaData
...
rewrapMetaData
}
...
.map {
unwrapMetaData
...
rewrapMetaData
}
.switchMap {
// unwrap metadata and wrap it in an observable
combineLatest(...) // have fun juggling an array of nested monads :)
}
async live function() {
const { value, meta } = observe getValue(...) // suspends when loading, throws on error
// work with values
const multipleValues = observe Observe.all(...map(i => ...))
// more work
// evaluateMetadata
}
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).
I don't think that's a good direction to go.