Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflections on Migrating My SaaS to SvelteKit

sveltekitsaas.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Reflections on Migrating My SaaS to SvelteKit

#11

Post by SarcevicAntonio »

pjmq wrote: 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…

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#12

Post by SarcevicAntonio »

jstummbillig wrote: post #4

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#13

Post by Pepe1vo »

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

Re: Reflections on Migrating My SaaS to SvelteKit

#14

Post by jFriedensreich »

Pepe1vo wrote: 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…

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#15

Post by [deleted] »

pjmq wrote: 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…

[deleted]

Re: Reflections on Migrating My SaaS to SvelteKit

#16

Post by kalpolintrol »

pjmq wrote: 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…

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#17

Post by kalpolintrol »

SarcevicAntonio wrote: post #11
pjmq wrote: 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…

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#18

Post by 0dayz »

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#19

Post by dmak »

pjmq wrote: post #10
jokull wrote: 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…

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.

Re: Reflections on Migrating My SaaS to SvelteKit

#20

Post by mattsahr »

0dayz wrote: post #18

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

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