I wanted this workflow but we absolutely share the same problems. However it took a few minutes on their site to see that the workflow involves explicitly assigning tickets to cheepcode in order for it to work on them.
That being said, I tried to sign up, and it broke horribly, and it looks like it was knocked out in 5 minutes, so my desire to give it access to my production codebase is fairly minimal.
The only reason React et all need an ecosystem is because they're hard to integrate vanilla libraries with, or harder to develop components for.
Vue suffers less from this issue, as you'll well know, and Svelte doesn't suffer at all.
The same can be said for people being skilled in it. It takes longer to skill up on React, less on Vue, and the least on Svelte.
A lot of people end up using React because of these invented scenarios, when in reality, building something rapidly like a start-up is significantly quicker with Svelte. Trust me, I've done it, and we're post Series A, and now reaching profitability.
I'll be the first to mourn the (future) loss of $: but the video clearly shows that the changes are a pretty enticing way to make your code that little bit cleaner, and solve all of the "but Redux!" style questions.
I found `$:` to be extremely confusing, full of weird quirks, and completely turned me off to using svelte for anything more than basic sites.
Runes seem like a clear improvement, but brings Svelte a step closer to React -- which hurts its appeal to me.
The difference between `let counter = $state(0)` and `const [counter, setCounter] = useState(0)` is near its initial value -- zero.
I do love the view library competitive landscape and enjoy seeing different paradigms leveraging reactivity. I also like the compiler optimizations that Svelte is bringing to the entire ecosystem.
> 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.
While this is all technically true, I don't think it's all that helpful a thought process to have when approaching Svelte. Yes, Svelte files are syntactically valid HTML, Javascript, etc, but they have very different semantics.
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.
100% valid HTML and within "the normal realm of HTML". The event is passed as a parameter to the function. Has been available since the introduction of JavaScript. Predates addEventListener(…) and its ilk by a few years.
Yes, "$:" as a labeled break exists outside JavaScript proper. That said, given the rare cases where anyone uses a labeled break and how unlikely that labeled break would be named "$", it seems a pretty safe extension to the language to allow such powerful behavior.
Both "$:" and "$store" are not magical; they are quite deterministic and serve to substantially reduce the total amount of boilerplate. Seems a fair tradeoff, but you are correct, it's a superset of the JavaScript language.
Now let's discuss the "naturalness" of useState, useMemo, and their ilk. I'll take Svelte's minimal "magic" over the verbose, repetitive, and error-prone library API logic, thank you very much.
> 100% valid HTML and within "the normal realm of HTML". The event is passed as a parameter to the function. Has been available since the introduction of JavaScript. Predates addEventListener(…) and its ilk by a few years.
Like I said, it's valid HTML, but it doesn't do what you're describing (and you can try it out fairly easily in your browser). The "onclick" handler executes the code string that it's given, working essentially the same way as `eval` or the `new Function("...")` syntax. It does not take a function pointer.
So in this case, the only thing it executes is a variable pointing to a function, which doesn't do anything because the function isn't being executed. You would need to add the function brackets to get any sort of effect.
This is the crux of the issue: Svelte is an additional language that happens to use the same syntax as HTML and JS, just with different (in some cases very different) meanings. You are not just writing "explicit Javascript code", you're writing Svelte code (which in most cases is probably very easy to pick up if you know Javascript, but it's still a different language).
Compare and contrast with, say, Typescript, which is syntactically different from Javascript, but semantically identical - just remove the types, and you have normal Javascript. (In fairness, with old decorators and enums, this isn't quite true, but it holds in general.)
To be clear, I don't think that's saying that one thing is better than the other, or that Svelte is bad because it's a new language or something. I think reactive primitives in Javascript are important, and adding them directly into the syntax of the language is a really clever way of solving a lot of problems in this space. I'm not sure if it's the solution I like the best (I've really enjoyed working with SolidJS signals recently, which provide some of the same ideas with a more typically Javascript-like API), but it's good to see experimentation here.
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.
It does support onclick though. This isn't a far off derivation. Also "|once" is a whole lot cleaner and more terse than the "once" variant of addEventListener, to be sure.
Anyone who already knows HTML and native event handling could pick this up in less than 5 minutes. Good enough.
it's not. `toggle` is a pointer to a function name and "toggle()" appears to be an expression which is parsed and then executed (scary).
you can on on:click={() => toggle()} in svelte which is more similar, but it isn't parsed and executed, it is a pointer to an anonymous function which is directly executed.
on:click={toggle()} in svelte would run the function immediately (probably not what you want) and return the result as the handler for the on:click
Not a pointer to a function. In JS, functions are first class objects. You might as well say toggle() is an invocation of a pointer to a function.
<div onclick="toggle"> has existed since the dawn of JavaScript in Netscape Navigator 2.0 Beta Gold. Your complaint about the syntax is in fact baked into the foundations of the web.
you're equating it to string interpolation. It isn't. It's a compiler directive which disappears when compiled, which is why it is expressed as a brace expression rather than a tag.
Yep, but slowly converting it all over to SvelteKit. Saves me having to maintain servers, watch setups, build processes, deployment processes, routing, bundling, and so on.
That's the tutorial - which uses WebContainers, which are indeed an experimental technology. It has nothing to do with the production readiness of SvelteKit the framework.
That being said, I tried to sign up, and it broke horribly, and it looks like it was knocked out in 5 minutes, so my desire to give it access to my production codebase is fairly minimal.