[pjmq]

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.

[SarcevicAntonio]

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.

[kalpolintrol]

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

[scosman]

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.

[roblh]

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.

[pier25]

Exactly

[yawnxyz]

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.

[dimmke]

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.

[kalpolintrol]

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.

[Sammi]

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.

[finder83]

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

[pier25]

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.