I would recommend to not use a framework at all. I usually maintain legacy projects and modernize them for my clients. Whatever you feel is the latest shiny thing will be the legacy horror of tomorrow.

If I’m free to decide the tech stack it is HTMX with a backend technology that suits the business case. For web related work I usually choose Node.js and fastify without template engine. It’s fast and easy going.

None. I'd use Go with standard library templates and plain ol' CSS with a sprinkle of JS.

If I was forbidden to use that, I'd probably use Ruby on Rails, Django or something like that.

I have a side project im working with on with go as the backend. I haven’t worked in any frontend stuff yet, do u have any example repos or websites i can look at and take inspiration from?

Is it possible to build “nice” websites like that?

Of course you can build nice websites like that-- websites have been made nice before the world had SPAs.

I have made a number of fully profitable (and pretty nice) websites over the last few years using that stack.

I can't point to any specific resource for learning how to do it other than the official docs regarding writing web applications [1]. For me, it all started there and evolved over time.

[1]: https://go.dev/doc/articles/wiki/

PHP / Symfony.

It has Auth, Templating, ORM, Email, Caching, Forms, Validations.

For frontend I like Bootstrap or Tailwind as a base, but for interactivity I use a combination of htmx and Alpine.js, so everything's pretty light-weight.

In the frontend world, I started reducing my reliance on it. I started quite a while ago and had went through jQuery, jQuery UI, bower, gulp, grunt, AngularJS, then the completely rewritten Angular 2+, Vue.js, npm, yarn 1, yarn 2, yarn 3, webpack, rollup, Parcel.js (which I like)...

It was too much for me to keep up. So I stuck with Symfony and try to keep the frontend light-weight.

I’d say use a “real” full stack (or batteries included) framework such as Laravel, Rails or Django. If you do need to use React, Vue, etc, then glue them with Inertia.js which is just a super thin layer that basically just replaces those frameworks templates by a modern js franework. Best of both worlds in my opinion, and a super stable and maintainable stack.

My problem with the ones you are mentioning (next, remix, svelte kit, etc) is that 1) they are not a full solution… you still have to figure out everything else, from authentication, authorization, sending emails, ORM, background jobs, etc… and 2) they’re in constant shuffle and rewrites and change of opinions so maintaining long running projects on these frameworks quickly becomes a nightmare.

If it’s for learning or a side project, then pick whatever. If it’s for business, pick tried and true and something g you’re confident in 2 years will be still maintained and not be a totally different beast (ehem, next).

None. I just use react and express. Does everything I need. I don't use ORMs, I write my queries in sql files. Deployment I use github actions or jenkins.

So you’re either: 1) writting a super basic application, 2) Creating your own abstractions so inventing your own undocumented untested unproven framework or 3) creating a mess no one will be able to maintain.

Which one is it?

Or please, describe how are you doing in your super simple stack:

Authentication, authorization, background jobs, assets bundling, migrations, emails, security (csrf,rate limiting, timing protection, etc), and everything else provided by batteries included frameworks.

The problem with writing raw queries is that you don’t get that sweet sweet type checking

I would even say type checking is a must. We use Zod to define data schemas and have type completion and runtime checking. We even define request and response schemas in Zod for our APIs (inspired by protobuf/GRPC schemas, but without the code generation step).

I'd say you almost never need file-based routing, I'd even go that far to say you don't need routing DSLs for backend (just use if statements, performance will be fine without compiled regular expression to match all routes). The fetch API has request and response objects, and URL and URLSearchParams. But in frontend I find react-router-dom very practical. I think they introduced file-based routing in NextJS and co, because it's easier to generate frontend code bundles per route by listing files at build time. Other than that it's just a gimmick.

And as already mentioned ORMs (object-relational mappers) will give you headaches really soon, it's probably not worth it.

You can use Vite for the frontend part which is more lightweight than NextJS and co. I'd say if you have or your team has already build a web application with such full stack framework once you probably know what is needed and what is not needed in frontend with Vite.

Wrapper functions with typed parameters :)

I do like Prisma, but I find that for quite a few queries it's ridiculously inefficient - things like getting counts, or where you have to get 20 of some model with a bunch of relations - that I find myself using a lot of queryRaw calls. Apparently this is because it doesn't use joins at all, it's all done sequentially. For some of the stuff where I'm getting counts grouped by month it goes down from 20+ seconds to under 200ms using raw SQL.

Wow, had no idea but it's madness that they don't use joins. I think it says a lot about the state of our industry that an ORM can get so popular in 2024 without leveraging such an essential SQL feature. I mean, Entity Framework had this covered 15 years ago... But it's not cool i guess.

Looks like there's preview support for joins now, so at least they are getting there...

I like nextjs deployed on vercel but am not a big fan with the new direction of next so open to other frameworks. The other libraries I tend to change up depending on use case or what I want to try out. (this is mostly for basic crud/LLM wrapper apps)

> not a big fan with the new direction of next

Care to elaborate?

Not the OP but agree with their comment. For me, since Next 13 it's been a mess. The transition to the app router has been incredibly complex with lots of undocumented edge cases and other issues. Rendering in general has become very confusing with server-side, client-side and everything in between. There's also no real guidelines/structure for handling remote content, requiring projects like ContentLayer (which may actually be discontinued).

I'd use https://leptos.dev because you can use a fully typed language (Rust) that is super fast in the backend and also in the frontend (see https://krausest.github.io/js-framework-benchmark/2024/table...)

This looks really good, basically what I always wanted to have. I really don't like frontend development, and everytime I tried some framework it was a teetering ziggurat of javascript and css, but being able to do everything in rust would be perfect.

Do you are anyone else have experience with this and can tell me how well it works in practice and if you hit limitations very fast, where you need to hack something to make it work?

Theoretically, there are no real limitations, as you can do everything with `wasm-binden` that you can do with JS/TS. However, if you expect ready-made UI components or want to integrate any JS library, you will have to invest some time.

Wouldn't recommend unless CPU-bound.

https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...

1) is it like Phoenix LiveView?

2) is it production ready?

1) I have no idea, I'm sorry

2) Yes and no, it really depends on your requirements. We have already created two customer projects with it and are very satisfied (although I personally still prefer the Elm approach to the reactive approach).

I prefer using Next. I've been using Remix at the day-job for about a year now. It's fine, but I still choose to use Next with all personal work. I'd also prefer to work with it professionally. My personal dev-blog started in v12, I upgraded it to v13 a while back (not much involved in that upgrade), and at this moment am refactoring it to v14. A lot has changed, and for the better.

It provides a great solution for most needs and problems. But I think the biggest selling point is that their docs are excellent. I never connected with the Remix docs...they often left me still confused. I've used Remix v1 and updated our two work repos to v2. I still don't feel fluent with it for some reason and often find myself thinking "I prefer the way Next does this".

Someone else here mentioned the T3 stack. That's a good resource to at least see other libraries/services that work well with Next. You don't need to follow any of it blindly, but use it as an information resource.

VueJS - syntax is very simple, you can start using it by importing it in <script> tag, or you can set up a full dev environment with vite, you can use vue dev tools plugin in chrome. It also has a very simple state management system as well as an event bus, if you want to go that route. and for backend - fastapi. i never found those "all-on-one full stack" frameworks to be usable.

This is the way. Vue will outlive them all. It gets the fuck out of your way.

This is the best, most concise description of how I feel about it. They should put THAT on the website instead of "An approachable, performant and versatile framework for building web user interfaces."

Svelte would be my vote. I don't like all the hoops Sveltekit is jumping through. I just want to compile ahead of time and get a bunch of dumb static files I can host somewhere. It's sad watching them move away from that.

Svelte is still there, and Kit is there for fullstack applications.

I rather like the experience of working with Remix. Though it has some quirks. `remix-auth` is OK. `drizzle` works ok. I dunno, it depends on a lot of factors but in the spirit of your question this is what I'll answer.

Remix is my favorite as well from this category. But I’m super conflicted regarding ORMs and data access libraries. All of them are either too new, too unstable, too unmaintained, too VC backed, too little devs/community, etc.

Share the same sentiment and settled on Kysely. Although new, it doesn't try to do too much and has excellent TypeScript support.

Too new, too focused on TypeScript (which I don't use), mostly developed by a single dev that already abandoned other similar projects (objection) and nobody knows what its future is.

This is exactly what I mean.

Compare that to using the ORMs from Django, Laravel or Rails or some of the Java ones. You can be sure than 3~4 years from now they'll still be around, well maintained and probably without big rewrites or API changes.

Not saying that it's not the best option in node land (I don't know), but what frustrates me is that there's no clear option for many core/basic things. And always "the best solution that's going to fix everything" seems to be the one that appeared last. Feels like building on top of mud to be honest.

I get your point. I see Kysely more as a progression from Objection, but that's not the case if you're not into TypeScript. I was using Knex.js like forever and now switching over to Kysely. kysely-codegen introspects the database on every build, and doesn't massage the output model like for instance Prisma does. The database is leading, the only dependency is the query builder API which feels pretty familiar coming from Knex.js. So even though it's new and shiny, it doesn't feel like a huge commitment you can't back out of if things go south with Kysely. Anyway, Node.js does indeed not have these "one true way" giants like the frameworks you mentioned. That's a blessing and a curse.

Yeah, that sounds good to me.

I think that when working with Node the "trick" is to pick libraries/dependencies/frameworks that are either 1) Well know, supported, big community, well maintained, many users, etc or 2) They're small and isolated enough that it wouldn't be a big deal to replace them or to just fork and maintain yourself.

At least that's my kind of unwritten rule about it.

At $dayjob right now I'm using remix+supabase (although the supabase part is going away, but we're keeping postgrest). I have to say I quite enjoy it. DevEx seems good (although we've added quite a bit of our own logic on top). Performance is too early for me to tell. For my personal stuff I tend to do more app-like things, so SSR/SSG is not that useful to me, and I tend to go with pure react+redux. But I might try svelte when the new version comes out, it solves a lot of my issues with it.

Remix is so much better than Next. I’m just crossing my fingers they won’t f**k up.

NextJS is pretty good. Here’s why I’d recommend it:

- It’s so much easier to manage file-based routing. 1 new page == 1 new file.

- Super flexible about client/server-side code on each page

- It’s concise, and easy to understand. The amount of code in a hello-world project is tiny, but scales up to large apps really nicely

- Easy to share things between client and server, typescript enforces type checking between client/server too

- It’s mature, has a huge community and backed by Vercel.

Some cons… I hope you like JavaScript

Phoenix, and by extension elixir, are so nice to work with I could hardly consider using anything else.

Elixir + Phoenix (+ Svelte via live_svelte if you need very very real time stuff). Has everything you need and none of the BS that is the JS ecosystem. :)

Isn’t trpc redundant now that next’s server actions are out?

Helps with larger apps that are not solely Next.js

I'm using Astro for a personal project and couldn't be happier.

It's not exactly the same as next/remix/kit, but does most of the same stuff and is a delight to work with. I love Svelte as well but SvelteKit, not so much

Remix. It ties together a lot of things that make sense.

The loaders and actions for loading and updating data just makes sense. Server side rendering just makes sense.

I use vite. It lets me work on pure React.js with Typescript.

Next.js, Remix, Astro, and Svelte are another layer of abstraction i dont want to deal with.

but what about the backend?

Currently using SvelteKit for a project, and I dig it. I've used Vue in the past and tried to get on the React train, but both felt a bridge too far from good ol' HTML, JS and CSS. Granted, I'm mostly using the packaging and reactivity in SvelteKit - most of my server side code is written in Node using Express to better separate concerns, with some existing in SvelteKit mainly for BFF purposes.

I feel like if, down the road, I decided to ditch a framework altogether, writing it in Svelte may help seeing as there are very,. very few framework specific elements in it. I may also be deluding myself.

Express + Vue

wanna try Astro though

Supabase + SvelteKit = SupaKit

React/Relay front end. Postgraphile/Fastify backend. Postgres database. Typescript. The most OP type safe stack. One change in your database propagates throughout your stack.