SvelteKit Is in Public Beta
svelte.dev
svelte.dev
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?
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.
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.
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.
Doesn't that ring a bell?
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.
Top has a link to a prior blog post: https://svelte.dev/blog/whats-the-deal-with-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.
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.
I have been building JS apps since '99 and once I found Svelte/SvelteKit, I have not looked back.
It really lets you stay in the flow of creativity while building.
Edit: embarrassing typo
SvelteKit is designed to let you build anything at all with Svelte.
ElderJS, JungleJS, Primo etc, are all specialisms.
Definitely a little rough around the edges (the real-world application has bugs), but it is public beta, so it's not surprising.
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.
But yeah, putting the mic angled on the side would probably be an improvement.
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?
Unsafe equality: "1" == 1 is true (string and float, https://dev.to/mkrl/javascript-quirks-in-one-image-from-the-...).
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.
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.
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
• 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!
Just curious, are you aware of few of the spinoffs of svelte for deno like snel?
https://github.com/crewdevio/Snel
Have you used deno for any toy projects and how did you like it? Any wishes or criticism?
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.
Can't wait for whenever a Cloudflare Worker adapter is out!
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!
Looks cool by the way, I think Svelte is a really great product.
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
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.
For more in depth info, refer to this page: https://kit.svelte.dev/migrating
That's also what stops me from moving over to Vue 3 (for which Vuetify support is currently in Alpha).
Vuetify just makes dev life so much easier. If Svelte had something that deep and all-encompassing I'd go all-in.
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:
Don't shrug, this is he most exciting framework I've seen in 22 years of fullstack dev.
Sapper was awesome, and I fully expect SvelteKit to raise the bar even further.
As in, after the first SSR'd page the app becomes an SPA.
Stoked.
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.
FYI: [dead] means the account is (shadow)banned, while [flagged] just refers to the particular comment.
There are two basic concepts:Each page of your app is a component
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
looks like you reinvented php, no?
If this is your only thought about it, you have a lot of catching up to do!