Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SvelteKit 1.0

svelte.dev

Post reply on HN
Print view View original

201–210 of 296 posts

Re: SvelteKit 1.0

#201

Post by jmull »

shepherdjerred wrote: post #129
jmull wrote: post #68

Earlier quoted context omitted.

Personally, I'd remove tRPC on down (and choose a database). It's nice there's type-safety between layers, but that's a bunch of layers that you don't even need. (A layer that doesn't exist takes is 100% type-safe and takes 0 hours to develop and maintain).

> A layer that doesn't exist takes is 100% type-safe How are you ensuring your database accesses are type-safe in this case?

That's fair... I do typically have a layer that sits at the level of an ORM, whose purpose is to reduce boilerplate and handle/verify types.

So I can't really claim I have nothing at the ORM level... However...

In my experience, when you pull in an off-the-shelf ORM and an off-the-shelf RPC framework you end up building app-level wrappers anyway to deal with the complexity and impedance mismatch between what you want your app to use for data access code and what layer provides.

So I think you might as well put your app-level database wrapper as directly around the database as you can manage (that probably means using the common, unopinionated client for your db... e.g., node-postgres for server-side javascript and postgres, or whatever the equivalent is for your backend/database).

Re: SvelteKit 1.0

#202

Post by intelekshual »

mccorrinall wrote: post #196
JoeyJoJoJr wrote: post #169

Earlier quoted context omitted.

You should also mention Zod, which acts as the type safe glue between the different boundaries. I have been using Google Sheets as a kind of hacky database. By defining the schemas in Zod I am able to automatically validate my sheets data and coerce the string cell values into their proper types. Zod schemas can be used all over the stack, imported for form validation, and avoid heaps of duplication and tests.

While Zod is hyped by Next.ja developers (I think mostly because Theo Brown has such a huge reach), I think Ajv is better, because it lets you generate OpenAPI documentation and it fully json schema compliant. I really like nextjs for its opinions on the frontend part, but it is lacking these strong, but great opinions on the backend. Wish love to see some design decisions from fastify adopted here. Matteo did really…

Zod has plugins that let you generate OpenAPI specs (and TS types, and JSON Schema, etc.) from your Zod schemas, so if that's the only reason you think Ajv is better, then it might be time to take another look at Zod? It really is great, especially if you buy into the "parse, don't validate" principle that it's built around.

Re: SvelteKit 1.0

#203

Post by Xevi »

thdrtnl wrote: post #187
5e92cb50239222b wrote: post #91

Earlier quoted context omitted.

Same, but with ASP.NET (which produces an OpenAPI specification) + Entity Framework on the server, React + TypeScript on the client (which consume that specification through openapi-generator). https://github.com/OpenAPITools/openapi-generator I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease…

If your are going to mention .NET in this context, why not mention Blazor? With Blazor you just write both the reactive frontend and backend in C#. No need to write Javascript. Super productive, type safe all the way. Today it has even support for hot reloading. Save your C# and see the changes in your browser. https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

Last time I looked at Blazor it only had two options, which were both equally horrible for public websites.

You either had to ship a big and bloated WASM file, which was at least 10x the size of competing JS frameworks, and in some cases 100X the size. Or you had to render all dynamic parts of your website on the server, which made latency a huge problem, since your website feels sluggish between each interaction.

Re: SvelteKit 1.0

#204

Post by FridgeSeal »

thdrtnl wrote: post #187
5e92cb50239222b wrote: post #91

Earlier quoted context omitted.

Same, but with ASP.NET (which produces an OpenAPI specification) + Entity Framework on the server, React + TypeScript on the client (which consume that specification through openapi-generator). https://github.com/OpenAPITools/openapi-generator I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease…

If your are going to mention .NET in this context, why not mention Blazor? With Blazor you just write both the reactive frontend and backend in C#. No need to write Javascript. Super productive, type safe all the way. Today it has even support for hot reloading. Save your C# and see the changes in your browser. https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

Because last time I looked, the Blazor binaries were huge, and had performance issues?

It's also irrevocably attached to that specific dotnet framework? Want to evolve parts of your stack? Too bad.

Re: SvelteKit 1.0

#205

Post by [deleted] »

pevey wrote: post #124
5e92cb50239222b wrote: post #91

Earlier quoted context omitted.

Same, but with ASP.NET (which produces an OpenAPI specification) + Entity Framework on the server, React + TypeScript on the client (which consume that specification through openapi-generator). https://github.com/OpenAPITools/openapi-generator I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease…

This is very backend-centric. It can't compare to a framework like SvelteKit or NEXT or NUXT, where the primary benefit is also shipping your tightly-integrated frontend code to the browser. .NET apps are old school, full refresh apps unless you are also using a separate frontend framework like React or Vue standalone. And that adds a lot of time and overheard. Everything you described in terms of easy migrations and…

[deleted]

Re: SvelteKit 1.0

#206

Post by CharlieDigital »

pevey wrote: post #124
5e92cb50239222b wrote: post #91

Earlier quoted context omitted.

Same, but with ASP.NET (which produces an OpenAPI specification) + Entity Framework on the server, React + TypeScript on the client (which consume that specification through openapi-generator). https://github.com/OpenAPITools/openapi-generator I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease…

This is very backend-centric. It can't compare to a framework like SvelteKit or NEXT or NUXT, where the primary benefit is also shipping your tightly-integrated frontend code to the browser. .NET apps are old school, full refresh apps unless you are also using a separate frontend framework like React or Vue standalone. And that adds a lot of time and overheard. Everything you described in terms of easy migrations and…

If you have .NET 6/7 installed, give this a try:

    dotnet new webapi -minimal
    dotnet run
I know there's been a lot of discussion about whether .NET/C# are faster than X or Y or Z based on TechEmpower benchmarks, but this will give you a backend that looks more or less like Express with an OpenAPI schema built-in (generate TS bindings for frontend) and a runtime that is going to be higher thoughput than Express or Node.

    dotnet watch
And you get hot reload.

Re: SvelteKit 1.0

#207

Post by arcturus17 »

brushfoot wrote: post #179
pevey wrote: post #124

Earlier quoted context omitted.

This is very backend-centric. It can't compare to a framework like SvelteKit or NEXT or NUXT, where the primary benefit is also shipping your tightly-integrated frontend code to the browser. .NET apps are old school, full refresh apps unless you are also using a separate frontend framework like React or Vue standalone. And that adds a lot of time and overheard. Everything you described in terms of easy migrations and…

Exactly. With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models. With Next, there's true code reuse between client and server. Next is smart about shipping your code where it needs to run, server, client, both. You can even mix and match from page to page: Server-side render one page per request; statically generate another at build ti…

> As much as I like ASP.NET, Next has leapfrogged it for web apps.

Look, I like NextJS as much as the next guy - I'd say it's my main working technology right now. And I've never built anything on .Net - I know its characteristics from watching tutorials and reading docs.

My take however is that "web apps" is a very broad world. NextJS gives you a thin API layer. There is no model layer to speak of. You're left fending for yourself in the wild, wild world of JavaScript.

.Net Core, on the other hand, offers a batteries-included, heavy-lifting, opinionated framework, with an immense toolbox and many conventions to guide you. There has to be a reason why people speak such wonders of it. If I had to build something enterprise-y with more than handful of devs it would probably be my choice.

Re: SvelteKit 1.0

#208

Post by doodlesdev »

yawnxyz wrote: post #161

For anyone who might have missed the announcement hidden in the launch video, there's Svelte Auth now from the Vercel NextAuth team: https://vercel.com/blog/announcing-sveltekit-auth

Wow that's huge. Might need to find something to try out SvelteKit now. Loved Svelte already and I was only waiting for a 1.0 of SvelteKit.

Re: SvelteKit 1.0

#209

Post by kcartlidge »

brushfoot wrote: post #179
pevey wrote: post #124

Earlier quoted context omitted.

This is very backend-centric. It can't compare to a framework like SvelteKit or NEXT or NUXT, where the primary benefit is also shipping your tightly-integrated frontend code to the browser. .NET apps are old school, full refresh apps unless you are also using a separate frontend framework like React or Vue standalone. And that adds a lot of time and overheard. Everything you described in terms of easy migrations and…

Exactly. With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models. With Next, there's true code reuse between client and server. Next is smart about shipping your code where it needs to run, server, client, both. You can even mix and match from page to page: Server-side render one page per request; statically generate another at build ti…

> With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models.

The separation of models is indeed inevitable when there is JS on the client and not-JS on the server. That's a 'problem' common to all non-JS back-ends.

However there are three points I'd make.

1. That's often a good thing, not a flaw, in that it enforces a mapping boundary between what the server and the client know and therefore strongly discourages leakage of data.

2. Mapping requirements of this type are much too trivial to base a tech stack choice on. It's barely worth considering given that mappings only need doing once and updating once per change. They are also very good protection against accidentally exposing new stuff precisely because changes in models don't automatically impact the client.

3. If this model syncing was really an issue (it usually isn't) you could try Blazor. By doing C# on the client as well as the server you get to share the same code/models. As per point 2 I don't think that's a good enough reason to switch tech stacks, but Blazor also has its place.

Re: SvelteKit 1.0

#210

Post by thdrtnl »

Xevi wrote: post #203
thdrtnl wrote: post #187

Earlier quoted context omitted.

If your are going to mention .NET in this context, why not mention Blazor? With Blazor you just write both the reactive frontend and backend in C#. No need to write Javascript. Super productive, type safe all the way. Today it has even support for hot reloading. Save your C# and see the changes in your browser. https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

Last time I looked at Blazor it only had two options, which were both equally horrible for public websites. You either had to ship a big and bloated WASM file, which was at least 10x the size of competing JS frameworks, and in some cases 100X the size. Or you had to render all dynamic parts of your website on the server, which made latency a huge problem, since your website feels sluggish between each interaction.

I don't know when it was the last time you took a look at Blazor, but Blazer server is extremely fast. I built some big corporate apps with it and never had any latency problems.
Post reply on HN