171–180 of 296 posts
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…
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…
That at least keeps the blast radius of type-related bugs very limited, and makes it easier to figure out where the problem is.
Earlier quoted context omitted.
If it's for your career: React + (Next or Remix). Maybe Angular or Vue if the specific company you want uses it If it's for yourself: Svelte. Amazing community, very likely to be here in 5 years, but I don't think it's been proven to work at large scales yet. If you want to twist everything upside down and see the full potential of what front-end dev work could be: Qwik or Elm (imho)
Svelte will be also the career choice in couple of years, like Angular was the career choice when React launched (although they have only 3 years between them).
By pretty much every metric,[^0] svelte is a tiny community still. A darling of the web dev community for sure, but has not yet gained the confidence of commercial products. Perhaps this has actually been good for Svelte and its development. It definitely seems like it's heading towards much wider adoption so I guess we'll see it tested soon enough
[^0]: https://gist.github.com/tkrotoff/b1caa4c3a185629299ec234d231...
Earlier quoted context omitted.
I'd love to browse a sample codebase. Do you know of any non-trivial open source projects using this stack?
https://trpc.io/docs/example-apps
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…
Great news and looking forward to how this goes. I still find it incredible that the frontend javascript ecosystem hasn't found a reliable and productive contender yet, a framework you could be sure would be still relevant without too much changes in 5+ years, something like what Ruby on Rails is for full-stack. Some would say that React/NextJS has this role but I have to disagree. When using React/NextJS you still h…
You shouldn’t need react-router or other routing-related third-party libraries because Next’s router (and its file-based navigation system) should be enough(?). I’d also say that React itself has powerful-enough state management options (useState hook plus React context, if needed).
The only annoyance I ran into was getting proper i18n working and integrated with Next (with i18next). There were some issues with Next’s newer releases and a redesigned i18n setup that broke a lot of things for me and I regretted the dependence of multiple libraries and frameworks needing to work together. (Storybook is another library that kept breaking.)
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…
Might I recommend https://jawj.github.io/zapatos/ to remove the last 3 lines of your stack.
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…
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 time.
As much as I like ASP.NET, Next has leapfrogged it for web apps.
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…
Curious how you handle `request.formData()` in Form Actions and ensuring type safety there.
[0] - https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...