Svelte is currently my framework of choice for frontend web development.

1. You can bundle your backend (server side code) and frontend into one SvelteKit application but I don’t recommend it. Any non-trivial application will have a sizable backend API and it will only grow over time. Resist the urge and split the backend API into separate ExpressJS app. This way you can hand off backend development to a separate engineer, test the backend independently and if you are outsourcing frontend development, you don’t have to share your backend code. Another benefit is that when you develop mobile clients they can share the same backend. Also this way you can get rid of those pesky cross-origin requests are not allowed errors. That’s half-a-dozen advantages (did you count?) if not more.
2. If you are developing internal applications and don’t care about SEO you can create a SPA and serve it via NGINX or Apache. Just set export let ssr = false in src/routes/layout.js.
3. How do you decide whether a dependency goes under dependencies or devDependency? Use following flowchart: is the dependency used by client-side code or server-side code? If client-side (i.e., browser), it goes under devDependencies. If server-side it goes under dependencies. If you paid attention to tip #1 and all server-side code is in a separate project, all your dependencies can go under devDependencies. Btw, the whole issue becomes a moot point (not applicable) if you will be building the app on the server prior to deployment. Let me explain: when it comes to deployment you have two choices: Option1: the code is built on the same machine on which it is deployed. Option 2: the code is built on a separate machine and the build artifacts are deployed on the deployment machine (i.e., there are separate machines in charge of building the code (CI/CD) and running the code). The dependency vs devDependencies distinction is meaningful only for Option 2. If you are using Option 1, you still need to install all the devDependencies to build your code.
4. SvelteKit docs don’t mention it but the whole section they have on error handling is w.r.t. handling a request to the server and the built-in error handling only kicks into effect if the error happens inside the load function or +server.js. When your application is running in the browser and an error happens, SvelteKit won’t catch it. The browser javascript code is not running on top of any framework. Its the server-side code that runs on top of a framework so the framework is able to catch an exception. This was the biggest gotcha for me and I spent a lot of time debugging why my client-side errors were not being handled (since the docs don’t provide the clarification)
5. The other issue which caused me lot of pain is the dreadful Cross-site POST form submissions are forbidden. If you are using Tip #1 then we side-step the issue entirely. Another benefit of not putting any server-side logic in your Svelte application.
6. Remember process.env does not exist in the browser (this shouldn’t need to be mentioned but I am a backend developer). Use this for env variables on the client-side.
7. There are some important differences between npm run dev and running the application using node build. Of course in the former case you will get hot loading (you don’t have to re-run the app if you make changes to a file) and that’s what we mostly think about but also keep in mind that files like vite.config.ts have no effect when the application is run using node build. You are not using vite in that case so vite configuration does not matter.
8. Understand the role of SvelteKit adapters and the difference between Svelte and SvelteKit. The adapters determine how your application is built (i.e., what happens when you run npm run build) and deployed for a specific platform.
9. I shouldn’t have to say this but make sure to test how the app behaves when there is an error calling the backend. This is my pet-peeve. Often time engineers only test the happy path and there is nothing more embarrassing than an error in the error handling code. This is one thing that differentiates a junior engineer from a senior one. Use a mock backend to test out the UI code thoroughly and decouple UI developer from backend developer – both can develop independently and UI developer need not be blocked on backend developer.
10. For the UI I currently use SMUI and am satisfied with it. I am generally a fan of the look and feel of Google products and the SMUI library has concise documentation with examples. Many other libraries have so much documentation that it becomes difficult to get started and you have to learn a lot of concepts and background just to become productive. You don’t necessarily have to use a UI library. I use it because standard HTML does not provide some UI elements that are present in SMUI (for example standard HTML has no menu). But if you are using a UI library then be consistent and don’t mix and match. What Svelte UI library is your favorite and what is your top tip for Svelte development? Drop me a comment below

Further Reading

• https://www.youtube.com/watch?v=Jf0cjocP8Wk