diff --git a/sites/svelte.dev/.env b/sites/svelte.dev/.env new file mode 100644 index 0000000000..ef80c3ff5d --- /dev/null +++ b/sites/svelte.dev/.env @@ -0,0 +1,19 @@ +# for local development, copy this file to .env.local file and +# fill in the blanks + +# server-side +GITHUB_CLIENT_ID= +GITHUB_CLIENT_SECRET= + +# Path to local copy of Svelte relative from sites/svelte.dev. Used by the REPL. +# Optional. The default value assumes the svelte repo and sites repo are in the same directory. +# LOCAL_SVELTE_PATH=../../../svelte + +# staging database +SUPABASE_URL=https://kpaaohfbmxvespqoqdzp.supabase.co +SUPABASE_KEY= + +PUBLIC_API_BASE="https://api.svelte.dev" + +# client-side +VITE_MAPBOX_ACCESS_TOKEN= diff --git a/sites/svelte.dev/.eslintrc.cjs b/sites/svelte.dev/.eslintrc.cjs new file mode 100644 index 0000000000..2284c1c420 --- /dev/null +++ b/sites/svelte.dev/.eslintrc.cjs @@ -0,0 +1,54 @@ +module.exports = { + root: true, + rules: { + indent: [2, 'tab', { SwitchCase: 1 }], + semi: [2, 'always'], + 'keyword-spacing': [2, { before: true, after: true }], + 'space-before-blocks': [2, 'always'], + 'no-mixed-spaces-and-tabs': [2, 'smart-tabs'], + 'no-cond-assign': 0, + 'no-unused-vars': 2, + 'object-shorthand': [2, 'always'], + 'no-const-assign': 2, + 'no-class-assign': 2, + 'no-this-before-super': 2, + 'no-var': 2, + 'no-unreachable': 2, + 'valid-typeof': 2, + 'quote-props': [2, 'as-needed'], + 'one-var': [2, 'never'], + 'prefer-arrow-callback': 2, + 'prefer-const': [2, { destructuring: 'all' }], + 'arrow-spacing': 2, + 'no-inner-declarations': 0, + 'require-atomic-updates': 0 + }, + env: { + es6: true, + browser: true, + node: true, + mocha: true + }, + extends: ['eslint:recommended', 'plugin:import/errors', 'plugin:import/warnings'], + plugins: ['svelte3'], + overrides: [ + { + files: ['*.svelte'], + processor: 'svelte3/svelte3' + } + ], + parserOptions: { + ecmaVersion: 9, + sourceType: 'module' + }, + settings: { + 'import/core-modules': ['svelte'], + 'svelte3/compiler': (() => { + try { + return require('svelte/compiler'); + } catch (e) { + return null; + } + })() + } +}; diff --git a/sites/svelte.dev/.gitignore b/sites/svelte.dev/.gitignore index 6635cf5542..fd1700f0b3 100644 --- a/sites/svelte.dev/.gitignore +++ b/sites/svelte.dev/.gitignore @@ -1,10 +1,11 @@ -.DS_Store -node_modules -/build -/.svelte-kit -/package -.env -.env.* -!.env.example -vite.config.js.timestamp-* -vite.config.ts.timestamp-* +/.env.local +/.svelte-kit/ +/build/ +/functions/ + +/static/svelte-app.json +/scripts/svelte-app/ +/src/routes/_components/Supporters/contributors.jpg +/src/routes/_components/Supporters/contributors.js +/src/routes/_components/Supporters/donors.jpg +/src/routes/_components/Supporters/donors.js diff --git a/sites/svelte.dev/.npmrc b/sites/svelte.dev/.npmrc deleted file mode 100644 index b6f27f1359..0000000000 --- a/sites/svelte.dev/.npmrc +++ /dev/null @@ -1 +0,0 @@ -engine-strict=true diff --git a/sites/svelte.dev/.prettierignore b/sites/svelte.dev/.prettierignore deleted file mode 100644 index 38972655fa..0000000000 --- a/sites/svelte.dev/.prettierignore +++ /dev/null @@ -1,13 +0,0 @@ -.DS_Store -node_modules -/build -/.svelte-kit -/package -.env -.env.* -!.env.example - -# Ignore files for PNPM, NPM and YARN -pnpm-lock.yaml -package-lock.json -yarn.lock diff --git a/sites/svelte.dev/.prettierrc b/sites/svelte.dev/.prettierrc index a77fddea90..1cb44838c1 100644 --- a/sites/svelte.dev/.prettierrc +++ b/sites/svelte.dev/.prettierrc @@ -1,9 +1,5 @@ { - "useTabs": true, "singleQuote": true, - "trailingComma": "none", "printWidth": 100, - "plugins": ["prettier-plugin-svelte"], - "pluginSearchDirs": ["."], - "overrides": [{ "files": "*.svelte", "options": { "parser": "svelte" } }] + "useTabs": true } diff --git a/sites/svelte.dev/README.md b/sites/svelte.dev/README.md index 5c91169b0c..47cc33dd74 100644 --- a/sites/svelte.dev/README.md +++ b/sites/svelte.dev/README.md @@ -1,38 +1,69 @@ -# create-svelte +## Running locally -Everything you need to build a Svelte project, powered by [`create-svelte`](https://github.com/sveltejs/kit/tree/master/packages/create-svelte). +A local database is only required in dev mode if you want to test reading and writing saved REPLs on it. Without a local database in dev mode, the REPL will be able to load saved REPLs from the production database, but not save them. -## Creating a project +Note also that in dev mode, the REPL will currently only work in Chrome, [as noted in the Vite documentation](https://vitejs.dev/guide/features.html#web-workers), pending support in Firefox for `import` statements in web workers. -If you're seeing this, you've probably already done this step. Congrats! +If you do want to use a database, set it up on [Supabase](https://supabase.com) with the instructions [here](../../db) and set the corresponding environment variables. -```bash -# create a new project in the current directory -npm create svelte@latest +Run the site sub-project: -# create a new project in my-app -npm create svelte@latest my-app +```bash +pnpm install +pnpm dev ``` -## Developing +and navigate to [localhost:5173](http://localhost:5173). -Once you've created a project and installed dependencies with `npm install` (or `pnpm install` or `yarn`), start a development server: +The first time you run the site locally, it will update the list of Contributors and REPL dependencies. After this it won't run again unless you force it by running: ```bash -npm run dev - -# or start the server and open the app in a new browser tab -npm run dev -- --open +pnpm update ``` -## Building +## Running using the local copy of Svelte + +By default, the REPL will fetch the most recent version of Svelte from https://unpkg.com/svelte. When running the site locally, you can also use your local copy of Svelte. -To create a production version of your app: +To produce the proper browser-compatible UMD build of the compiler, you will need to run `npm run build` (or `npm run dev`) in the `svelte` repository with the `PUBLISH` environment variable set to any non-empty string: ```bash -npm run build +git clone https://github.com/sveltejs/svelte.git +cd svelte +npm ci +PUBLISH=1 npm run build ``` -You can preview the production build with `npm run preview`. +The default configuration assumes that the `sites` repository and the `svelte` repository are in the same directory. If not, you can set `LOCAL_SVELTE_PATH` in `sites/svelte.dev/.env` to a different path to the local copy of Svelte. + +Then visit the REPL at [localhost:5173/repl?version=local](http://localhost:5173/repl?version=local). Please note that the local REPL only works with `pnpm dev` and not when building the site for production usage. + +## REPL GitHub integration + +In order for the REPL's GitHub integration to work properly when running locally, you will need to: + +- [create a GitHub OAuth app](https://github.com/settings/developers): + - set `Authorization callback URL` to `http://localhost:5173/auth/callback`; + - set `Application name` as you like, and `Homepage URL` as `http://localhost:5173/`; + - create the app and take note of `Client ID` and `Client Secret` +- in this directory, create an `.env.local` file (see `.env.example`) containing: + ``` + GITHUB_CLIENT_ID=[your app's Client ID] + GITHUB_CLIENT_SECRET=[your app's Client Secret] + ``` + +The GitHub app requires a specific callback URL, and so cannot be used with the preview deployment in the staging environment. + +## Building the site + +To build the website, run `pnpm build`. The output can be found in `build`. + +## Testing + +Tests can be run using `pnpm test`. + +## Translating the API docs + +Anchors are automatically generated using headings in the documentation and by default (for the english language) they are latinised to make sure the URL is always conforming to RFC3986. -> To deploy your app, you may need to install an [adapter](https://kit.svelte.dev/docs/adapters) for your target environment. +If we need to translate the API documentation to a language using unicode chars, we can setup this app to export the correct anchors by setting up `SLUG_PRESERVE_UNICODE` to `true` in `config.js`. diff --git a/sites/svelte.dev/config.js b/sites/svelte.dev/config.js new file mode 100644 index 0000000000..097bd173a8 --- /dev/null +++ b/sites/svelte.dev/config.js @@ -0,0 +1,2 @@ +export const SLUG_PRESERVE_UNICODE = false; +export const SLUG_SEPARATOR = '_'; diff --git a/sites/svelte.dev/content/blog/2016-11-26-frameworks-without-the-framework.md b/sites/svelte.dev/content/blog/2016-11-26-frameworks-without-the-framework.md new file mode 100644 index 0000000000..b29525dec3 --- /dev/null +++ b/sites/svelte.dev/content/blog/2016-11-26-frameworks-without-the-framework.md @@ -0,0 +1,55 @@ +--- +title: "Frameworks without the framework: why didn't we think of this sooner?" +description: You can't write serious applications in vanilla JavaScript without hitting a complexity wall. But a compiler can do it for you. +author: Rich Harris +authorURL: https://twitter.com/Rich_Harris +--- + +> Wait, this new framework has a *runtime*? Ugh. Thanks, I'll pass. +> **– front end developers in 2018** + +We're shipping too much code to our users. Like a lot of front end developers, I've been in denial about that fact, thinking that it was fine to serve 100kb of JavaScript on page load – just use [one less .jpg!](https://twitter.com/miketaylr/status/227056824275333120) – and that what *really* mattered was performance once your app was already interactive. + +But I was wrong. 100kb of .js isn't equivalent to 100kb of .jpg. It's not just the network time that'll kill your app's startup performance, but the time spent parsing and evaluating your script, during which time the browser becomes completely unresponsive. On mobile, those milliseconds rack up very quickly. + +If you're not convinced that this is a problem, follow [Alex Russell](https://twitter.com/slightlylate) on Twitter. Alex [hasn't been making many friends in the framework community lately](https://twitter.com/slightlylate/status/728355959022587905), but he's not wrong. But the proposed alternative to using frameworks like Angular, React and Ember – [Polymer](https://www.polymer-project.org/1.0/) – hasn't yet gained traction in the front end world, and it's certainly not for a lack of marketing. + +Perhaps we need to rethink the whole thing. + + +## What problem do frameworks *really* solve? + +The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that's not really true. At best, frameworks *move the complexity around*, away from code that you had to write and into code you didn't. + +Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your *concepts*. Frameworks are primarily a tool for structuring your thoughts, not your code. + +Given that, what if the framework *didn't actually run in the browser*? What if, instead, it converted your application into pure vanilla JavaScript, just like Babel converts ES2016+ to ES5? You'd pay no upfront cost of shipping a hefty runtime, and your app would get seriously fast, because there'd be no layers of abstraction between your app and the browser. + + +## Introducing Svelte + +Svelte is a new framework that does exactly that. You write your components using HTML, CSS and JavaScript (plus a few extra bits you can [learn in under 5 minutes](https://v2.svelte.dev/guide)), and during your build process Svelte compiles them into tiny standalone JavaScript modules. By statically analysing the component template, we can make sure that the browser does as little work as possible. + +The [Svelte implementation of TodoMVC](https://svelte-todomvc.surge.sh/) weighs 3.6kb zipped. For comparison, React plus ReactDOM *without any app code* weighs about 45kb zipped. It takes about 10x as long for the browser just to evaluate React as it does for Svelte to be up and running with an interactive TodoMVC. + +And once your app *is* up and running, according to [js-framework-benchmark](https://github.com/krausest/js-framework-benchmark) **Svelte is fast as heck**. It's faster than React. It's faster than Vue. It's faster than Angular, or Ember, or Ractive, or Preact, or Riot, or Mithril. It's competitive with Inferno, which is probably the fastest UI framework in the world, for now, because [Dominic Gannaway](https://twitter.com/trueadm) is a wizard. (Svelte is slower at removing elements. We're [working on it](https://github.com/sveltejs/svelte/issues/26).) + +It's basically as fast as vanilla JS, which makes sense because it *is* vanilla JS – just vanilla JS that you didn't have to write. + + +## But that's not the important thing + +Well, it *is* important – performance matters a great deal. What's really exciting about this approach, though, is that we can finally solve some of the thorniest problems in web development. + +Consider interoperability. Want to `npm install cool-calendar-widget` and use it in your app? Previously, you could only do that if you were already using (a correct version of) the framework that the widget was designed for – if `cool-calendar-widget` was built in React and you're using Angular then, well, hard cheese. But if the widget author used Svelte, apps that use it can be built using whatever technology you like. (On the TODO list: a way to convert Svelte components into web components.) + +Or [code splitting](https://twitter.com/samccone/status/797528710085652480). It's a great idea (only load the code the user needs for the initial view, then get the rest later), but there's a problem – even if you only initially serve one React component instead of 100, *you still have to serve React itself*. With Svelte, code splitting can be much more effective, because the framework is embedded in the component, and the component is tiny. + +Finally, something I've wrestled with a great deal as an open source maintainer: your users always want *their* features prioritised, and underestimate the cost of those features to people who don't need them. A framework author must always balance the long-term health of the project with the desire to meet their users' needs. That's incredibly difficult, because it's hard to anticipate – much less articulate – the consequences of incremental bloat, and it takes serious soft skills to tell people (who may have been enthusiastically evangelising your tool up to that point) that their feature isn't important enough. But with an approach like Svelte's, many features can be added with absolutely no cost to people who don't use them, because the code that implements those features just doesn't get generated by the compiler if it's unnecessary. + + +## We're just getting started + +Svelte is very new. There's a lot of work still left to do – creating build tool integrations, adding a server-side renderer, hot reloading, transitions, more documentation and examples, starter kits, and so on. + +But you can already build rich components with it, which is why we've gone straight to a stable 1.0.0 release. [Read the guide](https://v2.svelte.dev/guide), [try it out in the REPL](/repl), and head over to [GitHub](https://github.com/sveltejs/svelte) to help kickstart the next era of front end development. diff --git a/sites/svelte.dev/content/blog/2017-08-07-the-easiest-way-to-get-started.md b/sites/svelte.dev/content/blog/2017-08-07-the-easiest-way-to-get-started.md new file mode 100644 index 0000000000..29e59270d0 --- /dev/null +++ b/sites/svelte.dev/content/blog/2017-08-07-the-easiest-way-to-get-started.md @@ -0,0 +1,66 @@ +--- +title: The easiest way to get started with Svelte +description: This'll only take a minute. +author: Rich Harris +authorURL: https://twitter.com/Rich_Harris +--- + +Svelte is a [new kind of framework](/blog/frameworks-without-the-framework). Rather than putting a ` diff --git a/sites/svelte.dev/content/blog/2019-04-15-setting-up-your-editor.md b/sites/svelte.dev/content/blog/2019-04-15-setting-up-your-editor.md new file mode 100644 index 0000000000..65d0234645 --- /dev/null +++ b/sites/svelte.dev/content/blog/2019-04-15-setting-up-your-editor.md @@ -0,0 +1,65 @@ +--- +title: Setting up your editor +description: Instructions for configuring linting and syntax highlighting +author: Rich Harris +authorURL: https://twitter.com/Rich_Harris +draft: true +--- + +*__Coming soon__* + +This post will walk you through setting up your editor so that it recognises Svelte files: + +* eslint-plugin-svelte3 +* svelte-vscode +* associating .svelte files with HTML in VSCode, Sublime, etc. + +## Atom + +To treat `*.svelte` files as HTML, open *__Edit → Config...__* and add the following lines to your `core` section: + +```cson +"*": + core: + … + customFileTypes: + "text.html.basic": [ + "svelte" + ] +``` + +## Vim/Neovim + +You can use the [coc-svelte extension](https://github.com/coc-extensions/coc-svelte) which utilises the official language-server. + +As an alternative you can treat all `*.svelte` files as HTML. Add the following line to your `init.vim`: + +``` +au! BufNewFile,BufRead *.svelte set ft=html +``` + +To temporarily turn on HTML syntax highlighting for the current buffer, use: + +``` +:set ft=html +``` + +To set the filetype for a single file, use a [modeline](https://vim.fandom.com/wiki/Modeline_magic): + +``` + +``` + +## Visual Studio Code + +We recommend using the official [Svelte for VS Code extension](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode). + +## JetBrains WebStorm + +The [Svelte Framework Integration](https://plugins.jetbrains.com/plugin/12375-svelte/) can be used to add support for Svelte to WebStorm, or other Jetbrains IDEs. Consult the [WebStorm plugin installation guide](https://www.jetbrains.com/help/webstorm/managing-plugins.html) on the JetBrains website for more details. + +## Sublime Text 3 + +Open any `.svelte` file. + +Go to *__View → Syntax → Open all with current extension as... → HTML__*. diff --git a/sites/svelte.dev/content/blog/2019-04-16-svelte-for-new-developers.md b/sites/svelte.dev/content/blog/2019-04-16-svelte-for-new-developers.md new file mode 100644 index 0000000000..834e042138 --- /dev/null +++ b/sites/svelte.dev/content/blog/2019-04-16-svelte-for-new-developers.md @@ -0,0 +1,100 @@ +--- +title: Svelte for new developers +description: Never used Node.js or the command line? No problem +author: Rich Harris +authorURL: https://twitter.com/Rich_Harris +--- + +This short guide is designed to help you — someone who has looked at the [tutorial](/tutorial) and wants to start creating Svelte apps, but doesn't have a ton of experience using JavaScript build tooling — get up and running. + +If there are things that don't make sense, or that we're glossing over, feel free to [raise an issue](https://github.com/sveltejs/svelte/issues) or [suggest edits to this page](https://github.com/sveltejs/svelte/blob/master/site/content/blog/2019-04-16-svelte-for-new-developers.md) that will help us help more people. + +If you get stuck at any point following this guide, the best place to ask for help is in the [chatroom](https://svelte.dev/chat). + + +## First things first + +You'll be using the *command line*, also known as the terminal. On Windows, you can access it by running **Command Prompt** from the Start menu; on a Mac, hit `Cmd` and `Space` together to bring up **Spotlight**, then start typing `Terminal.app`. On most Linux systems, `Ctrl-Alt-T` brings up the command line. + +The command line is a way to interact with your computer (or another computer! but that's a topic for another time) with more power and control than the GUI (graphical user interface) that most people use day-to-day. + +Once on the command line, you can navigate the filesystem using `ls` (`dir` on Windows) to list the contents of your current directory, and `cd` to change the current directory. For example, if you had a `Development` directory of your projects inside your home directory, you would type + +```bash +cd Development +``` + +to go to it. From there, you could create a new project directory with the `mkdir` command: + +```bash +mkdir svelte-projects +cd svelte-projects +``` + +A full introduction to the command line is out of the scope of this guide, but here are a few more useful commands: + +* `cd ..` — navigates to the parent of the current directory +* `cat my-file.txt` — on Mac/Linux (`type my-file.txt` on Windows), lists the contents of `my-file.txt` +* `open .` (or `start .` on Windows) — opens the current directory in Finder or File Explorer + + +## Installing Node.js + +[Node](https://nodejs.org/en/) is a way to run JavaScript on the command line. It's used by many tools, including Svelte. If you don't yet have it installed, the easiest way is to download the latest version straight from the [website](https://nodejs.org/en/). + +Once installed, you'll have access to three new commands: + +* `node my-file.js` — runs the JavaScript in `my-file.js` +* `npm [subcommand]` — [npm](https://www.npmjs.com/) is a way to install 'packages' that your application depends on, such as the [svelte](https://www.npmjs.com/package/svelte) package +* `npx [subcommand]` — a convenient way to run programs available on npm without permanently installing them + + +## Installing a text editor + +To write code, you need a good editor. The most popular choice is [Visual Studio Code](https://code.visualstudio.com/) or VSCode, and justifiably so — it's well-designed and fully-featured, and has a wealth of extensions ([including one for Svelte](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode), which provides syntax highlighting and diagnostic messages when you're writing components). + + +## Creating a project + +We're going to use the [Svelte + Vite](https://github.com/vitejs/vite/tree/main/packages/create-vite/template-svelte) template. You don't have to use a project template, but it means you have to do a lot less setup work. + +On the command line, navigate to where you want to create a new project, then type the following lines (you can paste the whole lot, but you'll develop better muscle memory if you get into the habit of writing each line out one at a time then running it): + +```bash +npm create vite@latest my-svelte-project -- --template svelte +cd my-svelte-project +npm install +``` + +> You can replace `--template svelte` with `--template svelte-ts`, if you prefer TypeScript. + +This creates a new directory, `my-svelte-project`, adds files from the [create-vite/template-svelte](https://github.com/vitejs/vite/tree/main/packages/create-vite/template-svelte) template, and installs a number of packages from npm. Open the directory in your text editor and take a look around. The app's 'source code' lives in the `src` directory, while the files your app can load are in `public`. + +In the `package.json` file, there is a section called `"scripts"`. These scripts define shortcuts for working with your application — `dev`, `build` and `preview`. To launch your app in development mode, type the following: + +```bash +npm run dev +``` + +Running the `dev` script starts a program called [Vite](https://vitejs.dev/). Vite's job is to take your application's source files, pass them to other programs (including Svelte, in our case) and convert them into the code that will actually run when you open the application in a browser. + +Speaking of which, open a browser and navigate to http://localhost:5173. This is your application running on a local *web server* (hence 'localhost') on port 5173. + +Try changing `src/App.svelte` and saving it. The application will update with your changes. + + +## Building your app + +In the last step, we were running the app in 'development mode'. In dev mode, Svelte adds extra code that helps with debugging, and Vite skips the final step where your app's JavaScript is compressed. + +When you share your app with the world, you want to build it in 'production mode', so that it's as small and efficient as possible for end users. To do that, use the `build` command: + +```bash +npm run build +``` + +Your `dist` directory now contains an optimised version of your app. You can run it like so: + +```bash +npm run preview +``` diff --git a/sites/svelte.dev/content/blog/2019-04-20-write-less-code.md b/sites/svelte.dev/content/blog/2019-04-20-write-less-code.md new file mode 100644 index 0000000000..97e020af90 --- /dev/null +++ b/sites/svelte.dev/content/blog/2019-04-20-write-less-code.md @@ -0,0 +1,164 @@ +--- +title: Write less code +description: The most important metric you're not paying attention to +author: Rich Harris +authorURL: https://twitter.com/Rich_Harris +--- + +All code is buggy. It stands to reason, therefore, that the more code you have to write the buggier your apps will be. + +Writing more code also takes more time, leaving less time for other things like optimisation, nice-to-have features, or being outdoors instead of hunched over a laptop. + +In fact it's widely acknowledged that [project development time](https://blog.codinghorror.com/diseconomies-of-scale-and-lines-of-code/) and [bug count](https://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio) grow *quadratically*, not linearly, with the size of a codebase. That tracks with our intuitions: a ten-line pull request will get a level of scrutiny rarely applied to a 100-line one. And once a given module becomes too big to fit on a single screen, the cognitive effort required to understand it increases significantly. We compensate by refactoring and adding comments — activities that almost always result in *more* code. It's a vicious cycle. + +Yet while we obsess — rightly! — over performance numbers, bundle size and anything else we can measure, we rarely pay attention to the amount of code we're writing. + + +## Readability is important + +I'm certainly not claiming that we should use clever tricks to scrunch our code into the most compact form possible at the expense of readability. Nor am I claiming that reducing *lines* of code is necessarily a worthwhile goal, since it encourages turning readable code like this... + +```js +for (let i = 0; i <= 100; i += 1) { + if (i % 2 === 0) { + console.log(`${i} is even`); + } +} +``` + +...into something much harder to parse: + +```js +for (let i = 0; i <= 100; i += 1) if (i % 2 === 0) console.log(`${i} is even`); +``` + +Instead, I'm claiming that we should favour languages and patterns that allow us to naturally write less code. + + +## Yes, I'm talking about Svelte + +Reducing the amount of code you have to write is an explicit goal of Svelte. To illustrate, let's look at a very simple component implemented in React, Vue and Svelte. First, the Svelte version: + +
+ +
+ +How would we build this in React? It would probably look something like this: + +```js +import React, { useState } from 'react'; + +export default () => { + const [a, setA] = useState(1); + const [b, setB] = useState(2); + + function handleChangeA(event) { + setA(+event.target.value); + } + + function handleChangeB(event) { + setB(+event.target.value); + } + + return ( +
+ + + +

{a} + {b} = {a + b}

+
+ ); +}; +``` + +Here's an equivalent component in Vue: + +```html + + + +``` + + + +In other words, it takes 442 characters in React, and 263 characters in Vue, to achieve something that takes 145 characters in Svelte. The React version is literally three times larger! + +It's unusual for the difference to be *quite* so obvious — in my experience, a React component is typically around 40% larger than its Svelte equivalent. Let's look at the features of Svelte's design that enable you to express ideas more concisely: + + +### Top-level elements + +In Svelte, a component can have as many top-level elements as you like. In React and Vue, a component must have a single top-level element — in React's case, trying to return two top-level elements from a component function would result in syntactically invalid code. (You can use a fragment — `<>` — instead of a `
`, but it's the same basic idea, and still results in an extra level of indentation). + +In Vue, your markup must be wrapped in a `