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.
Reflections on Migrating My SaaS to SvelteKit
41–46 of 46 posts
Re: Reflections on Migrating My SaaS to SvelteKit
#42Earlier quoted context omitted.
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
#43Yep. 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.
Re: Reflections on Migrating My SaaS to SvelteKit
#44The 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…
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.
Re: Reflections on Migrating My SaaS to SvelteKit
#45Earlier 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.
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.
Not ideal but not the biggest deal. And definitely not enough to trade Svelte in for something else.
Re: Reflections on Migrating My SaaS to SvelteKit
#46The 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.