I saw couple discussions about future development of Karax (React), its virtual dom overhead and comparing it to another approaches.
One such approach is Svelte and the focus was always on the speed/overhead. I think it's wrong to thing about Svelte approach as just being faster. Because while Svelte is faster, speed is not it's main advantage.
Main advantage of Svelte is this:
What does svelte differently?
Both React and Svelte are reactive. They differ how they provide reactivity. React does it by framework, and you had to adhere to some code patterns required by that framework. Svelte provides it by the language itself (compiler) so you don't have to write boilerplate code.
React is not bad, it's huge step forward compared to older MVC approach. React is good. It's just that Svelte is even better.
Karax is not React
indeed a counter in karax would require a normal var counter = 0 as in the svelte side of the meme. see for example: https://pietroppeter.github.io/nimib/counters.html
Challenge: Rewrite the Svelte compiler in Nim :)
there is a project that goes in this direction: https://github.com/mildred/nclearseam
see also: https://mildred.github.io/nclearseam/docs/svelte_with_nim.html
still curious how sveltje works on a technical level
me too, I found this explanation helps me understand better: https://lihautan.com/compile-svelte-in-your-head-part-1/
As a long time user of both React and Karax, I agree with Araq that Karax is not React.
I've enjoyed working with Karax when I have used it.
For those interested in my nclearseam project linked above, I haven't touched in a while and I don't plan to improve it any further for now. I stopped mostly because the javascript backend for the Nim compiler is not good enough. I remember things like iterators were not properly supported in the javascript backend, and nclearseam needed to use features like this.
Still, this is an approach that I still value, but for the moment, I'll write my webapps with Svelte directly and integrate with a Nim backend if I need a backend.
I also noticed that reactivity within the language as permitted by Svelte can be a nighmare to debug and for an application I made that used heavily the special Svelte syntax for reactive variables within the code, it made the application very very slow. Explicit reactivity around Svelte stores is I believe better and for those interested I expanded them here: https://github.com/mildred/webmsg-webmail/blob/master/src/utils/store.js
I remember things like iterators were not properly supported in the javascript backend, and nclearseam needed to use features like this.
I agree that it's unfortunate that Nim JS still does not support closure iterators.
But you don't really "need" a feature like this as millions of programs, including UI programs, got written successfully in older languages lacking the feature.
I remember things like iterators were not properly supported in the javascript backend, and nclearseam needed to use features like this.
Speaking of which, someone might try to port enable lambda-lifting for the JavaScript target. It seems feasible to me.
I also noticed that reactivity within the language as permitted by Svelte can be a nighmare to debug > Told ya. ;-)
From the user point or from the language developer point? In my experience from the user point, working Svelte, the most pleasant and easiest experience among all JS UI frameworks. It just works. No problem, no complexities. Maybe Svelte developer has problems I don't know, but me as user don't have any problem.
Im currently working on a svelte-like framework: https://github.com/choltreppe/sneltim
Its not finished yet (theres just for no if else in template syntax, no css ..), but the basic system of defining components and the patching mechanisms work (for the small tests ive done so far)
