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)
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).
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, at least without going to very niche technologies where you'll have other problems.
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.
Migrations are generated automatically — change your models, ask it to generate migration code in C# + a SQL migration script, review the generated SQL, and apply.
The vast majority of database queries (pretty much everything besides reports) is written in type-safe LINQ, which makes it easy to refactor code, and also construct & combine queries at runtime. Unlike that specification abomination JPA expects you to use, LINQ queries look something like this:
If you change your schema and forget to update one of the queries accordingly (although using an IDE makes this pretty much impossible), your code won't even compile.
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-time-checked SQL DSL.
If you like LINQ, you'd probably really like jOOQ. It's uber-powerful and the only queries that I've not been able to completely write in jOOQ are geo-spatial queries--and even for them, I can use string SQL for just the one where-clause predicate where I need to go off-the-rails--the rest of the query still being standard jOOQ. The thing I like most about it, is that the queries that I write in the DSL are sooo close-to-the-metal of pure SQL--I'm not even context-switching between SQL and jOOQ really. Check it out!
Also have to sing praise for Kotlin, flyway, and some type-safe db framework.
I’ve recently been migrating projects from jOOQ to SQLDelight. While not as feature complete, being able to write queries in sql and then generate type safe code has been amazing. My biggest issue with jOOQ has been joins where you lose some null safety and general issues with the generated POJO (which admittedly has improved over time). With SQLDelight, it has felt like the database just fades away when writing Kotlin.
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.
> 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).
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 querying is exactly what Prisma gives you in the stack the OP described.
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.
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.
> 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 fending for yourself in the wild, wild world of JavaScript.
.Net Core, on the other hand, offers a batteries-included, heavy-lifting, opinionated framework, with an immense toolbox and many conventions to guide you. There has to be a reason why people speak such wonders of it. If I had to build something enterprise-y with more than handful of devs it would probably be my choice.
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.
> But I'd still rather develop a web app in Next and put any background services elsewhere in .NET if needed.
Thanks for sharing your perspective.
I think we're essentially saying the same thing. I would start pretty much 99% of my projects in NextJS. But if I needed to reach for something doing complex logic and scaling to a larger team, I could always add a .Net service to that later.
If anything the model layer in Next.js is superior because you can use the same model layer to build the page SSR, and then Next.js will gracefully transfer the entire model layer over to the client where your app can continue to work against it.
That sounds nice for the main user interaction, but what about when you need more heavy lifting of async tasks and side effects?
Like I get a shared model being accessed "directly" for the things that the UI displays and manipulates. But once you click an Order button you have transactions to process, ledgers to update, notifications to dispatch.
That kind of code doesn't float between client and server, it needs to happen once the order has been received regardless of the client state.
You can offload that to other services, lambdas, etc. but that's the sort of thing that you can just do all-inclusive in a standalone backend be it Node, .NET, Go, etc.
> 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 between what the server and the client know and therefore strongly discourages leakage of data.
2. Mapping requirements of this type are much too trivial to base a tech stack choice on. It's barely worth considering given that mappings only need doing once and updating once per change. They are also very good protection against accidentally exposing new stuff precisely because changes in models don't automatically impact the client.
3. If this model syncing was really an issue (it usually isn't) you could try Blazor. By doing C# on the client as well as the server you get to share the same code/models. As per point 2 I don't think that's a good enough reason to switch tech stacks, but Blazor also has its place.
> 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.
> That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity.
Mandatory busywork implies stuff with no real purpose. I specifically pointed out the purpose. You may not agree with the cost/benefit involved in doing it, but that's a preference and doesn't automatically make someone else's way of working busywork. And personally I find it increases productivity by eliminating a whole range of security concerns.
> Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup.
This largely depends upon if you accept that the work itself is of benefit. If you believe it's just busywork, then whilst my own opinion differs, your conclusion is reasonable for your situation.
> 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.
You're right on the sizes and the ecosystem (though that is not Blazor-specific and is something no non-JS client-side tech will ever be able to compete with).
I do ASP.NET and Blazor (alongside Node, Go, Python, Rails etc) and TBH whilst personally I see great value in Blazor it feels like that's mostly for back-office or enterprise applications where you get the incredible productivity (that much is true) and don't need to worry about the sizes or, depending on how you implement it as this is optional, the need for a persistent web-socket connection.
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.
* The payload of WASM makes it a difficult choice if serving mobile or regions with poor internet and you want a good first impression.
* Server side needing a constant socket for everything presents it's own limitations.
* It has hot reloading, but it pales in comparison to the JS experience at best and in my own experience has a lot of edge cases leading to full rebuilds.
* C# tooling is fantastic; Razor however I've found to be slow and well behind the experience of popular JS libraries.
* When you do need JS interop (e.g. browser API's) the experience is, IMO, awful.
I feel Blazor's niche is internal, simple LOB apps and I can understand the appeal if you don't already know JS or have some serious regulatory requirements around vendors and need to avoid NPM.
Personally, I find the DX and quality of the end product in svelte kit trump the code sharing of Blazor.
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.
For local development do you run two servers, next and asp and then for dynamic api calls by the client do you proxy the request through next or go directly to the asp server by its port number?
Similarly in production do you use a reverse proxy for the asp server so that requests to like /api go to the asp server?
> 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].
Look, mate, I do unironically appreciate a good enterforaprize sales pitch, but this is a nerd space so corporate marketing wank is in fact actively counterproductive for the purpose of evangelising what's actually pretty neat tech.
To everybody else reading this - mythz' tone deaf bullshit wasn't my favourite way to be reminded I have a gag reflex but the URLs are well worth a look.
Personally, I'd remove tRPC on down (and choose a database).
It's nice there's type-safety between layers, but that's a bunch of layers that you don't even need. (A layer that doesn't exist takes is 100% type-safe and takes 0 hours to develop and maintain).
That's fair... I do typically have a layer that sits at the level of an ORM, whose purpose is to reduce boilerplate and handle/verify types.
So I can't really claim I have nothing at the ORM level... However...
In my experience, when you pull in an off-the-shelf ORM and an off-the-shelf RPC framework you end up building app-level wrappers anyway to deal with the complexity and impedance mismatch between what you want your app to use for data access code and what layer provides.
So I think you might as well put your app-level database wrapper as directly around the database as you can manage (that probably means using the common, unopinionated client for your db... e.g., node-postgres for server-side javascript and postgres, or whatever the equivalent is for your backend/database).
You should also mention Zod, which acts as the type safe glue between the different boundaries.
I have been using Google Sheets as a kind of hacky database. By defining the schemas in Zod I am able to automatically validate my sheets data and coerce the string cell values into their proper types.
Zod schemas can be used all over the stack, imported for form validation, and avoid heaps of duplication and tests.
While Zod is hyped by Next.ja developers (I think mostly because Theo Brown has such a huge reach), I think Ajv is better, because it lets you generate OpenAPI documentation and it fully json schema compliant.
I really like nextjs for its opinions on the frontend part, but it is lacking these strong, but great opinions on the backend. Wish love to see some design decisions from fastify adopted here. Matteo did really do some great stuff.
Zod has plugins that let you generate OpenAPI specs (and TS types, and JSON Schema, etc.) from your Zod schemas, so if that's the only reason you think Ajv is better, then it might be time to take another look at Zod? It really is great, especially if you buy into the "parse, don't validate" principle that it's built around.
We do something similar. GraphQL type generation is pretty amazing, especially with heavy use of co-located queries on the FE and a typed ORM like prisma on the BE.
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.
If you use a database per customer you should also run a node process per customer. I don't know what exactly you're selling, but that bit of RAM should be in budget alone for the reason that you don't want the requests of customers slowing each other down
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
Absolutely impressive how you are one of the first to find a approach that leads to a 100% bug-free development methodology.
Or, you still have bugs right, so sometimes things break? Maybe you meant something like: This is how I move fast and don't have a certain section of bugs anymore?
I bet they don't even move "fast" since that's relative and we haven't determined any baseline paramters. Very misleading. The comment should be "This is how I move (metaphorically speaking, not physically e.g. increased typing speed) with what I perceive to be faster than alternative stacks that I have explored and that doesn't have a certain section of bugs anymore".
When I used prisma a few years ago I was not impressed and it couldn't do a lot of what I needed so I had to dump into raw sql queries anyway. It was easier for me to use knex and get the types mostly right.
A lot has changed in the past years of Prisma, it's a really great tool, to be honest, "raw sql" escape hatches to do anything raw when you need it, if you haven't tried it in years, I'd recommend you to try again since if you tried it years ago, it was a very different maturity level.
I believe the sidecar is optional now, and I think even the one that exists comes in the form of their paid service called Prisma Proxy. It doesn’t seem necessary for most use cases.
You should take a look at ts-sql-query [1] - it is not as popular as the older alternatives that have been around for a while, but it is a very feature rich query builder that takes type safety very seriously and supports most mainstream databases.
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. One example is our ODATA query and client library, which makes it incredibly easy to debug issues related to it, because everyone uses it.
Anyway, the one place where Typescript isn't great in the fullstack approach is the Database stuff. We used Prismo for the better part of a year, until we eventually moved on to Mikro-orm which has been great so far.
I'm personally not a big fan of OOP or "over architecture", because I've seen how bad it can go too many times. Instead I favour functional programming and keeping things as simple as possible, even having "almost duplicate" code once in a while. So with this in mind, it may strike you as odd that we moved from Prisma to Mirko-orm, but Prisma just clashes with the way we want an ORM to work in so many ways.
Maybe this is by design. Prisma doesn't want to be a "real" ORM after all, but things like having to put everything in a single schema file is bothersome. Yes, you can put it in different files and then cat them together, but that leads to other issues. Like the VSC Prisma extension highlights not working outside the main Prisma.Schema file. More than that though. We like to have "ID, UpdatedAt, UpdatedBy, CreatedAt" sort of things on basically all our models, and since Prisma doesn't have the inheritance I almost never use, that means you need to duplicate it soooo many times. It's also hard to write generic methods for basic CRUD stuff because of the way Prisma uses the Prisma Client Classes it auto-generates to operate. On top of that, migrations can't go backwards in Prisma.
Some of these issues are on the Prisma road map, others aren't, and you're always going to bang heads with an ORM, but Prisma just didn't feel as mature as it's extremely excellent documentation (and marketing) might lead you to believe in my experience.
I can certainly see myself using it again, once their roadmap is a little further ahead though.
Duplicate code is one of the biggest near-non-problems programmers waste a ton of time trying to address.
Sure, duplication isn't a goal, but DRY shouldn't hold back work as long as it has no meaningful consequence on performance. In some cases, duplication is a good thing, but your average programmer will address duplication by making a routing more complicated and further away from where it's being used. This is often a mistake.
Worse yet is when programmers DRY up tests. Tests are the worst place to be applying DRY. The point of testing isn't to write an entirely new application on top of your actual application. If you're DRYing up your tests a lot, you're probably writing a second application and should probably stop doing that.
> 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.
> We do this the other way around, by using Scala.js so we can use Scala on the frontend as well as the backend.
I've wondered about this approach for a while, but have yet to actually try it in any meaningful context. Do you use a framework like React via Scala.js, or are you doing something different?
Yeah it's React and some component library etc.. Library interop is pretty good if the library has type information available, and most of them do these days.
I'm using prisma with postgres. It's pretty nice. You define all your tables in their custom schema format which has VS Code integration and lots of type checks so it will tell you if there's a problem with the schema. You can generate types from the schema file automatically and also a statically typed ORM layer that will let you write queries against those tables with full code completion. It also will generate migration scripts for you when your schema changes.
It's not as good as EF by a long shot (nothing really is), but for most queries it works fine. You can also use SQL or stored procs for the exception cases which no ORM ever fully replaces anyways.
I prefer static types all the way, but my looser rule I've come up with in order to play nicely with others is that you're not allowed to interface something with poor type definitions/enforcement with another thing that's also bad at that. Including transport/wire formats, so if you're presenting JSON you'd better be able to tell me a good story about type safety on both the sender and receiver.
That at least keeps the blast radius of type-related bugs very limited, and makes it easier to figure out where the problem is.
Openapi, then codegen on both ends — frontend (orval) with TS and react-query, and backend with golang (openapi codegen) for the server's request and response objects.
There is so much "let me just see if this works..." tap tapppy tap .... "no... NO WAY... OMG IT WORKED!" with Svelte.
Very little surface area. It embraces your knowledge of plain ole CSS/JS/HTML and empowers you with reactivity and a means of if being able to add motion to your ui.
Newbs and Pros alike can build fast with it. That speed + reactivity allows your software to better keep up with your converstaions that make it all so. Thats insanely powerful.
It's soooo good. Congratulations to Richard Harris and everyone on the Svelte/SvelteKit Team! <3
Backing up how great it is that so much of Sveltekit is built using basic web standards. More often than not when I'm wondering what the shape of an object or function is in Sveltekit, I realize that it's exactly the same as you'd find on MDN documentation.
It's an incredibly refreshing experience compared to other frameworks that create custom concepts for everything they do.
This is what they said about React when it first blew up. Compared to Angular, it's much closer to being *just javascript™*. But I wonder how well that'll hold up after the honeymoon phase
The builder.io team made a tool called Mitosis[^0] that lets you input a component written in almost any framework and automatically recreate that same component in any other framework including Vue, React, Qwik, Angular, Svelte, React Native, Lit, web components, and even Swift
It's always interesting to try out different frameworks and compare the plain HTML version of certain components with this tool
> This is what they said about React when it first blew up
FWIW, I think that "it's much closer to being just javascript™" statement has absolutely held up over time (Angular, esp. the old angular.js is painful compared to React for this reason), AND that Svelte is likely a step closer again (which they can do because they have an entire compiler and aren't reliant on embedded a DSL inside of JavaScript).
I agree Svelte is a step closer, but most people agree that modern React has at least somewhat strayed from just javascript™. Server components by default, hooks, JSX, synthetic events, etc have added many more layers of abstraction. I fully support these developments. I just think they're a necessary byproduct of a project maturing. I fear that if Svelte ever blows up past a niche framework, it will also stray from it's "use the platform" philosophy out of necessity as well
Unlike React/JSX, Svelte uses ASTs that adhere to HTML, JavaScript, and CSS (non-JSX) format. Yes, there is a minimal Svelte-only API footprint, but the native AST parsers means that parsing is much more respectful of correct code validation, versus JSX's own idiomatic set of ThingsYouCannotDo™.
I had exact same experience with it "it just worked", I started playing with few days ago and compared with other frameworks where I had to fight my to do what I wanted to do, from libraries to non oblivious behaviours. In SvelteKit it just works and it's refreshing. Especially love the builtin animation stuff.
Except it forces you to use node js, or do I read it wrong? Can we get a streamlined js framework that is just about the frontend and let’s you use whatever backend language you want? I know there is react, vue and angular but they seem so bloated
We are using SvelteKit frontend with Python backend (Pyramid + SQLAlchemy). When I started the project, I considered doing Python backend + templated HTML frontend a la Django, but SvelteKit server-side rendering was so good that I decided against this. Before I have done JSP, PHP, Django, Next, React and everything between, so I have some experience to compare. Despite all progress on Node.js backends, they still cannot compete with Python for complex SQL + ORM use cases.
The frontend is open source and available here if someone is interested what a complex SSR heavy SvelteKit application deployment looks like:
The SSR server is a lightweight Node.js web server (Vite), but you can have it nicely along your backend API web server (Pyramid in our case). Both are reverse proxied behind the same domain using Caddy.
I'm looking at the frontend source code, and the Svelte components look almost the same as VueJS single file components using the composition API. Can someone who has used both comment on both their pros/cons?
Svelte is a frontend framework, which you can use to build anything from a full SPA to a single button. SvelteKit is a Node backend framework that integrates tightly with Svelte.
SvelteKit is a Javascript backend framework. It only uses Node at build time (with hopes of replacing even that with e.g. Deno), the deployed serverside component will happily run outside of Node.
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.
Yes, the whole point of SvelteKit is that it's SSR+hydrate. But it doesn't need Node for that. It'll run on just about any Javascript engine, including Cloudflare Workers which is quite close to pure V8 + standard web APIs.
You seem to be conflating a few different concepts. Store are absolutely reactive across all components and pages. They are prefaced with $, and there are a bunch of native stores that you can use such as $page.
You can even create variables reactive to one another by declaring a variable like so:
$: y = x * 2
Using the export let x = default; option is for passing data from the parent component/page to a child. If you want variable changes in the child to be reflected in the parent, you can use a store ($ notation), or you can use bind like so:
<ChildComponent bind:x={someValue}>
In my opinion, all of this is much much easier than in competing frameworks.
I'm really struggling to follow what you're trying to do - but why do you not just use the same writable store in both your page and template/component?
Also, maybe look into store subscriptions and/or reactive declarations for what you're trying to do.
Regardless, it sounds like you really need to just read the docs or do a tutorial.
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.
Do i get this right, using SvelteKit SSR frontend node server and it communicates with backend FastAPI server via json. This is nowadays called a normal stack oO. (by the way i like Svelte but SvelteKit makes only sense if you stay in JS land, and i'm not willing to jump ship from python to js/ts ;))
I tried htmx and so far i really like it and the + is i just have "one" backend.
- 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.
You can always find workarounds for these cases, often using `<svelte:component>`, 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:
Jsx is expressive but it comes with a deviation from html. And loses optimization opportunities.
Templates are closer to html, can be better optimized but lack expressiveness.
Is there a third option which has both? Not yet for sure. Right now, you need to compromise somewhere.
The only pragmatic option is to support both template and jsx (Vue approach) but then people complain about "complexity" and "multiple ways to do same thing"
Reacts performance problems don't come from JSX, but rather how single updates can affect the entire tree below it.
Solid uses fine-grained observability like Svelte and achieves similar performance [1].
SwiftUI uses static diffing, fine-grained observability, and avoids re-renders by comparing view dependencies [2]. It is performant even on watches.
Not sure what you mean by `React's Typescript-centric design`, React used Flow from the very start and also had PropTypes for plain JS. Typescript support came much later.
I've been keeping a reference implementation of a SvelteKit blog, inspired by @leerob's nextjs site: https://github.com/sw-yx/swyxkit/ for the past year and it's now updated for 1.0. hope it helps someone get going!
I've been using SvelteKit since July of this year on downforeveryoneorjustme.com and it's easily my favorite Javascript framework at this point. I found Svelte made sense to me almost immediately and debugging issues has always been a breeze.
I have been building an application in SvelteKit and it's an incredible framework. I really believe it's going to become the dominant front-end framework in the next few years.
I completely agree except that I would say "full stack framework" instead of "frontend framework." Just add a db and you are good to go. I tried it out when building a couple of non-critical internal apps for clients (basic CRUD apps, but with some pretty complex business rules). SvelteKit is beautifully designed. It makes things that used to be a bit of a pain super easy to understand and implement. You can use pretty much any NPM vanilla js/ts library. The timing here could not be better for me. I will definitely be using SK for my next project.
What about validation, CORS, cookies, encrypted sessions, etc? A backend (or full stack) framework should at the very minimum include those kind of things.
It's a major gripe I have with all the new full stack frameworks. The focus is on rendering and dealing with requests but they are quite sparse in bread and butter backend features. Other than routing you're basically on your own.
The community will probably start making third party plugins but I would rather have official plugins I can 100% trust like Fastify does.
It's full stack because you write the code that you want to run on the server AND the code that you want to be shipped to the browser both within SK. Not because it does everything. You would want to choose your favorite libraries for those things, e.g., zod is my fave for validation.
SvelteKit ships with a SSR server (Vite) and file system based routing out of the box. It does most of things, though not all. SvelteKit = Svelte + SSR + integration layer.
Though I expect the situation improve a bit soon, as now SvelteKit 1.0 release is out from the door.
SvelteKit 1.0 is the one release I was actually waiting for. I've seen a lot of flashy stuff launch in the frontend framework recently but this one feels...genuine?
Huge congratulations to Rich and team! Hope I'll be able to contribute to Svelte's growth someday.
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
I'm just completing a job using svelte/kit, tailwind, postgres, typescript.
Actually, I was new to the entire stack, but it went smooth as butter.
(Though I have plenty of experience with JS, HTML, CSS, other databases, etc.)
IMO, svelte and sveltekit are well designed and have a great dev experience.
LOL, as I was writing this he was apologizing on the stream for the breaking changes. That was a bit of a pain, but not really that bad. My only real gripe is using folders to organize both layout hierarchy and route hierarchy is going to turn out to be a mistake.
What bothers me about it is that the routes and layouts have to live in the same hierarchy... Of course this is very usually OK, but layouts have an aspect of visual design while routes follow a logical organization. These are going to change according to different priorities and can be controlled by very different groups/people/authorities. There will be conflicts, and when that happens, you're going to be refactoring code (e.g. to factor out common bits to a component that can suddenly no longer live in the same layout) and moving it around.
The fundamental problem is that folders are now being used for two different concerns, which will inevitably lead to conflicts (and developer pain).
Edit: oops, you're actually talking about the removal of the option to have routes defined by a file, so that a route must be defined by a folder. I'm completely fine with that. I don't know why people complain about that. All the interesting routes end up with more than one file anyway, and who needs a special extra-simple way to organize the uninteresting routes, which are already simple?
The src/routes/posts/[slug]/+page.svelte thing is pretty recent, it used to be just src/routes/posts/[slug].svelte. I'm not exactly thrilled with the new naming...
I left the framework for this reason. When I asked about it, I was told "this is what Next will be doing soon". I need more reasoning than that, and it was indicative of the decision making process. Turned me off. Aside from that, Svelte is SUPER fast and easy to use. I may give it another go at some point.
I thought it was weird and couldn't see the reasoning, but personally I just persisted with using it and in the end I've found the new structure perfectly workable and perhaps even marginally prefer it. So yeh, it might seem stupid but maybe just try and use it more to find out if it's really that big of a problem for you. The rest of the gains I've had from SvelteKit were too good to pass up, it's overall just a superb dev experience.
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?
Elm hasnt had the momentum for years, its gonna be a long shot for it to go anywhere from here
> but I don't think it's been proven to work at large scales
i basically have this saved now:
notable companies now using svelte not just for internal apps but customer facing, critical stuff:
- huggingface (for everything, including gradio)
- alaska airlines (entire customer flow)
- razorpay (payment dialogs)
- schneider electric (many things)
- ikea (entire ecomm experience)
- riot games (league of legends client)
- Brave (search page)
- Square (developer portal)
- several YC startups
- and basically every notable data journalism outlet on the planet (Bloomberg, the Economist, Reuters, Les Echos, german and japanese publications, pudding.cool, and of course the NYT)
Nice. I think the most significant one listed there is huggingface. It's very widely used but rarely "for everything". I think that shows most companies still aren't confident in it enough to bank everything on it quite yet, but it seems like we're pretty close!
Edit: and yeah you're right about Elm. Probably not a good choice for first timers. But it's a great example of what a FE that adheres to functional programming philosophies could look like. Given React's recent developments I think the skills gained from trying it out would definitely carry over to React and other emerging frameworks. Although it's famously stable and error-free, it's not been battle tested for very large and complex apps so it's likely only a good choice for sideprojects atm.
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).
and before angular was jquery. But I do think there's quite a big difference between React and Angular. Angular never reached the level of marketshare that React has even if it was close. And even when it was close it was only for a few years. React has been the standard for nearly a decade now. And React has been much more explicit about growing its ecosystem whereas Angular has much fewer 3rd party plugins/tools. In addition to all that, Svelte has technically been around since 2016. Even if we cheat and say it only really started getting attention in 2018-2020, it has still been rising slower than Vue did when it launched. In the latest StackOverflow survey (2022), Svelte still hasn't even surpassed the 5% threshold for how many developers have used it.
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
I'm surprised that 5% of developers have used svelte. That seems like a lot, I was under the impression that webdevs are not the majority of software developers.
In 2019: React.js 31.3%, Angular/Angular.js 30.7%, Vue.js 15.2%
I'm sure those number skew towards a certain kind of dev. Hopefully this gives you a better idea of how skewed it is. Also note: it's an online survey. Devs of niche frameworks can and often do encourage people to rate their framework higher
complex dashboards like CircleCI or client portals like maybe your bank or health insurance portal
many pages and lots of functionality with lots of data floating around like Reddit, Twitter
literally everything/anything like Facebook, GitHub, etc
For simple apps, I'd go with a PWA if possible. For single, mostly informational, pages you usually just need a static site. For a company blog, some of these tools could be used to make the frontend for a CMS, but you can also just get away with Wordpress, Squarespace, etc most of the time unless they want some really custom functionality. Then there's also micro-frontends and Astro and other related tools if you're trying to do a lot of different things and wanna mix and match different solutions to different problems
It's impossible to say this early. Still a very community-driven project. Rust was in a similar position at one point but it wasn't really until Mozilla took the helm that people felt confident enough to say "it's hear to stay". At this point it's been at least used by NYTimes, Facebook, Apple, Spotify, etc but I don't think any of these companies have a lot betting on it yet. It certainly has a huge following in the dataviz community and, for historical reasons, amongst journalists. Additionally it's regularly tops the State of JS surveys as the most loved framework. But none of that is really concrete imo
If you're learning a new framework and you're concerned about stability React is still definitely the way to go. I think both React and Svelte are good at depending on generalizeable front-end skills that can carry over to other frameworks though so if your career doesn't depend on it, I don't think learning Svelte is a waste of time at all
Svelte would be a good choice. It's important to note that there has been a ton of convergence in architecture, so for example, even though Remix uses React, the app architecture it encourages is quite similar to that of SvelteKit. So if you learn one, you would likely find the other familiar and easy to pick up.
I would strongly recommend Vue3 in the composition style with <script setup>.
It's really close to svelte's style, of simplicity and principle of least astonishment. It also uses very explicit wrappers for reactive objects so that there's isn't as much magic happening. For me, vue's reactivity is order of magnitude simpler than things like svelte.
Vue also has a pretty well established community and a pretty solid foundation.
remix isnt like those others in that you’d also need React to do UI
at this point React Vue and Svelte are all decent production choices, as for what is intuitive that really depends what YOU like, different strokes different folks
svelte is probably the most fully integrated toolkit (animations, state mgmt, server side rendering, serverless api routes, etc) and ships the least javascript at this point tho if u want the quick sales pitch
- Reasonably intuitive, especially if you stick to functional components and aren't messing around with low-level renders
That said, I enjoyed building a web app with Svelte. It's extremely simple and powerful. Its only disadvantage is it is new and has a fraction of the market share.
I've used many frameworks and in my opinion Svelte+Sveltekit has the very best simplcity over power ratio. If you don't mind job offers being quite scarce for this stack right now that's about the best choice. You can do the Svelte tutorial for a sneak peek of this.
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 have to rely on third party library for routing, state management, querying etc. like React-Query, React-Router, Redux (Next has a router but you still need libraries to do the rest). Some of these libraries change a lot, some become less relevant, new libraries emerge, and in the end when you start a React project you must go through the "library shopping" step.
> you still have to rely on third party library for routing, state management, querying etc.
Take a peek at Joystick [1]. I designed it as the exact antithesis to this. It's full-stack (Node.js back-end with a fully ssr'd component framework designed for the long-term) and doesn't introduce any special paradigms (i.e., vanilla HTML, CSS, and JavaScript—no attribute tricks/compilers needed). Everything is designed to be a fixed-API with the only changes being added functionality (i.e., no random "hey this is deprecated now" rug pulls).
> When using React/NextJS you still have to rely on third party library for routing, state management, querying etc.
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.)
Congrats to Svelte. More than a couple years ago, I gave my team the opportunity to go React, Vue or Svelte after giving them time to test them out. React was basically the legacy code that we were familiar with. This was right around the first hooks release and after using it for a while, and we had a nasty redux state manager, and nothing about React felt truly great for DX besides JSX, and that was everywhere already.
I'm happy with Vue but every time I look at Svelte code I get a bit jealous. Its a very nice environment, one I would pick up for personal projects if that time was there, and I wish Svelte godspeed and a huge adoption curve.
All the praise for SvelteKit in this thread peaked my interest. But where would I start?
I'm currently looking around to find a modern "toolkit" to write a new webbased frontend for our traditional desktop app. It's goin to be more or less CRUD with lots of tables/grids.
Currently I favour vue.js with Quasar because of all the tooling and ressources it offers. It looks like it's easy to start with a traditional "navigation on the left, content on the right" layout.
I need nothing fancy, it's going to be business CRUD for a small circle of users. Deployed on premises at our customers sites.
I’d be careful about the hype train in a 1.0 milestone announcement post. There’s plenty weird and quirky about svelte + kit. Take it with a grain of salt.
While the breaking changes were rough this year, the new structure is a huge improvement over before. It is now extremely clear the order that items are loaded, and what is loaded on the server vs client. Form actions are also amazing.
Congrats to the team and thanks for all the hard work!
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 internals.
>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 <Button> or <TextInput>. I could not figure out how to type my <Button> component so that it takes every single attr and event that a regular <button> 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.
Auto-define exports of native properties for a child widget. This should be posted as an issue on the Svelte core repo. It would save a ton of time building components!
Now that Kit 1.0 is out the door the team can turn their attention back to Svelte proper so now is the time.
Exciting to see this hit 1.0! The new tutorial site looks great and I love that the sidebar is searchable now. Also the Cmd-K search on the docs (https://kit.svelte.dev/) is awesome to have as well.
I've been really enjoying working with Svelte for the last year or so now. My main project is a video editor, running under Tauri and using plain client-side Svelte, but I've also used SvelteKit to throw together a few little admin dashboard-y things and it's been very quick to get started with. Right now those projects are pretty lightweight too, just SvelteKit with TypeScript, the pg-promise package to connect with Postgres, and a handful of handwritten SQL queries.
Congrats to the team! Looking forward to see what the future holds for Svelte[Kit].
I'm a React expert, but whenever I can I choose Svelte, it really is a joy to use. I've been using SvelteKit for some time now, it's great to see it out of beta so I can shill it to more projects.
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.
It’s not directly comparable. Svelte apps have an extremely minimal runtime, because Svelte compiles components into largely freestanding chunks of code.
The benefit is that for smaller apps, SvelteKit can be extremely lean, but the cost grows as the number of components and pages increases, since a number of attributes can’t draw from a larger, monolithic runtime (or set of runtimes).
You do have to build moderately large apps to hit the point at which it’s a drawback however.
I’ve been using SvelteKit since very early beta, and it’s been amazing to watch it evolve along the way to 1.0. It is by far and away the most intuitive framework I’ve used and I can’t say enough good things about it.
Congratulations to the team, and keep up the good work!
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.
Sveltekit saves your scroll position in session storage so refresh and back/forward navigation feels like regular browser behavior. If your scroll position is resetting on refresh that may be a bug.
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
This appears to be deliberate depending on the page. Looking at the network inspector as I click around, I see cache-control: private, no-cache on the responses for docs content, but I do see caching on the blog pages.
Been using Sveltekit and love what the community has done to the framework. Makes life of a developer very straightforward and I'm sure that Sveltekit will rise to be a dominant frontend framework soon.
Congrats all Svelte team and community, highly antecipated project. Played a lot with the early releases. To me, Svelte suite is the best option for front-end applications.
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 state of affair in that regard.
Is 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.
I literally started working on a project in Svelte after spending like two afternoons trying to do it in React.
Svelte is such a God send. So much simpler and powerful than React. Not to mention the fact that React only handles the UI layer but is too unopinionated w.r.t. the application architecture.
I enjoy Svelte a lot and congrats on the release. However the job market for Svelte seems really weak, at least for US dev salaries. I hope Sveltekit increases adoption, as it's a nice alternative to NextJS
Svelte is getting traction for sure. Arguably, it is easier for a vue dev to transition to svelte than a react dev, because of heavy similarities in vue and svelte.
However, react has more people. And most of newer devs are on react for job purposes. So svelte will get disproportionately higher react devs than vue devs.
I've been following Svelte since it first appeared on the State of JS survey. So cool to see it evolve over time and happy to see all the hard work pay off!
I always wonder why Hacker News is such a magnet for comments trashing product announcements while also knowing almost nothing about the product being announced.
In the long run the approach Svelte takes seems very promising so I've kept an eye on it for a while now. I took umbrage at the snooty messaging towards a browser in a tool pitched as a way to "build production-grade websites".
Sure but the "snooty messaging" you're commenting on is from their tutorial, which is used to conveniently learn the framework in the browser.
This has nothing to do with Sveltekit itself. You can download a demo repo, enter "npm run dev" and see that it works on Safari without any issues. Hell, I've deployed ecommerce sites using Sveltekit used by 500k people/month where 60% of visitors are on mobile Safari without any issues.
So when a product is posted that you are unfamiliar with, maybe try giving it more that 30 seconds of consideration before dismissing it due to something completely unrelated to the product itself.
That's the tutorial - which uses WebContainers, which are indeed an experimental technology. It has nothing to do with the production readiness of SvelteKit the framework.
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.
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
It's worse than that, sadly. A lot of what is perceived as standards (that is they have an official sounding spec on w3c somewhere) are actually not, and are just Chrome releasing stuff.
If you go to MDN and click on multiple experimental APIs you'll find they do have a spec. And they are shipped in Chrome. And then you start reading the spec and it says "It is not a W3C Standard nor is it on the W3C Standards Track.": https://developer.mozilla.org/en-US/docs/Web/API
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.
Speaking as nearly-exclusively a JSX/TSX user, it is not really true that it is closer to HTML than Svelte's templating. People who like and use Svelte report the opposite.
Agree with this. Iterating with Array.map and returning nodes to compose, say, unordered lists in JSX is most decidedly un-HTML-like.
I can see the drawback to learning yet another templating language, and on this point I’d just say “to each their own”. I feel like either approach is fine. Svelte’s templating is pretty minimal, so there isn’t much to learn.
I don’t get why you’d want to try to emulate html. The syntax and closing tags are brutal on the eyes. I’d prefer a more lisp style syntax for representing 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
Why is there a new frontend-whatever-work / tool every week? Database stuff is fairly stable, so is backend stuff. Browser APIs seem stable to me too? Why can't you guys decide that this is how things are best done
SvelteKit is nothing new. It's been kicking around for 2+ years with tons of user satisfaction (and 3 years prior to that under another name), but this is the first major/stable release.
As someone who's written both a GUI framework and a database library for Haskell, the answer here is actually really obvious. There's only a small set of algorithms for database query execution, all of which are well understood. Thus, there are best algorithms that you can implement.
On the other hand, there is no correct way to style, animate, interact with, etc a button. The design space for UX is much larger than that of databases, and existing libraries touch maybe a small percentage.
+ 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.prisma.io)