Svelte was rated as the most loved web framework by developers in 2021 (link). So what is Svelte and why is it so loved?
Svelte is a rather unique...
For further actions, you may consider blocking this person and/or reporting abuse
While evaluating Vue.js replacements I tried Svelte a year ago and TypeScript support was lacking. There also wasn't a solid alternative for a nuxt.js/next.js like integrated SSR solution. Going all in on React with Next.js I cannot see myself going back to Svelte. React even though not perfect has an incredible community force behind it that makes finding libraries or modules a walk in the park. It looks Svelte today is much better at TypeScript support especially in Template literals, but for me the train has left the station. For Svelte to gain more traction SvelteKit needs to be a much higher priority.
Sometimes Next.js seems to be adopted like it's some kind of silver bullet.
As demonstrated by Optimizing Core Web Vitals on a Next.js app it can take quite a bit of effort to (in this case) nudge the Time to Interactive from "moderate" to "good" with a Next.js application. Next.js's Achilles heal is that it performs full page hydration since most React applications do full page renders on the client side. Back in 2019 an experimental, heavily customized Preact/Next.js application demonstrated the benefits progressive hydration could bring (see also Partial Hydration in Preact).
Based on this Remix is gunning for Next.js with their interpretation of progressive enhancement while Astro does it with partial hydration.
experiences. Web. frameworks. future. me. puts forward an interesting perspective. React (Next.js) and Svelte (SvelteKit) are Generation 2 Web solutions (Gen 2) - but the challenges of client-side hydration limits the effectiveness of their respective SSR solutions.
Meanwhile there are already early indications of Gen 3 - JavaScript-based server-first architectures. Server-first differs from traditional dynamic server rendering as there still can be a significant client side capabilities (e.g. nested routes)—but the client no longer dictates key aspects of the server-client dynamic; while both are separate their interactions will be more tightly coupled (compared to SPA + API) to deliver a better user experience. Gen 3 MPAs will attempt to optimize for FCP and TTI to provide universally "fast page navigation"—with may even leverage "streaming HTML".
The weirdly obscure art of Streamed HTML
Taylor Hunt ・ Mar 15 '22 ・ 12 min read
Why Efficient Hydration in JavaScript Frameworks is so Challenging
Ryan Carniato for This is Learning ・ Feb 3 '22 ・ 9 min read
Thanks for the pointers. I agree it isn't a silver bullet and these frameworks introduce their own problems. It's a delicate tradeoff for me between a slower less flexible solution like Next.js or run a bleeding edge less common setup. As an entrepreneur I also have to consider the cost of onboarding new developers , or the impact of a more obscure framework when I want to sell my business.
It's hard to argue with that reasoning but I think the mindset has gotten to the point where it is self perpetuating SPA/React/Next.js adoption—products are built with React because of developer availability and developers adopt React because of demand. Adoption based on popularity of authoring experience rather than suitability towards the product being developed (Responsible JavaScript refers to this as the bandwagon fallacy).
The typical developer framework discussion revolves around a framework's impact on the developer('s happiness and productivity) rather than the impact on the end user. That facet gets highlighted elsewhere:
The Cost of Javascript Frameworks:
"Good frameworks should provide a better starting point on the essentials (security, accessibility, performance) or have built-in constraints that make it harder to ship something that violates those.
That doesn’t appear to be happening with performance (nor with accessibility, apparently)."
The Three Unattractive Pillars of Web Dev: accessibility, security and performance;
Responsible JavaScript:
"Frameworks don’t doom us to build shitty websites but to use them is to accept a certain amount of overhead you can never optimize away. You must step lightly, particularly since the ecosystem of installable plugins and off-the-shelf components available to such architectures can further compound their user-experience problems."
Your experience with Vue is unfortunate, especially if it lead to wasted effort. But disruptions like this aren't limited to the "smaller" frameworks; both Angular and React have had them:
Clearly it must be the pragmatic choice at times, it just seems that ecosystem/hire-ability considerations have made React the incumbent technology—despite the clear need for alternatives with different sets of priorities.
Thats fair. Next.js is really coming out ahead in the SSR world, and SvelteKit really needs a bit more work.
I wonder why you were looking for a vue replacement.. I'd appreciate it if you could share why....
This was at the time Vue 3 was introduced. My codebase was build using (TypeScript) Vue Class Components and there was no migration path going forward. Vuex wasn't well suited for TypeScript and it didn't look like this was going to change anytime soon. The Vscode extension Vetur and TypeScript templates didn't play well together, the overal dev experience was lacking. I think Vue is an awesome project and my move to TypeScript was probably what made it less enjoyable.
I think this post misses a very important aspect: the ecosystem. We have seen to many frameworks come and go, some are even sick of it. The ones who "survived" were react, vuejs and angular. Each has its own flavor, its pros and cons, but most of all they have a mature ecosystem, which svelte lacks of.
...interestingly enough, I used a lot its predecessor: ractive.js.org/ . It was made by the same guy, who then abandonned it in favor of svelte. Afterwards, ractive never really recovered from this blow. The community was rather small and deteriorated into a slow death. So, I got burned a bit. It makes me warry of web technologies lacking crucial momentum.
A solid point, especially in a professional setting a framework's ecosystem is a very important consideration.
A thriving ecosystem takes time however, and I do think that for Svelte it is steadily building up, with more more developers learning the framework and more tools being built.
I love Svelte, but I keep coming back to React/Next.js as many has pointed out already due to the eco-system and solutions being available. Its just a time thing perhaps and its great that Rich joined Vercel to work on it full-time and I hope to see it flourish!
On the other hand, the critique of elegant JS and the simplicity is a bit misguided I would say. Svelte has more "magic" behind the scenes including the state management and what is really happening behind the scenes of
bind:Obviously more explicit code requires more writing and more lines but it also makes it a bit more logical.
Everything is sort of a trade-off. I am excited for Svelte though and its future!
If you are searching for true reactivity, try Solid.js – where svelte tries to get the most out of its compiler, Solid gets the most out of its reactive system, from state down to specific DOM updates.
Thanks for the suggestion. I'm always looking for more tech to try.
I like Svelte and it has pushed things forward, but it still has a lot further to go. I found testing hard with Svelte and Jest and Vite, I wrote about this recently:
Testing a Svelte app with Jest
Rob OLeary ・ Nov 18 '21 ・ 15 min read
As SvelteKit uses Vite, Vitest will probably be the way forward. However, it is the VueJS folks who are working on it, so integration with Vue is superior I guess...
Vitest doesn't prioritise Vue at all. Give it a try before bashing it 🙊
What I said in no way bashed Vitest. Quite the opposite, I said it will probably be first choice for testing apps that use vite because it has support of some vite/VueJS folks and that it looks promising. I haven't tried it, but I intend to. I was merely speculating on how far along it is wrt support for different frameworks. Try to find the good in what people say
I looked at Svelte before and I decided against it because of the imperative programming paradigm it uses. React allows me to write (mostly) functional typescript/javascript, and there are other frameworks too.
Maybe it's possible and I've just not looked at it well enough.
A very good point in favor of React for me. I think functional style programming with React is very beautiful.
I have looked into doing the same with Svelte and it is possible using immutable stores, but I need to take a further look to judge how good it works.
I have made few small games and app with Svelte in my internship and they were so fun to build. I feel for small and medium size projects, Svelte is a very good solution. Only thing I will complain about Svelte is the CSS scope. I was creating a component library with it and it was painful to override the styles that the components came with.
I really don't see any reason to switch from Vue 3 to Svelte.
That's awesome. Switching is time consuming and may not yield the benefits touted by the evangelists.
you can say that about any frameworks without opinion
Is it posible to make ssr with svelte and .net core?
Should i use sveltekit or just svelte for that?
I believe both options can be utilised. Here a thread with some ideas: reddit.com/r/sveltejs/comments/r4x...
Better still, try RiotJS
I have stopped using Sveltkit due to its very unstable nature right now (beta). Cant wait for a stable release.
Me too. However, playing around with Sveltekit recently, I personally found Sveltkit to be decent stability wise.