What is SvelteKit? The linked page assumes I already know and have just been waiting for an announcement.
I have heard a bit about Svelte. I love the analogy with spreadsheets, where original spreadsheets reevaluated every cell whenever any cell changed. Modern spreadsheets maintain a dependency graph, so when something changes, only the direct dependencies are even evaluated. If any of them change, then only their dependencies are evaluated, etc., recursively. So React's repeated full virtual DOM diff at runtime vs. Svelte's focused dependency graph, created at compile time. Very interesting.
But that's Svelte, or at least I think it is. So what is SvelteKit?
> Think of it as Next for Svelte. It's a framework for building apps with Svelte, complete with server-side rendering, routing, code-splitting for JS and CSS, adapters for different serverless platforms and so on.
> If you're familiar with Sapper, SvelteKit is Sapper's successor.
As @skybrian points out below, this doesn't help much if you don't know what Next and Sapper are, and especially if you don't know what Svelte is.
Here's my attempt.
1. Svelte is a JavaScript component framework, i.e. it offers a way to write reusable UI components in JavaScript. (Other popular frameworks include React, Angular, and Vue.)
Each major framework solves the problem of code reuse in a different way, and components written in one framework are generally hard to adapt to other frameworks, if only because each framework includes some JS that you have to run in order to make its components work, and it hurts performance to run three frameworks when you could have just run one, so developers fight a lot about which framework is best.
2. SvelteKit supports "server-side rendering" (SSR) for Svelte. JavaScript frameworks let you implement user interfaces in JS, but by default, that JS only runs ("renders" the UI) on the client side, in the user's browser.
Client-side rendering hurts performance if the user has a slow Android phone. But even on fast devices, client-side rendering adds round trips to the server, first requesting the page, then requesting the JS, then finally running the JS to render. It's usually faster to render HTML on the server, and then to progressively enhance it on the client side.
Server-side rendering requires you to buy into an even bigger framework, with JavaScript component code running on the server and on the client, but it can offer nifty features, like "code splitting," sending down just the right JS needed for the current page (or the current "route," which is a bunch of pages of the same type with similar URLs). SSR frameworks have to handle not just UI components, but entire pages, and deciding based on the URL which page to show, which is called "routing."
For React server-side rendering, you'll typically use Next.js. Vue offers its own server renderer. Angular offers "Angular Universal." Preact offers WMR.
Svelte had an older SSR framework called "Sapper." Sapper is now dead/deprecated code, and SvelteKit is the new thing.
That was outstanding. Decades ago, before they invented juice boxes, we kids enjoyed milk and cookies while listening to carefully worded, age-appropriate explanations. Heaven help me, sometimes that combination still hits the spot. Thank you.
It's an application framework for Svelte which replaces Sapper.
It uses Vite[1] for development and has been designed from the start to be able to produce static sites a la Gatsby or Next (Sapper wasn't great at that). Svelte Kit runs SSR on Node JS servers like Sapper did, but also on cloud functions and I think even Cloudflare Workers which do not run Node.
See Svelte as a JavaScript library like React or Angular, which allows you to develop web applications easily.
Now, SvelteKit is bringing the library to the _framework_ level (big big emphasis on "framework", we all have different definitions for what a framework is), which adds easy routing, server-side rendering, optimized JavaScript bundles per page for the client, etc.
Because to start a project you have to spend days and even months researching libraries, the current best practices, etc. and then glue them all together with some monster build system (webpack, etc.) and pray that one library doesn't update to be incompatible, or that the library maintainer loses interest and maintenance, etc. And then if you look at another project you have to learn everything again because they took an entirely different approach of glueing together libraries.
These frameworks are an opinionated take on project structure meant to save time and effort. Can they build anything and everything with JS? No, and they don't make such promises. Can they build most apps and things people want to build, and with a much faster and simpler setup? Absolutely, yes.
But honestly this isn't the thread to fight the framework vs. library fight. That ship sailed _years_ ago after create-react-app got popular.
I get kind of annoyed when people can't do at least 10 or less minutes of their own research. I believe it states on the front page that its akin to Next for svelte and the successor svelte/sapper. If you don't know what those are then perhaps just follow the links backwards and read?
TL;DR, it is the new officially recommended way to build apps with the Svelte framework. Compared to its predecessor, it promises much faster local development based atop Vite and ESBuild, and it can be deployed as a static site, or a node server, or as serverless functions (whereas previously you only had either server or static site options). There are a ton of other small new features as well in the docs.
Web dev with Svelte brings me back to the early days of web development - php, MySQL, jquery and XMLhttprequest. I personally have never understood all the tooling required to build a modern day react app, and oh how I have tried. Svelte dev as a way-of-thinking-framework is as close to the fundamentals as I think you can get. The dx is amazing and sveltekit takes it to the next level. #sveltalowda
+1 I’m building my second app using svelte now and I’ve had a great experience. Svelte gives me what I need without a bunch of cruft that I don’t, and it lets me build components that embed in existing sites really well. The only thing missing was a good server side rendering story which I didn’t need short-term but long-term will be really useful.
Hey I hope you don't mind a bit of constructive criticism: you should look into getting a pop filter for your mic. I'm very sensible to pops and esses so it might not bother others but it's a very cheap upgrade that you might want to consider :)
You can also experiment by placing at a 45°angle (point the mic towards your mouth, not your mouth towards the mic) and placing it slightly sideways. It'll help with sibilances and pops.
Anyways, thanks for sharing the video, I was actually looking for an overview of SvelteKit's features.
There's also a tutorial [0] which goes through these examples one by one explaining in detail how each concept works. I highly recommend it to anyone interested in learning this framework.
I don't understand why the second example caches the src, checks if the current src matches the cached src, and if not sets both the src and the alt. Does the complier fully check the codebase to ensure they are always set together?
This makes me very glad I have never worked in JavaScript. Why does hello world compile to something with three explicit no-ops and what the heck is safe_not_equals? I had to wonder what an unsafe way to determine equality is and looked this and found this is apparently the code?
export function safe_not_equal(a, b) {
return a != a ? b == b : a !== b
|| ((a && typeof a === 'object') || typeof a === 'function');
}
Why is it possible for a != a to not always be false and b == b to not always be true? How did Javascript defeat the most immutable rule of basic logic discovered by Aristotle 2000 years ago?
Javascript does a lot of implcit conversions, it was badly designed and has dynamic types which means a lot of runtime checks, these quirks can't be removed with breaking a lot of legacy code.
Yet, like with C, you learn the different ways you can shoot yourself in the foot over time and avoid them. In 10 years I've never written a safe_not_equals function, although explicit object/null checks are a thing, but it wouldn't surprise me if libraries used by millions that may end up in Internet Explorer go that extra step. Each language has it's particular use-case, JS happens to be the language of web development.
Although I agree with you in principle, in practice most of js devs never worry about such things. It's mostly library authors and such.
And there are cases where a != a, I think for NaN (not a number).
Fair enough. It makes sense for NaN, but languages like Rust and the various ML variants solve that by defining floating point numbers to not be a type where equality is a valid binary operation.
> Even though it was far from ready, SvelteKit was the only framework that matched our esoteric requirements. (Anyone who has worked in a newsroom and done battle with their CMS will know what I'm talking about.)
I would be interested to hear more about the esoteric requirements; whether they're performance-related, have to do with what's representable in the CMS, or something else. At any rate, those NYT covid tracker pages are great and I have (sadly) spent a lot of time with them over the past year.
• we can't have any dynamic pages, everything has to be static HTML
• we don't control the actual page; our job is to create a fragment of HTML that the CMS stitches into the body, then associate that fragment with some publish metadata...
• ...but during development, we need a simulacra of the NYT article template
• we have to be able to create AMP versions of almost every page
• our old app was already fairly Svelte-centric, and we wanted to reuse as much as possible
• we wanted to use client-side navigation to avoid page reloads (while capturing custom navigation analytics) e.g. because it makes no sense to make people load MapboxGL repeatedly
It's possible that we could have coaxed one of the existing static site generators into fulfilling all these requirements, but it seemed like we'd be in uncharted territory without the benefit of having the SSG maintainer on staff!
Not concrete plans but I expect it will happen, yes (at the very least in the sense of having an `adapter-deno` to allow the built app to run in Deno; running SvelteKit _itself_ in Deno is a separate issue)
i was surprised to learn how many counties in the US are still considered high risk.
also its a pretty cool indication of trust in Rich that they let him build his own metaframework and dogfood it in production at NYT scale. not sure what else i can draw about that (its probably not a good idea to let most devs do that) but its cool
I'm really enjoying front-end work at the moment. I've used Vite/esbuild for a few projects so far and it's a huge step forward, and I'm really excited by this hybrid SSG/SSR approach that SvelteKit is offering, especially as it's "official".
I've been primarily a Vue dev for quite a few years and never really considered investing much time in other emerging frameworks, but I'm very tempted to seriously dive into Svelte at this point.
JS/front-end often gets a bad rap on HN. I see complaints that things have become unnecessarily complicated or that all these frameworks are overkill, but I can build pretty complex, well structured applications with relative ease these days, and I have way more fun doing it, most of the time. I suppose I owe a lot to people like Rich Harris and Evan You who are genuinely making the work I do more enjoyable. Looking forward to trying this out.
This is so exciting! Been using SvelteKit this last week to build a new version of the Svelte Radio podcast website. Works very well and the DX is amazing.
Can't wait for whenever a Cloudflare Worker adapter is out!
Svelte has been such a breath of fresh air after so many years with React. (I still like React.) All my new projects are built with Svelte. There are just a couple of patterns to ease the transition but once you get those it's just so easy.
The best part is every time you want to do something, you gradually stop looking for a library to do it, because it's just html, js and css. So you just roll your own solution and everything is much, much simpler.
Well as Rich Hickey would say, "not everything is awesome", but I'm a big fan of Svelte and mainly looking forward to the new build times speed increases.
Thank you Rich Harris and all the Svelte contributors!
Rich Harris did a great talk[0] at an early stage of SvelteKit's development called "Futuristic Web Development". I really do believe this is the next phase of how JS web frameworks will work in the future.
This blog post gives a bit more information on that: https://svelte.dev/blog/whats-the-deal-with-sveltekit, though the section on Snowpack is out of date. Basically, SvelteKit is serverless-first (whereas Sapper made you choose between a Node server and prerendered HTML), and because it's powered by Vite has a much nicer developer experience.
It also fixes a few of the rough design edges in Sapper. This migration guide gives you an idea of the scope of the changes: https://kit.svelte.dev/migrating
i would also like this. i recall Rich musing on some of the "hydrating unnecessary content" problems in this post https://dev.to/richharris/in-defense-of-the-modern-web-2nia so i imagine its on his mind. Elder.js solved it in a way, i'd love to see Rich's spin on it.
The way I understand it is it's an evolution of sapper to be more versatile, especially with respect to the backend. Out of the box it can work more easily with serverless providers that give you static file hosting + some kind of basic API gateway and serverless function platform. So you can write full stack client and server-side code all using the same framework (like you can with sapper). But the key difference from sapper is that you're not stuck using a node.js backend, with sveltekit you can swap in different backend implementations, like one targeting a serverless/lambda system.
I haven't used Sapper, but I've read a bit about SvelteKit. Afaik the main reasons for the rewrite were to clean up the code, and make the framework platform agnostic. This means that you can use different adapters for SvelteKit to make it usable in places where Sapper wasn't optimal, such as serverless hosts.
No, go back about a week to the thread here on esbuild: https://news.ycombinator.com/item?id=26399377 Esbuild is a go-based tool that takes the place of babel, webpack, tsc, etc. and is much, much faster than webpack. Vite adds a nicer dev experience on top of esbuild (hot module reloading, etc.).
I only know of one active attempt at: https://stc.dudy.dev/docs/status from the author of swc. You may ask kdy to test but the product is closed source unlike swc.
Agree with this one.
Existing UI frameworks (eg. https://sveltematerialui.com/) are not to the level of Vuetify (for good reason).
Even though I like Svelte, having to build a lot of UI elements from scratch has been annoying.
> If you have a app that you'd like to migrate to SvelteKit, you'll find instructions at .
Ok can't copy/paste anchor text apparently, but yeah I'm confused as well. I just read a bit about Sapper the other day, is this a replacement? :shrug:
Will this support devs who want to use Svelte to add specific widgets to a dynamically generated Rails page? I want to explore SSR but was/is daunting with installing JS stuff along with existing web app infra.
We've banned this account for posting a huge number of unsubstantive comments. That's not what HN is for. It's supposed to be for thoughtful, substantive conversation and intellectual curiosity.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
I think the point was that the user's comments didn't add much value to the site. If you don't have anything of value to say, then don't say it. Reddit is probably a better platform if you just want to say "nice", or something.
Part of what moderators do is ban accounts that break the site guidelines repeatedly, especially when they are respawns of previous accounts that broke the site guidelines repeatedly.
Haha thank you kind stranger! I've been a member since 2012 and while I've visited my profile tons of times, for checking comments and submissions, I've apparently never stopped to look at the settings and what they might do. I have a userscript that makes the main view 69ch wide and blurs my username, but I've never even been aware that the site actually has its own customization settings. :facepalm:
You create pages by adding files to the src/routes directory of your project. These will be server-rendered so that a user's first visit to your app is as fast as possible, then a client-side app takes over
Learn more about svelte (not just sveltekit here) and you'll see why your snarky comment just looks dull and uninformed. SSR (what you're calling reinvented php here) is just one tiny part of the svelte and broader component-based client-side JS ecosystem. You're washing away their incredible power for building fully browser-based applications that mix client and server logic all from the same clean codebase.
I have heard a bit about Svelte. I love the analogy with spreadsheets, where original spreadsheets reevaluated every cell whenever any cell changed. Modern spreadsheets maintain a dependency graph, so when something changes, only the direct dependencies are even evaluated. If any of them change, then only their dependencies are evaluated, etc., recursively. So React's repeated full virtual DOM diff at runtime vs. Svelte's focused dependency graph, created at compile time. Very interesting.
But that's Svelte, or at least I think it is. So what is SvelteKit?