Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Are they still sticking to that godawful routing nomenclature of +page.svelte in infinite nested folders?by sensanaty
- Sveltekit has been a breath of fresh air for me over the last few years.
I've had to work on a Next.js for work and much prefer Sveltekit. Excited to try this release!
- The thing I like about Svelte the most is that it's closer to raw HTML. Rather than having to keep up with all the React developments if you're not using it all the time.
- I love the hands-on developer experience of programming in Svelte. But since we're in October of 2026 I have to ask, is the vibe-coding experience in Svelte any different than in React? Can anyone with experience in both comment?by stillatit
- I used Svelte daily as my main framework between 2020 and 2024. Took me a couple of years to realize Svelte's biggest strength is also its biggest issue. Having a custom language means so much effort is needed to build and maintain custom tooling to support it. And not only from the small Svelte team and its community. Eg: Even to this day, the Svelte plugin by JetBrains is trash [2]. If you want to do Svelte you're basically trapped into using their VSCode extension.
Ultimately I ended up moving away to Solid primarily because I can write vanilla TS/TSX. Like it or not, TS/TSX is a standard these days and most editors or IDEs support it out of the box.
by pier25 - Such a great project. I converted my React-enjoying cofounders to Svelte/SvelteKit worried they wouldn't like it, but they absolutely love it!
We use Svelte extensively at Orb.net for our website (duh), but also as a framework for our desktop and mobile apps. Wails serves our golang and SvelteKit/Svelte provide the UX. It's been tremendous for multiplatform productivity, and binaries are less than 20mb! Nothing like Electron!
by jamies - After far too many hours using react, Svelte has become my favorite frontend framework. I’m seeing a lot of comments about how it stacks up in the LLM age. Prior to Opus 4.6-8 (and that era of model releases) they often struggled to get Svelte 4/5 code straight and mixed it up quite a bit.
But having used it A LOT this year for personal projects, large work initiatives, and one-off web tools. I’m happy to say all the modern llms seem to do just fine with it. They even handle the experimental features, like remote functions, very well. It’s mostly preference but I find reading Svelte code much more pleasant than React/Vue.
by poetril - Hey everyone, Rich from the Svelte team here. Coordinating all the moving parts for yesterday's launch (last few PRs, doc updates and redirects, CLI release, launch blog post...) turned out to be a bit of a slog so I'll confess I turned off my laptop and went for a beer as soon as it was done instead of sticking around to engage in HN threads and Reddit and so on.
Honestly, I didn't expect the release to generate much conversation at all. There's a lot less focus/interest in front-end frameworks generally these days, for obvious reasons, so I figured the median reaction would be 'oh, the Svelte team are still shipping? good for them' and not much more. It's a joy to see the conversation here whether it's from happy users, or people who prefer different things, or people who have fully outsourced the writing-the-code bit to LLMs and straight up don't care about the underlying tools any more.
Which I totally understand! As framework authors we're very persnickety about the details of the code, so we've been on the slower end of the LLM adoption curve, but even we're starting to delegate more of the work to agents. If you're prompting an app into existence it's natural not to care that much about the particulars. But a question I've seen several times here, and in the zeitgeist more generally — 'in a world of agents why should I care about Svelte vs React vs whatever?' — deserves an answer.
And it's this: your app will be _better_ if you use Svelte. Your JavaScript bundle will use fewer bytes, your server-side rendering will take fewer milliseconds, and your users will reap the benefits: faster, more efficient apps. For all that the agentic revolution has created a huge _quantity_ of software, the _quality_ of the average app stubbornly refuses to budge. If anything, software is becoming less reliable. I think we've all felt that. Using a framework that treats things like accessibility and progressive enhancement as core concerns will help you steer towards better outcomes. (Your agent will use fewer tokens as well.)
Of course, this was always the pitch! Agents don't change that. And that's why we're still shipping and still sweating the details. We have some stuff coming up that we're unreasonably excited about — we really care about this stuff, and we're very grateful to be part of a community who shares that passion. Thank you for the support, it means the world to us.
by rich_harris