What is Svelte and what is Svelte Kit?
Svelte is my favorite front-end library. I love it for its simplicity, elegant syntax, and speed. What separates it from frameworks like Vue or React is the fact that Svelte is a compiler which bundles all the development code into vanilla javascript. It means that during runtime, svelte code is not included inside a compiled bundle.
Despite its growing popularity, Svelte is still nowhere in terms of popularity in comparison to giants like React, Angular, or even Vue. It means fewer job offers and fewer third-party packages. Even if a community is great I had an impression that Svelte is not developing as fast as other frameworks and big companies are not eager to use it in large-scale apps because of the lack of a clear roadmap. Although I loved almost everything about Svelte, I think the lack of good tooling was the biggest problem with Svelte. There was no CLI tool like create-react-app or vue create and the Svelte devtools plugin was not so impressive. Also, there was an official Server-Side-Rendering framework based on Svelte, called Sapper. The way you had to create sapper projects using a tool called degit was not so great in my opinion. Also, there were some known issues with rollup and webpack templates. It all paints a picture of a great library but with a little bit of chaos inside its ecosystem. All it lacks is a pinch of consistency.
Fortunately, it looks like Svelte creator was familiar with these issues and in October 2020 he announced Svelte Kit. As it was told, it should merge Svelte and Sapper into a single framework with opinionated architecture and with official CLI. But for me, the biggest news was regarding the usage of native ES Modules via a new bundler called Snowpack. You can test it right now using npm init svelte@next command but this release is unstable so I installed it to get a better idea of what we can expect. I prepared my list of things I expect from Svelte Kit.
1. CLI
Right now neither Svelte nor Sapper doesn’t have a CLI tool that can generate project structure. I think that tool like “Create React App” or “Vue create” is crucial and it makes thousands of apps based on single framework kind of standardized. With a tool like “Vue create” you can choose a couple of options like CSS preprocessor, Linter, Typescript support, and so on. It also makes it easier to scaffold a boilerplate code. The great news is Svelte Kit will have a good CLI tool!
2. Dev tools
I’m not going to lie. I’m a huge fan of Vue Devtools. It is incredible how good, well polished, and good-looking this extension is. For me, it is so handy that I can’t work on more complex Vue apps without it. React Devtools on the other hand is kind of chaotic and has that kind of “still in beta” feel. I would be really glad if Svelte could have dedicated devtools as polished as Vue one. It really makes working on complex apps so much easier.
3. Consistent API
We all know what happened with Angular.js with significant changes in API. Also, the new Composition API in Vue 3 changes how we should write components. Of course, the old Options API still works but it makes unnecessary (in my opinion) division. If you jump to any React codebase I don’t know what to expect. Class components or functional ones based on hooks? When you jump into the Vue codebase, what to expect? Composition API, Options API, or maybe even components based on classes using Vue Class Components? I expect Svelte’s API to be consistent and predictable. I think the simplicity of Svelte makes it almost certain that API won’t change drastically in the future.
4. Development based on ES Modules
It was already announced that during the development process Svelte Kit will make use of native ES Modules using Snowpack. It means blazing-fast build times because there is no need to bundle files during development. What I observed using an alpha version of Svelte Kit is they decided to use Vite (another bundler based on ESM) instead of snowpack. Both tools are and it’s exciting to see how fast it is. On production, Svelte Kit will use Rollup.
5. Fast build times
It’s an expectation but also a reality now. With Vite as a development bundler, build times are crazy fast! Also, HMR works perfectly and can maintain the state of the app even if we are changing the code. I hate long build times while working on huge projects and the ability to build projects within milliseconds will increase developer experience for sure!
6. Server Side Rendering (SSR) and Static Site Generation (SSG)
Svelte itself was just a frontend library. Sapper on the other hand provided Server Side Rendering. For me, the perfect solution is the ability to use CSL (Client Side Rendering), SSR (Server Side Rendering), and SSG (Static Site Generation). This is already possible in frameworks like Next.js when you can decide which page is rendered on the client and which on the backend. I hope this flexibility will be possible with Svelte Kit.
7. Great docs
Vue, React, Gatsby and Next are primary examples of amazing docs. Extensive, good-looking, with many code examples, in-depth explanations, and recipes. I really hope that Svelte Kit will have docs on the same level as the frameworks mentioned above. It’s not an easy task but keeping my fingers crossed!
8. High performance in large scale apps
Many frameworks promise us high performance, boasting various benchmarks. What these benchmarks do not show us is a performance in large-scale apps. Personally, I didn’t have a chance to work on a large-scale Svelte app so I don’t know how it performs already but I hope that even large companies won’t hesitate to build super-large products with Svelte Kit.
9. Typescript support out of the box
In the beginning, Svelte didn’t have Typescript support. It was added later on and the support was quite nice. It is confirmed that Svelte Kit will have full Typescript support and I can confirm that It works really well from what I saw in the alpha version.
10. Filesystem routing but with flexibility
Filesystem routing was already introduced in Sapper so it’s nothing new in Svelte world but I would love to see more flexibility on that file system routing. Having routes based on your directories and files are super nice but what if you have a slightly more complex situation. What if you want to build CMS with routes coming from the API? I hope that we as users will have many options to customize the behavior of file system routing without doing unnecessary tricks.
Top comments (0)