Is SvelteKit worth using or should people just use plain svelte or vanilla javascript?
This is the question that @yamessays asked me on my story on How to write a Chrome extension with SvelteKit.
I hadn't asked myself that, focusing instead on discovering if it was possible, how to make it work and seeing it in action. So after a couple days thinking and going back on my projects, I've come up with the following list of why you should and shouldn't use SvelteKit with Chrome Extensions and my take on which factors you should consider to make that decision.
Disclaimer
I am by no means a Svelte or Chrome Extension expert. I've written a few extensions in Vanilla JS and one with SvelteKit.
This analysis assumes that the extension you are writing uses Manifest V3.
Introduction
Svelte is a front end reactive web framework that allows developers to make highly reactive websites easily. It compiles your code into native js, html5 and css to make your websites quick and powerful.
Svelte comes with many useful tools, notably stores for state management. Stores are managed data that can be referenced, accessed and updated anywhere in your app.
Pros:
- Reactivity: if you want to make your extension display a reactive popup this would be a great way to build it, make it interactive and reactive.
- Stateful: if you need your extension to hold a state (persistent or not), Svelte's store is a great tool that helps you manage user credentials or preferences in your extension. Furthermore, the store allows you to easily send and receive data to your service worker and the tab on which your user is currently.
- Speed: because all of your JS is already bundled and compiled into one file or multiple chunks, your extension is quick to load and display to the user.
- Use JS libraries: because Svelte is able to bundle and compile all of your dependencies together it makes it extremely easy to use third party JS libraries. I used Supabase's library in my extension as I did on my website to handle user login.
- Use CSS libraries framework: Same thing here, because of how Svelte processes and compiles your code, you can use CSS frameworks such as Tailwind directly on your extensions
- Routes: you are able to use routes in your extension's popup to manage what you display to the user easily and manage your pages as your would a normal web app.
- Single codebase: if your extension shares code with another of your products (e.g. your product's website), having a shared codebase for your components, layouts and styles may be extremely useful for your development needs.
Cons:
- Your IDE will scream bloody murder if you try to use the chrome api's (as its not expecting those to be present).
- You will still have to write custom JS to have a deeper interaction with the current tab/webpage (outside of what is offered through the chrome api).
Caveats:
- You are unable to use Svelte on any injected files. This means that you cannot use it to control the DOM on the user's window, only the DOM that is provided for the popups/action/alerts from the Chrome extension context. Thus if your app has to interact or retrieve information from the webpage without the extension popup being open, you'll have to write custom JS to manipulate the DOM, maybe even use JQuery to help you in doing so. This could have been possible previously with Chrome's Manifest V2 but with the deprecation of V2 and stable rollout of V3, many more restrictions have been put in place.
Final Verdict
It all comes down to what you want to build. If your extension focuses on having a user interact with your service on any given web page and requires limited knowledge of the current tab/page, then yes, this is a good way to quickly build an extension and scale it.
If your extension attempts to improve the user's experience on a given webpage by adding features to it, you'll go back to writing vanilla JS and Svelte won't be of much use.
If you're injecting functionality that is only partly reliant on the current page (e.x. amazon price tracker) then Svelte and Svelte kit can be very useful but might be better suited as web-components to avoid style and javascript collisions.
Top comments (0)