announcement blog posts (sveltejs#497)

* announcement blog posts

* bump vps as well

Author: Rich-Harris

apps/svelte.dev/content/blog/2024-10-21-the-omnisite.md

@@ -0,0 +1,59 @@
+---
+title: The Omnisite
+description: Your one-stop-shop for everything Svelte
+author: Rich Harris
+authorURL: https://twitter.com/rich_harris
+---
+
+Launching [Svelte 5](svelte-5-is-alive) and [the brand new `sv` CLI](https://www.youtube.com/watch?v=fAPFsRP-mbc#t=3h15m40s) wasn't enough: we've also released a brand new website. You're looking at it.
+
+Up until now, we've maintained multiple different sites under the `svelte.dev` domain — the main site, for Svelte itself, along with `kit.svelte.dev` and `learn.svelte.dev`. This had some minor benefits, but was mostly a nuisance:
+
+- inability to search across sites
+- subtly different navigation
+- potential for broken links (at build time, SvelteKit automatically validates that every internal link is correct, but links to other sites are a different matter)
+- preferences such as dark mode are not shared between sites
+- navigating between (for example) documentation and the tutorial involves a full page reload
+
+From an implementation perspective, keeping multiple sites in sync proved to be a headache.
+
+Having everything under a single roof means you'll have an easier time finding the information you need. Right now, the site includes documentation for [Svelte](/docs/svelte) and [SvelteKit](/docs/kit); soon, it will also cover the CLI and additional packages like `vite-plugin-svelte`.
+
+## New look
+
+We've also given the site a facelift. Our logo and hero artwork ('the machine'), designed by the brilliant Achim Vedam, are unchanged — these, and the Svelte orangey-red colour, are still the cornerstones of our visual identity.
+
+But many other aspects of the site have been cleaned up, starting with the five Bs — boxes, backgrounds, borders, box-shadows, bold text — which are tempting to overuse when organising information on a page. By getting rid of most of these and simplifying our colour palette, the site is calmer, more cohesive and less cramped.
+
+We've also updated our button styles so that they actually look like buttons (a radical concept in modern UI design, unfortunately).
+
+## What the font?
+
+Of course, the most salient difference is the typography. Previously, we used [Overpass](https://overpassfont.org/) for everything except code — logo, headers, UI elements and body copy. It's surprisingly versatile given its origins as an adaptation of [Highway Gothic](https://en.wikipedia.org/wiki/Highway_Gothic) (the typeface used on road signs in the US since 1948, aside from a [brief flirtation with Clearview](https://www.bloomberg.com/news/articles/2016-01-27/the-official-u-s-highway-sign-font-is-changing-from-clearview-to-highway-gothic)), but it's really not meant to be used for everything. We found ourselves making all sorts of ad hoc adjustments (tweaking colours, casing, line heights, spacing, weights and so on) and breaking other design rules (misaligning copy, adding unnecessary borders) to create hierarchy and reduce monotony. We needed a change.
+
+At the same time, we couldn't bring ourselves to look the same as every other documentation site. Modern web design is stiflingly anodyne: everything is boxes, purple glowy nonsense, and the same handful of sans serif typefaces.
+
+We should find that last part strange. Open any book or magazine and it's overwhelmingly likely that it will have been set in a serif typeface. There's a reason for that: serifs make individual letters more distinct, aiding readability, and help to define the type's personality.
+
+On screens, serif type is less common. That's partly for historical and technological reasons: on the lower resolution screens of yore, particularly on Windows with its inferior font rendering, serifs lack definition and make readability _worse_. But most users today have much sharper screens, making this less of an issue. Indeed, most newspaper and magazine websites, and many blogs, use serifs for their body copy.
+
+I suspect the real reason is mostly cultural: because we've come to associate serif type with the printed word, it is viewed as less _modern_. Conversely, sans serif type is associated with digital products.
+
+I don't know about you, but I've come to associate digital products with unreliability: with bugs, cookie banners, exploitative business models, a disregard for privacy, planned obsolescence, and the many other sins of the technology industry.
+
+I want the things I use to have analog sensibilities. I like things that feel _weighty_, that have an almost physical presence. (Svelte's HTML-first design, and ‘the machine', are, in a way, manifestations of this, even though we are inescapably a digital product.)
+
+Above all, I want a web that isn't so damn homogeneous.
+
+So our new site uses a selection of typefaces:
+
+- DM Serif Display for headings
+- EB Garamond for body copy, falling back to Georgia on low-resolution screens
+- Fira Sans for UI elements
+- Fira Mono for code
+
+We know this is a controversial choice! Many people today engage with the written word almost exclusively through screens, and so the sight of serif typefaces might seem offensively strange. It may take some getting used to. We also recognise that there may be some legitimate readability concerns for some people with some combinations of operating system/screen/dark mode preference, and so we beg your understanding while we get everything just so.
+
+## Contributing
+
+As with any big update, there are a few details that still need polish, some of which may have escaped our notice until now. [The codebase is now open source](https://github.com/sveltejs/svelte.dev), and we welcome your contributions.

apps/svelte.dev/content/blog/2024-10-22-svelte-5-is-alive.md

@@ -0,0 +1,96 @@
+---
+title: Svelte 5 is alive
+description: Our biggest release yet
+author: The Svelte team
+authorURL: https://svelte.dev/
+---
+
+After almost 18 months of development, comprising thousands of commits from dozens of contributors, Svelte 5 is finally stable.
+
+It’s the most significant release in the project’s history. Svelte 5 is a ground-up rewrite: your apps will be faster, smaller and more reliable. You’ll be able to write more consistent and idiomatic code. For newcomers to the framework, there’s less stuff to learn.
+
+Despite all that, Svelte is almost completely backwards-compatible with Svelte 4 — for the majority of users, the initial upgrade will be completely seamless:
+
+```json
+{
+	"devDependencies": {
+---		"@sveltejs/vite-plugin-svelte": "^3.0.0",---
+---		"svelte": "^4",---
++++		"@sveltejs/vite-plugin-svelte": "^4.0.0",+++
++++		"svelte": "^5",+++
+		// …
+	}
+}
+```
+
+## What is Svelte?
+
+Svelte is a framework for building user interfaces on the web. It uses a compiler to convert declarative component code, based on HTML, CSS and JavaScript, into tightly optimised JavaScript.
+
+Because the compiler shifts a lot of the work out of the browser and into `npm run build`, Svelte apps are small and fast. But beyond that, Svelte is designed to be an enjoyable and intuitive way to build apps: it prioritises getting stuff done.
+
+The team behind Svelte also maintains SvelteKit, an application framework that handles routing and data loading and server-side rendering and all the gory details that go into building modern websites and apps.
+
+## What changed, and why?
+
+For one thing, we’ve overhauled our website. You can read more about that [here](the-omnisite).
+
+As for Svelte itself, we’ll cover the _why_ first. We’re not fans of change for change’s sake — in fact, Svelte changed less than any other major framework between 2019 (when we launched Svelte 3) and now, which is an eon in front end development. And people really liked Svelte 3 and 4 — it routinely tops developer surveys of satisfaction.
+
+So when we make changes, we don’t make them lightly.
+
+With more and more people building more and bigger applications with Svelte, the limitations of some of our original design decisions started to become more apparent. For example, in Svelte 4, reactivity is driven entirely by the compiler. If you change a single property of a reactive object in Svelte 4, the entire object is invalidated, because that’s all the compiler can realistically do. Meanwhile, other frameworks have adopted fine-grained reactivity based on _signals_, leapfrogging Svelte’s performance.
+
+Equally, component composition is more awkward in Svelte 4 than it should be, largely because it treats event handlers and ‘slotted content’ as separate concepts, distinct from the props that are passed to components. This is because in 2019 it seemed likely that web components would become the primary distribution mechanism for components, and we wanted to align with the platform. This was a mistake.
+
+And while the `$:` construct for reactively re-running statements is a neat trick, it turned out to be a footgun. It conflated two concepts (derived state and side-effects) that really should be kept separate, and because dependencies are determined when the statement is compiled (rather than when it runs), it resists refactoring and becomes a magnet for complexity.
+
+Svelte 5 removes these inconsistencies and footguns. It introduces _runes_, an explicit mechanism for (among other things) declaring reactive state:
+
+```js
+---let count = 0;---
++++let count = $state(0);+++
+```
+
+Interacting with state is unchanged: with Svelte — unlike other frameworks — `count` is just a number, rather than a function, or an object with a `value` property, or something that can only be changed with a corresponding `setCount`:
+
+```js
+let count = 0;
+// ---cut---
+function increment() {
+	count += 1;
+	console.log({ count });
+}
+```
+
+Runes can be used in `.svelte.js` and `.svelte.ts` modules in addition to `.svelte` components, meaning you can create reusable reactive logic using a single mechanism.
+
+Event handlers are now just props like any other, making it easy to (for example) know whether the user of your component supplied a particular event handler (which can be useful for avoiding expensive setup work), or to spread arbitrary event handlers onto some element — things that are particularly important for library authors.
+
+And the `slot` mechanism for passing content between components (together with the confusing `let:` and `<svelte:fragment>` syntax) has been replaced with `{#snippet …}`, a much more powerful tool.
+
+Beyond these changes are countless improvements: native TypeScript support (no more preprocessors!), many bugfixes, and performance and scalability improvements across the board.
+
+## How do I upgrade?
+
+If you’re currently on Svelte 3, begin by [migrating to Svelte 4](/docs/svelte/v4-migration-guide).
+
+From there, you can update your `package.json` to use the newest version of `svelte` and ancillary dependencies like `vite-plugin-svelte`.
+
+You don’t _have_ to update your components immediately — in almost all cases, your app will continue working as-is (except faster). But we recommend that you begin to migrate your components to use the new syntax and features. You can migrate your entire app with `npx sv migrate svelte-5`, or — if you’re using VS Code with the Svelte extension — you can migrate components one at a time by selecting ‘Migrate Component to Svelte 5 Syntax’ in your command palette.
+
+Svelte has a large and robust ecosystem of component libraries that you can use in your applications such as [shadcn-svelte](https://shadcn-svelte.com/), [Skeleton](https://www.skeleton.dev/), and [Flowbite Svelte](https://flowbite-svelte.com/). But you don’t have to wait for these libraries to upgrade to Svelte 5 in order to upgrade your own application.
+
+Eventually, support for Svelte 4 syntax will be phased out, but this won’t happen for a while and you’ll have plenty of warning.
+
+For more details, see the [comprehensive Svelte 5 migration guide](/docs/svelte/v5-migration-guide).
+
+## Our new CLI
+
+Along with a new version of Svelte, we have a new Command Line Interface (CLI), `sv`, to go with it. You can learn all about it in [the `sv` announcement video](https://www.youtube.com/watch?v=fAPFsRP-mbc#t=3h15m40s) and in a forthcoming blog post.
+
+## What’s next?
+
+We plan to release a new version of SvelteKit in the near future that takes advantage of the new Svelte 5 features. In the meantime, you can use Svelte 5 with SvelteKit today, and `npx sv create` will create a new SvelteKit project with Svelte 5 installed alongside it.
+
+After that, we have a laundry list of ideas we want to implement in Svelte itself. This release is the foundation for many improvements that would have been impossible to build on top of Svelte 4, and we can’t wait to roll up our sleeves.