151–160 of 296 posts
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.
How so people feel about client side navigation? Browsing svelte.dev it appears back/forward navigation now requires a request each time as browser cache is no longer usable. Page refresh also seems to reset scroll position but that might be unrelated.
Navigating back/forward will only make a new request if that page needs to fetch data in its +page.js component https://kit.svelte.dev/docs/load
It will save you a ton of time by making it really easy to add integrations to your projects (like Tailwind, Bootstrap, Supabase, Jest, etc)
Sveltekit 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
I tried htmx and so far i really like it and the + is i just have "one" backend.
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.
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…
Anyone know a good way to solve Prisma memory usage? We use a database per customer and each one adds 50-80mb of RAM. Our backend currently consumes 2-3GiB of RAM to host less than 100 customers... App server has GC pauses of 50-80ms as a result of the memory usage.
I recently jumped over that "trying to minimize resources" hurdle myself because it's just not economically correct for me to spend even an hour of my time when I can host a few months worth of servers for that money
There is a plethora of javascript frameworks: React, Vue, Svelte, Remix, etc. If I know nothing about front-end development, and would like to learn one that is: - Intuitive - Suitable for small projects as well as large projects. - That is here to stay, i.e. either adopted by many companies, or its adoption curve is going up. Which one should I pick? Would Svelte be a good choice?
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…
Microsoft has invested massively in modernizing .NET and C#.
It is also widely praised by devs - .NET is ranked 4th most loved framework in the SO 2022 dev survey.
You have built-in scaffolding to get a React + .NET app right from the CLI, with hot-reload and all the facilities you'd expect.
Hardly old school at all. Personally, if I had to build a website with a thin API layer I'd reach for NextJS (or equivalent) alone, but anything beyond that I'd go for .NET Core any time of day.