What would be the best route to upgrade a medium sized project from say `1.0.0-next.263`?
There's 327 intermediate versions up to this one and a considerable amount of breaking changes.
SvelteKit 1.0
181–190 of 296 posts
Re: SvelteKit 1.0
#182Congrats to the launch. This looks so good :)
Re: SvelteKit 1.0
#183This 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…
> Database schema is generated from models described in C# (or reverse-engineered from an existing schema). You don't have to compromise your schema to satisfy the ORM (another claim I often read on HN), as it's very adaptable to your needs.
Generating the schema from the models is easy mode, the ORM naturally won't generate anything it doesn't understand. The claim is that the ORM can't handle advanced schema features that it wouldn't generate. (Although in my experience most people claiming that just never bothered to learn the ORM).
Re: SvelteKit 1.0
#184This 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…
Postgresql > PostgREST > Elm
Re: SvelteKit 1.0
#185Earlier quoted context omitted.
How are you liking Prisma compared to a pure SQL approach?
I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else can…
> I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else can also work on the front-end even though it's not their daily thing (and vice versa). More than that though it lets us do things like code reviews, troubleshoot solutions and generally work together really well, even though we're working on very different projects. It also lets us build libraries that can be used for everything.
We do this the other way around, by using Scala.js so we can use Scala on the frontend as well as the backend. It's very nice.
Re: SvelteKit 1.0
#186Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks? From what I know it has more fine grained reactivity than for example React or Vue and should therefore just run more efficient? Or has the approach of Svelte also drawbacks that I am not aware of?
> Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks?
I personally would say no. I like Svelte's dev experience but I don't like the output code and while it has smaller invalidation subsections than a full component there's not a 1 to 1 mapping between a piece of data changed and the exact piece of DOM getting updated.
> Or has the approach of Svelte also drawbacks that I am not aware of?
Svelte is superb for producing NYT infographics and other relatively lightweight experiences. I work on interface builders and when you're scaling up the number of components on a page and the complexity then having the reactivity code repeated in the components instead of shared in a library becomes a drawback. What pushed me off of of Svelte was a ~500 loc component that had ~40 reactions and resulted in a 4.1k LoC js file output. I looked through the output and didn't see any particularly egregious mis-compilations, just that the Svelte's approach resulted in verbose outputs. I don't think most people will have components this complex so I don't think Svelte is a bad choice and I do like the DX but that caused me to move on.
Of the current options, I recommend Solid. It has fine grained reactivity all the way down, better perf, similar bundle size, and the community is generally performance obsessed. They're currently experimenting with islands/partial hydration/mixed server+client rendering and preliminary results are halving the delivered JS. As an example, their movies demo [1] is ~15k.
Re: SvelteKit 1.0
#187This 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…
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...
Re: SvelteKit 1.0
#188Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks? From what I know it has more fine grained reactivity than for example React or Vue and should therefore just run more efficient? Or has the approach of Svelte also drawbacks that I am not aware of?
> Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks? I personally would say no. I like Svelte's dev experience but I don't like the output code and while it has smaller invalidation subsections than a full component there's not a 1 to 1 mapping between a piece of data changed and the exact piece of DOM getting updated. > Or has the approach of Svelte also drawbacks tha…
budibase is a notable interface builder in Svelte if anyone wants to compare https://github.com/Budibase/budibase
and ofc huggingface gradio counts too https://www.svelteradio.com/episodes/gradio-with-pngwn
Re: SvelteKit 1.0
#189While I like Svelte, I fear it looses some of the flexible API-building enabled by React.
Specifically: since it uses a templating system, you can't pass around interface definitions easily:
- https://github.com/sveltejs/svelte/issues/3480 (no dynamic slots)
- https://github.com/sveltejs/svelte/issues/5381 (can't wrap children)
You can always find workarounds for these cases, often using ``, but React's Javascript/Typescript-centric design avoids such issues before they even occur. For instance, I can trivially define a tabbed interface by mixing strings, JSX, and components, without imposing any DOM-structure. The component that reads this definition can use it to build a tabbed-view on mobile, and a master-detail-view on desktop. It could even build a table of contents.
In the definition, I can still work mostly with strings, but fall back to JSX in the rare case where I do need some advanced formatting:
const tabs = [
{ name: "Tab 1", icon: , content: MainTab },
{ name: Tab with bold text, icon: , content: SecondTab },
]
Re: SvelteKit 1.0
#190Sveltekit has been an absolute DREAM to learn and use with my app! Been tracking their 1.0 progress closely and it's been incredible. Sveltekit + TailwindCSS + FastAPI has made it super easy to whip up functionality and have a fine-tuned approach as well. As someone else said, the "I CAN'T BELIEVE IT WAS THAT EASY" is an ongoing sentiment whenever I use it. Looking forward to seeing it grow and gain more popularity
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.