top | item 36149307

(no title)

himujjal | 2 years 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.

discuss

order

pier25|2 years ago

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.

dimmke|2 years ago

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.

pier25|2 years ago

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

Ins43b|2 years ago

I think it's import to keep your backend/api isolated from these FE frameworks. Backends live forever, these frameworks not so much.

himujjal|2 years ago

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.

dimmke|2 years ago

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.