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

231–240 of 296 posts

Re: SvelteKit 1.0

#231

Post by drschwabe »

SvelteKit is nice to rapidly develop websites (after some initial training/familiarization/minor frustrations stage), I only wish it was a library w/ perhaps a separate CLI utility and the framework optional; ie- if they exposed some core features as re-usable functions or one-off CLI commands to build a static site with its clientside window.location/cached routing technique that makes sites feel blazing fast for example.

This way you wouldn't have to drop in and adopt the entire framework just to get one or two features.

Re: SvelteKit 1.0

#232

Post by httgp »

hu3 wrote: post #27

This is how I move fast and break nothing. By having fullstack type-safety from database all the way to the frontend with auto-completion. My current stack: + SvelteKit (could be Next, Nuxt, Solid or any other TypeScript framework) + tRPC (typed calls between frontend and backend, https://trpc.io ) + trpc-sveltekit (glues SvelteKit and tRPC, https://github.com/icflorescu/trpc-sveltekit ) + Prisma (ORM, https://www.pr…

How well does tRPC work if the API consumer isn’t built with TypeScript?

Re: SvelteKit 1.0

#233

Post by omgsean »

dhucerbin wrote: post #226

Fantastic news! Although I loathe writing libraries [1] in Svelte, I love writing apps and kit is great extension to server side. I like similar to Remix push for Web APIs, like forms for mutations etc. I like nested layouts with data endpoints. I like that most of the internal state is visible as reactive store. [1] Creating complex type definitions for more generic components is hard and require knowledge about int…

>Creating complex type definitions for more generic components is hard and require knowledge about internals.

This is what turned me off of Svelte initially. Usually when I make websites I start by defining some primitive components like or . I could not figure out how to type my component so that it takes every single attr and event that a regular takes plus some extra attrs that I want to define (theme, size, etc.) This is trivial in React so I was surprised that it didn't really seem possible in Svelte.

Re: SvelteKit 1.0

#234

Post by cutler »

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

Blazor is a non-starter if you care about payload size and startup time. Fine for intranets but not much else.

Re: SvelteKit 1.0

#235

Post by brushfoot »

arcturus17 wrote: post #207
brushfoot wrote: post #179

Earlier quoted context omitted.

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 fendi…

> I've never built anything on .Net

The grass isn't greener. I've built in both - I have a .NET Core/Angular SaaS app that I created and sell, and I've been building greenfield in Next. I much prefer Next.

The duplication in .NET/Angular has never been worth it...not once. And having network calls for everything is unnecessarily painful.

I started the app in 2019, when RESTful SPAs were all the rage. I bought into the hype that you should have API endpoints for everything no matter what, because you'd soon have a mobile app and daemons and this and that.

Turns out, YAGNI. It would've been better to server-side render and only create API endpoints when necessary.

That's what I like about Next: Static generate where you can, server-side render per request where you can't, SPA where necessary - and the layers are as flat as can be. It's the best of all worlds.

That being said, I've worked in .NET for ~16 years now, and I like it more than JavaScript/TypeScript. But I'd still rather develop a web app in Next and put any background services elsewhere in .NET if needed.

Re: SvelteKit 1.0

#236

Post by cpfohl »

michaelsbradley wrote: post #133
hamdouni wrote: post #102

Earlier quoted context omitted.

Nodejs is only needed in the development phase.

That's true if you're developing a SPA or static site with SvelteKit. However, there are APIs that involve Node being run in production, i.e. the authors of SvelteKit envision it being used to build hybrid apps that involve front-end JS and Node.js server/s.

That is opt in! The adapter system in SK is great.

Re: SvelteKit 1.0

#237

Post by brushfoot »

kcartlidge wrote: post #209
brushfoot wrote: post #179

Earlier quoted context omitted.

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 bet…

> 1. That's often a good thing, not a flaw, in that it enforces a mapping boundary

That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity.

> 2. Mapping requirements of this type are much too trivial to base a tech stack choice on.

Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup.

> 3. If this model syncing was really an issue (it usually isn't) you could try Blazor.

Blazor is cool, but the bundle sizes are still too large right now, and it doesn't have the ecosystem of web components that JavaScript does. Sure, you can integrate, but you're just making life more complicated for yourself. It feels like too little, too late.

Re: SvelteKit 1.0

#238

Post by mythz »

5e92cb50239222b wrote: post #91
hu3 wrote: post #27

This is how I move fast and break nothing. By having fullstack type-safety from database all the way to the frontend with auto-completion. My current stack: + SvelteKit (could be Next, Nuxt, Solid or any other TypeScript framework) + tRPC (typed calls between frontend and backend, https://trpc.io ) + trpc-sveltekit (glues SvelteKit and tRPC, https://github.com/icflorescu/trpc-sveltekit ) + Prisma (ORM, https://www.pr…

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…

> 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 of long-term support

It's easy to beat Open API, it adds friction, generates ugly code and has a suboptimal UI. If you use https://servicestack.net you don't to rely on an intermediary external tool, you can generate clean TypeScript DTOs directly from strong C# typed models, that only needs to generate the clean DTOs for your typed APIs (i.e. without the ugly client proxy) as all generated DTOs can be used with the smart generic Service Client, which works the same way across 9 popular languages [2], maximizing reusability and reducing any porting efforts if needing to support Mobile Apps in future. It works even better in .NET languages where if you properly design your Service Layer [3] into a impl-free project you can avoid code-gen entirely and share the DTOs that define your typed Service Contract with .NET clients enabling an end-to-end Typed API without code-gen, which dramatically improves Dev UX in C# clients like Blazor [4] since you can add/modify APIs whilst your Service is running.

We also maintain a better integrated and UX Friendly API Explorer [5] that Open API's Swagger UI which generates richer, validation bound customizable Forms directly from your Typed DTOs, better discovery and API docs and a "Code" tab which gives API consumers step-by-step instructions for how to easily call your Typed APIs in their preferred programming language [6].

As for productivity I'd say it's hard to beat the productivity of AutoQuery [7] where you only need to define your API's typed POCO contract, which ServiceStack uses to implement fully queryable APIs, that you can access immediately from an instant build-in UI https://locode.dev or rapidly create custom Blazor pages with Auto Form and AutoQueryGrid components [8].

[1] https://docs.servicestack.net/typescript-add-servicestack-re...

[2] https://servicestack.net/service-reference

[3] https://docs.servicestack.net/service-complexity-and-dto-rol...

[4] https://servicestack.net/blazor

[5] https://docs.servicestack.net/api-explorer

[6] https://docs.servicestack.net/api-explorer#code-tab

[7] https://docs.servicestack.net/autoquery

[8] https://servicestack.net/blazor#auto-forms

Re: SvelteKit 1.0

#239

Post by Xevi »

thdrtnl wrote: post #210
Xevi wrote: post #203

Earlier quoted context omitted.

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.

Were they internal or external apps? Because latency was the problem last time I looked, and it won't be super noticeable if you have the servers that close to you.

Re: SvelteKit 1.0

#240

Post by brushfoot »

CharlieDigital wrote: post #206
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…

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

That's not what GP is talking about, though. I like the new .NET minimal APIs, but what GP is talking about is the frontend/backend _integration_ with a framework like Next.js.

Next isn't really like Angular in that you don't need an API layer (though you can have one if needed). It's more like ASP.NET Core MVC.

The difference is the frontend code is truly integrated with the backend. It all lives in the same project. It's just React components. You can render them statically on the server at build time, per request at runtime, or on the client. And you can mix and match. Next only ships the client the JavaScript it needs.

You don't need an API unless you want SPA parts of the app. Where you do want that, it's simple to implement, because you're already in JavaScript and all your other code plays nicely with it. It's a really nice way to organize and consolidate the different pieces of web dev IMO.

Post reply on HN