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

271–280 of 296 posts

Re: SvelteKit 1.0

#271

Post by rk06 »

Tade0 wrote: post #117

As someone who wrote his first lines of JS in 2001, working with Svelte feels a lot like the good old days of JS when front-end was simple. To me the main selling point is that the stack trace is actually useful for a change - you especially can find in there the line which caused the re-render and subsequent error. JS frameworks/libraries by and large lost that feature a decade ago.

Chrome has improved it a lot, now the stack traces can point to line of user code which caused this issue.

This was initiated by Angular team, but I have seen it work for vue as well

Re: SvelteKit 1.0

#272

Post by kaba0 »

oh-4-fucks-sake wrote: post #223
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…

I agree with the sentiment--and with most of your comment--except the assertion that "I don't think it's possible to beat this stack". I have something similar: Kotlin on the server-side with my SQL DSL generated by jOOQ and Flyway running my schema migrations. I don't have any experience with LINQ--but it looks to be of a similar idea to jOOQ such that you get an autogenerated, injection-safe, type-safe, compile-tim…

I think parent meant “stack” for every similarly high level, statically typed language. I can vouch for Spring (Data) with JPA. The criteria api is also very great.

Re: SvelteKit 1.0

#273

Post by miohtama »

Labo333 wrote: post #190
miohtama wrote: post #140

Earlier quoted context omitted.

SvelteKit SSR is a very good pair to Python backends, like FastAPI.

Can you expand? I don't get how you can use SSR with another language than Node. I always thought one has to use the static adapter.

Requests are routed reverse proxy (Caddy) -> Vite (SSR) -> Python (Pyramid).

SSR calls your backend APIs and renders templates.

Example from SvelteKit page.ts here:

https://github.com/tradingstrategy-ai/frontend/blob/master/s...

Some remarks

- page.ts is routed by Vite for every HTTP request for SSR and then it will fetch() data over backend API

- If rendered in the client, fetch() hits directly the backend API

- Both cases the template is rendered using the same logic (Svelte HTML templating, CSS, JS)

- You are going to need a template language any cases, like Django's one. Alternative way to think this is that SvelteKit is just a super powerful template engine.

Re: SvelteKit 1.0

#274

Post by dawei67 »

qprofyeh wrote: post #144

While most of the comments here seem positive… A custom template language is like another programming language to learn (to make mistakes in). I prefer JSX/TSX which is closer to reusing HTML.

the template "language" is learnable in 10mn and fit in a small cheat sheet. I personally think JSX as a template language make HTML horrifying to read

Re: SvelteKit 1.0

#275

Post by acqbu »

kenkunz wrote: post #34

Congratulations to the whole SvelteKit team! I've been using Svelte / SvelteKit for 1.5 years now – it is without comparison the most enjoyable and productive web f̵r̵a̵m̵e̵w̵o̵r̵k̵ language I've ever used. I'm lucky enough to work with Svelte / SvelteKit full-time. I'm gratified that the site I help build and maintain is included in the SvelteKit showcase: https://kit.svelte.dev Trading Strategy: https://tradingstra…

That's amazing. Out of curiosity, how does one get to work for companies that use Svelte?

I'm based in the UK and the only companies I've heard of using Svelte are Decathlon, Apple and Spotify.

Re: SvelteKit 1.0

#276

Post by dskwrite »

acqbu wrote: post #275
kenkunz wrote: post #34

Congratulations to the whole SvelteKit team! I've been using Svelte / SvelteKit for 1.5 years now – it is without comparison the most enjoyable and productive web f̵r̵a̵m̵e̵w̵o̵r̵k̵ language I've ever used. I'm lucky enough to work with Svelte / SvelteKit full-time. I'm gratified that the site I help build and maintain is included in the SvelteKit showcase: https://kit.svelte.dev Trading Strategy: https://tradingstra…

That's amazing. Out of curiosity, how does one get to work for companies that use Svelte? I'm based in the UK and the only companies I've heard of using Svelte are Decathlon, Apple and Spotify.

A couple of spots I'm aware of that are Svelte specific .. https://sveltejobs.com

Jobs channel on the Svelte Discord https://discord.com/channels/457912077277855764/640884695890...

Re: SvelteKit 1.0

#277

Post by tmd83 »

kursus wrote: post #261
tmd83 wrote: post #253

Is there any option if I want to do traditional (non JS) SSR but also want to share an API endpoint for both browser and other use cases? Seems like a JS frontend framework or a JS SSR is the only option for such use case. If SSR and API force a JS backend that leaves a lot of the benefit that other languages bring to the table and effectively limiting you to 1 (JS) or 2 (TS including) languages. Seems like a sad sta…

You can have any kind of backend with Sveltekit, and call it from client or server (or both). You can even completely bypass sveltekit per request.

You mean an API backend in any language and Sveltekit for client side JS based UI in Sveltekit?

Re: SvelteKit 1.0

#278

Post by lakomen »

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 generate backend and frontend types in 2 seconds with Go, after I define the model structs.

I laugh at your slow running, resource wasting .net

Re: SvelteKit 1.0

#279

Post by Kuinox »

dmitriid wrote: post #257
Kuinox wrote: post #221

Earlier quoted context omitted.

Any browser is fast with the last CPU node. Safari is becoming compatibility nightmare.

The tutorial used Web Containers which... aren't a standard and are very specifically Chrome-only. And it undoubtedly relies on a bunch of Chrome-only non-standards, too.

> Web Containers which... aren't a standard

The implementation doesn't use chrome specific API AFAIK, and it works on firefox.

> are very specifically Chrome-only. And it undoubtedly relies on a bunch of Chrome-only non-standards, too.

It does support all majors browers, except safari.

The reason why it doesn't work on Safari is even listed:

> Safari recently shipped support for SharedArrayBuffer and cross-origin isolation in a somewhat buggy state. In addition to this, it is still lacking a few other features which prevents us from shipping a working environment such as:

> Atomics.waitAsync > Lookbehind in regular expressions

> Note that none of above can be pollyfilled.

These are not "Chrome-only non-standards" and are parts of the officials JS/HTTP specs

Re: SvelteKit 1.0

#280

Post by dmitriid »

Kuinox wrote: post #279
dmitriid wrote: post #257

Earlier quoted context omitted.

The tutorial used Web Containers which... aren't a standard and are very specifically Chrome-only. And it undoubtedly relies on a bunch of Chrome-only non-standards, too.

> Web Containers which... aren't a standard The implementation doesn't use chrome specific API AFAIK, and it works on firefox. > are very specifically Chrome-only. And it undoubtedly relies on a bunch of Chrome-only non-standards, too. It does support all majors browers, except safari. The reason why it doesn't work on Safari is even listed: > Safari recently shipped support for SharedArrayBuffer and cross-origin iso…

I stand corrected.

The reason for my comment is that far too often these complaints are about some things that Chrome ships at neck-breaking speed.

Post reply on HN