Live data from Hacker News

Reflections on Migrating My SaaS to SvelteKit

sveltekitsaas.com

31–40 of 46 posts

Re: Reflections on Migrating My SaaS to SvelteKit

#31
post #10
post #2

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 deb…

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…

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#32
post #13

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…

> 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.

Re: Reflections on Migrating My SaaS to SvelteKit

#33
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).

Re: Reflections on Migrating My SaaS to SvelteKit

#34

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/

Re: Reflections on Migrating My SaaS to SvelteKit

#35
post #29

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#37
post #9

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 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 especia…

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#38
post #26
post #22

Earlier quoted context omitted.

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

Re: Reflections on Migrating My SaaS to SvelteKit

#39

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).

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#40
post #9

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 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 especia…

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.

Post reply on HN