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