11–20 of 256 posts
Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?
Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?
- had a 3 year head start on Svetle (2013 vs. 2016)
- has major engineering orgs behind it. Facebook started it. Microsoft makes it work with Typescript.
- is easier to get started with. While JS-compilation is common, it's required for Svetle.
Svelte isn't free of pain points. Like any form of magic, it has edge cases. It's better but not "better enough" to de-throne React.
Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?
The automatic handling of dependencies and recomputing means you have less control over how updates work.
Also I think it is important to understand the mutations going on in your ui. Having them explicit like in Vue makes it easier to understand what is gonna happen by looking at the code versus the implicit way that Svelte uses.
The cursive italics are apparently a feature of the Victor Mono [1] font used for the full page. While it'd be amusing in Tumblr context (where cursive is used for hyperbolic emphasis), I can't fathom why one would consider it in a code context, but to each their own...
You can change it (at least on Safari) by going into developer tools, clicking any node, and removing "Victor Mono" from --font-family
And I find manual render very usefull and once you do it, you can have a global state as simple as a global object, no need to use useState anymore.
Well, IIRC, Elm is faster than all the examples given, and yet front-end developers find Elm to be weird and frightening.
So I’m not sure I agree with the premise of the article.
I also don’t agree that there can be so many valid answers to “Find a change detection paradigm that fits the needs of your application”. Surely everyone just needs the one that is most efficient and least broken.
What about Solid.JS?
Most other frameworks here (all? not sure about Vue) will invalidate and rebuild an entire component subtree if a piece of state in them changes. The solid runtime doesn't care about components so changing a piece of state high in a subtree will only update the piece of the DOM directly depending on that state and not any nodes that were authored as sub-components.
Earlier quoted context omitted.
3) Saves you from having to rewrite dataflow and state management code with every project. (Saving time is a business factor.)
Those are trivial to solve for and then once you do solve for it its just a matter of copy/paste from project to project with about 10 minutes of rewiring. That costs dramatically less than spinning up a large framework project to project, but frameworks save on training time because most developers cannot solve for these problems on their own.
The rest is nice to have.