Hacker News new | ask | show | jobs
by himujjal 1106 days ago
The exact problem with SvelteKit, NextJS, NuxtJS etc is the plugin the OP has to create.

Somehow these meta-framework don't make much sense once you go past the basic DB -> REST -> SSR apis. Productivity decline is a guarantee. DX will suck your soul. Svelte is a far enjoyable library/framework than SvelteKit.

They did bring a lot of good things into the world of JavaScript, but I think this architecture will soon be obsolete for regular template (webpages) or simple SPAs (webapps).

That being said, one of the most promising contenders is InertiaJS though. I think something like InertiaJS will come in 2-3 years and make these meta-frameworks obsolete. Why? The DX.

3 comments

I agree.

It's disheartening to see thousands of man-hours poured into these projects that solve a lot regarding rendering in the server and client but are nowhere close to popular backend frameworks like Rails, Laravel, and Django.

I imagine the argument is that, because these full stack frameworks are platform agnostic (Node, Deno, CF Workers, etc) they couldn't possibly cover all the backend needs for all those platforms. And of course that makes sense...

But IMO the decision to become platform agnostic is hurting more than it helps.

In part because I think people have overestimated the interest in deploying backend projects to say CF Workers. Sure you get super easy distributed compute but the real problem is distributed data which no one has solved properly yet.

And the other point is that IMHO it doesn't make sense to sacrifice the value and usefulness of a project just to offer a single feature (being platform agnostic) which is not that valuable to begin with.

I agree with you and I think this is by far the biggest risk to SvelteKit as a project. The biggest problem is that it’s very prescriptive for some things and then has no opinion (or even guidance) on other areas.

Like forms, the docs say use Form Actions, but it’s fundamentally at odds with being able to build a standalone component that can submit data to the server and be used anywhere. The workarounds are silly.

And then there’s how they treat navigation. Always use anchors! For progressive enhancement and preloading pages. Except you end up having to use their ‘goto’ method to do routing in a lot of circumstances. It’s very muddled and full of mixed messages.

> And then there’s how they treat navigation

Yeah, and that awful file-based routing (IMO).

I feel that the strongly opinionated approach worked wonders for Svelte since the (let's call it) reactive components paradigms was well understood by then. But translating that approach to the backend has not been very successful because flexibility is paramount.

Yeah and the attitude towards suggestions is pretty poor. I’m in too deep to refactor right now, but Inertia looks like a good option eventually. Keeping the benefits of svelte while moving to a better backend. I’m glad it was posted.
What I did was integrating Svelte with Fastify.

Initially that required lots of custom stuff (before SvelteKit and Vite had SSR) but now it's fairly easy to integrate with Vite. I have this repo I used to experiment a bit with that.

https://github.com/PierBover/fastify-vite-svelte-template

I think it's import to keep your backend/api isolated from these FE frameworks. Backends live forever, these frameworks not so much.
Yeah. This is exactly why I think the meta-frameworks wont really matter in a decade’s time or will disappear.

InertiaJS is an idea/implementation I like and its way of mitigating this issue of meta-framework dependence.

I agree with you, but what that actually looks like can vary.

Personally, I found maintaining a second backend only codebase and hitting it from the SvelteKit backend to be really cumbersome.

You can write controllers and even an API and keep it in its own folder system.

I'm currently doing this with Next.js with a "custom server". Allows for sharing TypeScript interfaces/types and the express instance quite easily. It's just one big vscode project. But custom servers are frowned upon and will probably disappear in future versions which will make things slightly more complicated.