Proofs are arguably still better than tests at evaluating efficiency, at least for smaller components/algorithms in isolation. While there are cases where constant factors that can't be described well in a proof matter, in most cases, the crucial element of an algorithm's efficiency lies in how the complexity scales, which can be proven in the vast majority of cases. On the other hand, relying solely on benchmarking introduces a lot of noise that can be difficult to sort through.
If only there was a clear answer to this. Software engineering, as it has appeared to me, has always seemed to evolve with opinions moreso than tangible improvements. That being said, some practices are almost universally agreed to lead to better code, like defensive programming (proving your assertions relating to program conditions in the actual code), uniform documentation, and, in general, taking your time in implementing structures that will be used throughout the codebase. Formalizing your logic in proofs can be one part of that.
Agh, I understand why runes were implemented, but I still can't get myself to like them. It feels like Runes take away from what made Svelte Svelte (the simple, concise syntax), and changes like this seem like slow concessions back in that direction anyway.
I felt the same way at first, but even in my small project, I've come to greatly appreciate them—or at least what they seem to enable. I've found deeply nested bindings to work without a hitch, which wasn't always the case in Svelte 4.
You just have to build a big project with Svelte 5 and you will come to like them.
A lot of magic is okay for simple application, but when you want to build anything that scales Svelte before runes was just horrible. With Svelte 5 and Runes you can look at any component and instantly know what it does. You couldn't do that with Svelte 4 unless you wrote the whole code yourself.
I think that's actually the core of the problem. It's the right choice for big projects. But Svelte was an absolute joy to use when brewing up a small or medium size project that you want to just work first time.
Runes are the right choice for the library, but there is still a loss there.
Not sure I agree. I’ve built numerous small projects in Svelte 3 & 4, sharing that same joy many of us had! Stores were generally amazing.
I was highly skeptical of runes upon the original announcement and very cursory usage during beta phase.
When I finally got to porting a couple simple projects, I shrugged “this isn’t too bad, but what’s all the fuss?”.
I ported a mid size project and it really clicked.
Then I went to build a brand new small project, and I found myself in love with runes. Having spent the time to get under the hood (especially using them as classes), being able to leverage them during the design phase really sped me up and facilitated cleaner/better state management.
They really are an improvement. Tracking data flow in a complicated component (bound props going in both directions, derived state, …) was terrible before runes — you just had to rely on compiler magic, which worked until it didn’t. Now it’s more or less obvious.
I wish they had found a way to make the compiler just work. No longer having the ability to update the DOM by updating bound variables eliminates one main reason I wanted to use Svelte in the first place. I still love SFC though.
You can't just set a variable anymore, you need to use runes. Which is silly - I shouldn't need to tell Svelte this is reactive, any variable referred to inside the HTML in the component is logically reactive and Svelte should know this. Like it used to. This is why we had a compiler.
I should point out that indeed (as you're correctly pointing out) updating bound variables looks the same, just that declaring them sucks. I don't really trust they won't do similar things to updating bound variables though.
On the one hand, yes, it's annoying to have to explicitly declare state. On the other hand, it's much easier and clearer to declare derived state now. Pre-Svelte 5 code had a lot of this:
let someState = someOtherState.thing;
$: someState = someOtherState.thing;
Which was awful.
Svelte 5 does still have a compiler, and there's still a lot of "magic" involved — it just asks you to be more explicit about your intentions in some cases. Of course in an ideal world it could just figure it out, but some distinctions (do I want this variable to always update when its dependencies change? or do I just want to set an initial value based on the dependencies?) need to be specified explicitly, and I prefer clear syntax for that explicit specification over the terrible, verbose hacks that you used to have to use in order to prod the compiler "magic" in the right direction.
I was a runes hater, then I bit the bullet and migrated a big app to Svelte 5. Now I get it. You should give them a chance as well.
> Of course in an ideal world it could just figure it out
Yep. We're agreed there.
> I want this variable to always update when its dependencies change? or do I just want to set an initial value based on the dependencies?
Reasonable to default to first, ask the developer to be explicit about the second if needed.
Honestly I still love SFC and Svelte having opinions about CSS and state storage is great. But it feels like this was the wrong direction. The 'magic' is why we used Svelte.
Edit: I think my tone here is a little off due to illness. Sorry if I sound grumbly. Wasn't my intention.
QuickJS is great for cases where you are more limited by startup and executable size than anything else but it tends to perform quite terribly (https://bellard.org/quickjs/bench.html) compared to V8 and anything else with JIT compilation.
More code does not inherently mean worse performance.
But its SDK is not the c++ abominations like v8, and that alone is enough to choose quickjs or similar, since we all know here, that c++ (and similar, namely rust/java/etc) is a definitive nono (when it is not forced down our throat as a user, don't forget to thanks the guys doing that, usually well hidden behind internet...).
For performance, don't use javascript anyway...
That said, a much less worse middleground would be to have performance critical block written in assembly (RISC-V Now!) orchestrated by javascript.
I'm not sure I understand the point of mentioning the language. If it was written in a language like c but still "shoved down your throat" would you still have qualms with it? Do you just like things written by corporate entities and those languages tend to be popular as they scale to larger teams well? Or do you dislike software that is too large to understand and optimized for the needs of larger teams? Because it doesn't matter if it's software or some grouping of distinct software - at some point there will be a point at which it becomes challenging to understand the full set of software.
If I were to create an analogy, it feels like you're complaining about civil engineers who design skyscrapers to be built out of steel and concrete instead of wood and brick like we use for houses. Sure the former is not really maintainable by a single person but it's also built for higher capacity occupancy and teams of folks to maintain.
The "need of larger teams" does not justify to delegate the core of the technical interfaces to a grotesquely and absurdely complex and gigantic computer language with its compiler (probably very few real life ones).
This is accute lack of perspective, border-line fraud.
Not all problems are technical. Some are social. Velocity of a large team should absolutely be taken into account when designing software. Does the concept of an assembly line also upset you? Not every thing can be done by a single craftsperson working in isolation or in a small group.
I'm not suggesting where we ended up is ideal, but it has utility. I hope for a language reset akin to kotlin for the c++ community at some point to help resolve the complexity we've managed accumulate over decades. There is a decent amount of effort from various parts of the ecosystem to accomplish this.
I could be reading your comment wrong, but what do you mean with "c++ is a definitive nono"? Also how is a complicated repository enough (reason) to choose quickjs?
