Reflections on Migrating My SaaS to SvelteKit | Hacker News Reader

Reflections on Migrating My SaaS to SvelteKit

sveltekitsaas.com

66 pointsGlench44 comments

The more I see it the more I'm certain that Rich and the team screwed the pooch with the whole '+page.server.ts' stuff.

They should really be using the existing <script context="module"> syntax to have a context="server" portion instead of splitting the file out.

Heck, it could even just be an import for a server.ts file in the same root directory if people really liked the +whatever style of having the server code separated.

It feels especially redundant when you're building a static app or SPA. The sort of overly opinionated nonsense that put me off React and on to Svelte in the first place.

I've decided against making the switch to SvelteKit and instead rely on good old Svelte because I can have a /pages/Whatever.svelte encapsulates the structure and core logic of each view/page. It's clean, it's HTML-like, it works and more importantly, I can immediately wrap my head around it when coming back to the project after a period away.

I deeply love the guy, but I really think Rich should walk back this decision and default to the "whats the cleanest pattern that people can easily wrap their head around" approach.

IMO, separate files are clearer. I'd even argue that mixing server and client in one file with a made up framework semantics isn't the cleanest pattern that people can easily wrap their head around. Rich made this point in his most recent talk in the section about implicit DSLs.

What works for one person might not work for another. It's not one-size-fits all.

I’ll take the opinionated and enforced structure. Even when they aren’t what I would choose. I like ecosystems with standardization.

That said… the one bit I can’t stand is every file having the same name. Working on 4 “+page.svelte” files at the same time breaks every dev environment I’ve ever liked (vscode, vim tabs). It seems to be fighting the tools and mental models I have.

Me too. I absolutely love svelteKit but this is the most baffling decision, it makes searching for files in vscode so much slower and makes managing open tabs a mess. Even just being able to add an extra word and an extra dot to identify a file would make it tolerable. Like +home.page.svelte or something.

Exactly

I finally have a massive Sveltekit project I'm working on, and yeah... I have to close all tabs because it gets way too confusing to juggle all those files.

Same I’ve been working on a very large spa and I had to add comments at the top of files so I can quickly find them when I need to open them.

Not ideal but not the biggest deal. And definitely not enough to trade Svelte in for something else.

Same. Although I've migrated all of my projects to a single SvelteKit monorepo. This is a really disparate mix of things: creative coding sketches, webview GUIs, personal sites.

I find the problem isn't necessarily the opinionated layout of Kit - I respect that they are trying to establish a sane pattern for frontenders to use. The problem is that this is locked down and enforced in the config and adaptors. Perhaps too much influence via way of the zeroconf web hosting services contributors work at.

Most problems I encounter, in particular of the SPA / making-a-quick-sketch kind, could be solved by more hackable control of the build system. Sometimes I'd like my routes in a single file, sometimes excluding some routes, sometimes a different pattern than +page.

If this breaks something, so what? You have the means to fix it or find a way. As it stands I find myself plugging away at an obtuse JSON object, or must make a my-weird-way-of-doing-things fork. Appeal to the maintainers and it reinforces a papa-knows-best attitude.

Just open it up, make the build system hackable - then see how people decide to use it.

Rich Harris (Svelte creator) gives his counter arguments in his most recent talk: https://youtu.be/uXCipjbcQfM

He describes the drawbacks of mixing backend and frontend code in the same file in the Implicit DSLs section.

There's other ways to do it though that don't break tools like pagename.server.svelte

Agree 100%. The routing is one of the main reasons I'm not using SvelteKit.

It's bonkers they decided to do this and not provide some sort of escape hatch.

SvelteKit is a very complete and well designed solution. Routing, data loading, forms, SSR, caching, dealing with environment variables - all very nice. The only "drawback" is Svelte - I just don't like the data binding thing and prefer working with React components and hooks. Maybe that's just because I've spent so much time in React/Next. Well written React code is actually quite easy to debug, reason about and debug. I find it super annoying to refactor Svelte code because every time I want to extract some code into a component it can't be a function in the same file before it becomes a whole new file. It has to be a file. Also haven't found anything nearly as nice as Framer Motion and Radix in Svelte land.

With all the love in the world, that's probably down to the sunk-cost fallacy. You've invested a chunk of time into understanding the idiosyncrasies and non-standard methodologies that React has pushed at you over the years.

Svelte's pattern for data binding (with the exception of the $: reactivity) is exceptionally idiomatic and as close to standard web as 2-way reactivity will ever be. Easy to get to grips with as a newbie and a breath of fresh air for someone with years of fe experience under their belt.

Svelte embodies the KISS principle and long may that last.

See, that's what a lot of people say about Ruby.

But some weird people like me enjoy JavaScript despite its downsides and find Ruby terrible.

Maybe its irrational but familiarity sometimes wins over level of idiomacy.

Everything in React is just a function, so there is expectation of how it works. The data binding in Svelte is a bit magical and not always clear if there are race conditions, but I'm a Svelte noob trying to port my existing app to it.

SvelteKit is really, really great for small to medium sized projects. The amount of stuff you get "for free" (prerendering, ssr, decent SEO) by using SvelteKit is so nice.

That being said, I definitely agree with the sentiment here that the file based routing is sub-optimal and I think the hurt goes up exponentially with the size of a project. I've also found that straying off the opinionated path even a little gets you in all sorts of trouble almost immediately. For me it was trying to add a SvelteKit app to an existing Nx codebase, did manage to make it work in the end luckily.

Btw, if anyone has found a good solution for creating an OpenAPI spec for SvelteKit server routes, let me know. :)

> That being said, I definitely agree with the sentiment here that the file based routing is sub-optimal

Not sure if you're talking about the article, but I'm the author and I love file-based routing. I think it's an exceptionally good idea that makes it so much easier to figure out where code lives. Haven't yet run into an issue that makes it "sub-optimal" like you said, but SvelteKit's node adapter does make it so you can set any routes you want with plain old Express.

this is exactly what i am thinking. i ended up building my own router that tries to use an openAPI schema as the sole source of truth but pre-populates the schema based on folder structure so that simple setups behave nearly identical to file based routers. the difference is that you can drop pre-populated routes when the app gets more complex and gradually move to a schema based approach and do things like extract more complex data from url, validation and reuse pages at different places etc.

Sounds cool! If you have any code you're willing to share, I'd love to take a look :)

I am so confused that both next and svelte seem to be entirely fine with x identically named files being concurrently open, which directory based routing has given rise to by design.

Surely, this issue can not hand waved away by the entire team of two major web frameworks, while they are currently trying to establish directory based routing as a new paradigm?

Modern editors have pretty good tab labeling to help you figure out which file is where. Plus, I personally rarely work on completely different routes at the same time.

To me the issue is not so much tab labels but searching for files. I rarely use the file explorer to move around a project.

I think the only two negatives I got of sveltekit is:

1. Ecosystem - there's not a lot if any battle tested libraries for svelte at the moment, especially for data tables (tanstack does not have good performance and there's not much documentation for svelte), this will get better with time.

2. You have to do it the svelte way - whenever it's routing or using certain libraries that are vdom, it's usually not a painless experience.

With that said I still really love using svelte and honestly it saved me from giving up on web development.

Maybe AG Grid + Svelte? https://ag-grid-svelte.michael.kim/guide/overview/ The free/community version of AG Grid goes an awfully long way.

> The naming conventions for routes is a little bonkers. Now when I’m working on my app I have like 10 tabs open that all have the name +page.server.ts. Does anyone know how I can make this better in vim?

:help setting-tabline

Low-level stuff; consolidating with some kind of project root directory concept and patterns would be convenient for such cases.

   > :help setting-tabline

For VSCode users:

   Workbench > Editor: Label Format

Set to short will append the directory name right after the file name on the tabs, making it painless to work with the file structure.

> The naming conventions for routes is a little bonkers

Yep. File-based routing is already in itself a questionable idea, but to me the whole +page thing is a deal breaker. I doubt they will change course on that but I hope they will add an alternative way of configuring routes, the request flow, etc.

SvelteKit has actually made me question if I should keep using Svelte at all in the future. Svelte has always been polarizing but I found myself agreeing with most of its strong opinions. With SvelteKit I've found myself in the opposite position where I disagree with pretty much everything.

I really like Svelte and SvelteKit, I would like to use it more, but I still feel that RubyOnRails has a better ecosystem for common things like forms and validations, even better with simple_form.

I also miss some out of the box solutions like Devise (without using external services).

Please excuse the self promotion but I’m actually building something like that for SvelteKit!

http://sveltekitsaas.com/

Yeah. All these full stack frameworks don't really solve much on the backend.

Instead of SvelteKit, I use Svelte with Fastify which offers a lot more for the backend.

For folks who have used both, how do you feel Svelte + sveltekit compares to React + Next?

I honestly feel 10x more productive when using SvelteKit instead of Next, and really I have much more experience with React than I ever had with Svelte, it's just that simple and logical. The biggest problem however is ecosystem, you might have difficulties finding Svelte-specific libraries to do what you want and might need to create your own components (i.e. using generic JavaScript libraries), although that's not too hard it can become a bit of a burden to be maintaining it. Overall, I would really recommend people try out SvelteKit, but just pay attention to see if the libraries they may need are available before using it for a bigger project.

Svelte SaaS starter kit looks very interesting, I’ll be keeping an eye out

SvelteKit is awesome - I wished there were a nice Docusaurus alternative in it. I checked out KitDocs and Sveltepress but both seem like small personal projects that can at anytime stop being maintained.

I’m working on a Next.js based alternative to Docusaurus if you are ever interested in switching over to the dark side and want to build a Next app lol

In the past, I got tasked with an existing Next.js app to play nice with a Docusarus user guide they were building. I found that Docusaurus was very limiting in that environment, and I was forced to launch a separate Docusarus powered docs site under a different sub domain.

I’ve ported over the Docusaurus functionality into an open source Next.js project, complete with Markdown loading, Tailwind CSS, simple .env file configuration, and much more.

I fixed the Docusaurus problems that I mentioned above.

https://github.com/elegantframework/elegant-cli

For what it's worth there's a good library to load markdown with Svelte components mixed in. Here's how I'm loading it: https://github.com/jokull/blog/blob/master/src/lib/getPosts....

https://archive.ph/yYh4J

Why did you post this?

The post wasn't loading for me because my DNS was blocking it for it being newly-registered, so I decided to post the archive link in case someone else had the same issue.

Ah thanks! Was wondering if the site was down. Didn't know that DNS did that!

how does it compare with react?

Very different. Svelte has magic event bindings and compiles `.svelte` files. Their learning material is interactive and worth going through just to see some new ideas.

It certainly feels like that, but there’s actually a lot more magic happening under the hood with React.

You can open the compiled svelte output and follow through the entire code path for updates in a few minutes.

Reply on news.ycombinator.com