Rust in the backend and frontend, via WebAssembly. I'm using the Leptos framework for the frontend.
How do you find Rust for the frontend?
I enjoy it a lot. It's the first time that I find frontend actually fun.
A lot of the memory management aspects of Rust are bypassed by Leptos, so that doesn't come up as much as one might think.
And I do find Rust's type system really helpful for actually portraying the UI state. For example, if you execute a function that can fail, you don't have to catch some exception and then pass the error message separately into the UI or whatever.
Instead, you get a Result-type from that function, which contains either the data you want to render in the UI or the error information you want to render instead.
So, you can just pass that right through to your rendering code. And then there's pseudo-HTML inline in the code, where you can do full-blown Rust-pattern-matching to properly handle such a Result-type and simply render the appropriate UI element.
No horrid multi-line ternaries, no uninitialized variables, no separate boolean checks before accessing a variable. You simply know at all times what information is actually available.
What's also really nice with backend and frontend in the same language, is that you get compile-time-guaranteed compatibility between them, because you can simply use the exact same model types and API route constants.
It is still a relatively young ecosystem, so there are still breaking changes every so often. And well, obviously you won't find anywhere close to the number of UI component libraries as you can find for JS. So, for an experienced JS dev, it is likely a step back in productivity.
But if you've got Rust expertise instead or only backend folks on your team, then I heartily recommend it.
Check out Greg Johnston's interview with Primeagen. Greg's just an awesome dude all around. I just hope one day there comes a solution for the large bundle sizes associated with wasm frameworks
Vue/Nuxt + ASP.NET Core + PostgreSQL
I've used Nuxt a few times, but I end up in absolute hell sometimes tracing down bugs and incompatabilities. More so with Nuxt 3. Probably not an issue for more experienced Devs.
I find myself coming back to the simplicity of running a separate backend, even though that reintroduces a lot of the problems that Nuxt alleviates.
/me Sort by top
wat
HTMX, Python, JavaScript.
Though I would like to try Go for the backend if I would just find some time for it.
Also Svelte and Sveltekit is very nice
svelte front end, golang backend, postgres for database. But it depends on the needs of the project. Choose technology because it's the right fit for the job, not because it's your favorite.
Choose technology because it’s the right fit for the job, not because it’s your favorite.
100000%
I think this is strictly less than 100% true. There is significant value in using tools you know and like
Well it's difficult when the main difference between technologies is mostly preference. Real pros and cons require tons of analysis.
TypeScript React (although I like Svelte better, it's hard to pitch for business projects), C# ASP.NET Core API, Postgresql.
React, Go, GraphQL, and PostgreSQL
How's Go for a backend? I've used it abit, stupid fast.
React / TypeScript / Vite (sometimes Redux) for the front end, C# .net / SQL for the backend..
Fast-ish to get up and running, scales to a medium-large project with minimal headaches
Yessss.
C#/.Net backends are the best. The long term stability, DevX, and the "it just works" nature of all the tooling makes it a great choice. It's also fast, which makes scaling for most applications a non-issue.
I've switched to postgres for DB from SQL server, have never looked back, would recommend.
Yup all valid points. And I find Nuget to be a heaps less painful package manager than other ecosystems
Typescript React from cloudront Typescript express on ecs. PSQL on RDS
.Net + EF Core + Vue/TS + Postgres. Redis as needed, Kafka as needed.
I can get applications built extremely quickly, and their maintenance costs are incredibly low. The backends are stable, and can hang around for 5, 10+ years without issue or problems with ecosystem churn.
You can build a library of patterns and reusable code that you can bring to new projects to get them off the ground even faster.
Would recommend.
But .NET has a 3 year LTS schedule unless you're on the invincible .NET Framework 4.
You'll have to update your server OS at some point and then your .NET version will be too old to be installed and then you'll have fun bugs to squash from all the new versions of things interacting...
Javascript/Preact/Lesscss on frontend with a backend written i Go, using Postgres for data needs. Sometimes with websockets in between if needed.
Go and Next.js.
For data, PostgreSQL or SQLite depending on the need.
markdown+frontmatter+handlebars, bun, sqlite.
HTMX + Go.
Go as a backend has a very nice multithreading model to extract more speed and value from your app.
The built-in standard libraries provide many good abstractions.
Also the templating engine is very nice to use.
I hate go templating, I really really do. I don't even really know why. I just hate it.
Vue + Express + Typescript + Postgres
Though I am playing around with Firebase and Firestore at the moment so that simpler projects have less backend overhead
React +python + postgres/sqlite
SvelteKit + PocketBase + CapRover.
Typescript, svelte, django, postgresql with a dash of celery, redis and pushpin
Depends:
For websites: Htmx + AlpineJs on the front end, ASP.NET Razor Pages and PostegreSQL on the backend.
For Web Apps; Blazor and PostgreSQL
My current favorite is mostly Rust-based with the tide crate, tide-jsx crate, vanilla JS, postgres crate, and Postgres in Docker. Super easy, super fast (to develop and run), but I haven't made any large web projects with this stack yet, just small stuff.
Mocha, C, Informix
Nuxt + graphql or C# (the latter I’m still studying but it’s not bad).
Total beginner here, but I like VueJS with Pug Templating for the front end. I also could go with just HTML/Pug for most of my projects since they are small.
On the backend I only really have experience with NodeJS, but have created small personal applications with the Express, Hapi, and Fastify frameworks. For databases, I have only worked with MariaDB and Sqlite, with Knex/ObjectionJS the only query builder/ORM-like libraries I've utilized thus far. I hear a lot about PrismJS for a full fledged ORM and will probably look into that at some point. I've played around with Postgres, but have yet to build anything using it yet, and have not worked with GraphQL or Redis either.
I'm intrigued by the Python FastAPI and Flask frameworks (no interest in Django tbh). I also am intrigued by Go for servers, but have yet to even write a single line of Go code yet.
On the Front End, I'm looking to learn React next as it's everywhere, but am much more interested in learning Svelte and HTMX.
I'm seriously very surprised to still see so many relational databases in the top responses... guess I'm just in fantasy land. I hate writing SQL... good at it, but it's not fun (to me).
I hate when I have to work with non SQL based persistence.
To each their own I guess. 😇
API gateway all the things... it's annoying at times, but I don't want to have to manage a dbs... or write SQL.
Of course, there's always some data store to manage, but I prefer the ones with fewer switches and easier scaling (like DynamoDB).
In the end, it's a matter of preference. I prefer writing custom map reduce functions, you prefer SQL indexes.
Honestly, the amount of requests and data I'm handling for personal projects could be easily handled by the filesystem... so, ddb is great and I stay free tier... like always.
Use an ORM. With NoSQL on relational data, you're guaranteed going to write a worse, relational solution than what relational databases provide. SQL is shit, but rewriting relational logic is worse.
Except when you're not worried about scale because you're building a small side project... I don't want to pay for a db (or the hardware to host it) for my play projects. My in-home play server is a very old home PC that is very underpowered for today's software.
Not sure I get what you're saying. Sqlite exists and works on very underpowered hardware.
Ah, yes... good old sqlite... I guess the main reason I go the route I go is that I like writing map/ reduce functions... much more than reorganizing tables because I structured them poorly to start.
In fact, the project I'm on right now at paid job has a lot of structure transformation... and I'm enjoying it so much that I'm not even pining for one of my million side projects.
While it's not the most performant way to do things, I feel like data structure manipulation is one of the easiest to read ways to get from point a to point b.
Express, JavaScript (with JSDocs+TS for type-checking) and Postgres
Laravel (PHP) + Vue (JS)
WordPress wirh custom templates running on a LAMP stack.
Does streamlit displaying data from a csv file count?
Streamlit + Snowflake DB
It is very limited but it's the best framework for dashboards.
Django/DRF has really grown on me as I've been working in it more, also I always feel myself come back to flask for small projects.
FastAPI was fun but I don't feel it will have enough longevity
I'm Definitely a backend python fanboy
Frontend: react is neat but I'd like to explore Vue more again
I'm used to :
Angular or React + Pyramid(Python) or Strapi(Nodejs)
Rust in the backend and frontend, via WebAssembly. I'm using the Leptos framework for the frontend.
How do you find Rust for the frontend?
I enjoy it a lot. It's the first time that I find frontend actually fun.
A lot of the memory management aspects of Rust are bypassed by Leptos, so that doesn't come up as much as one might think.
And I do find Rust's type system really helpful for actually portraying the UI state. For example, if you execute a function that can fail, you don't have to catch some exception and then pass the error message separately into the UI or whatever.
Instead, you get a
Result-type from that function, which contains either the data you want to render in the UI or the error information you want to render instead.So, you can just pass that right through to your rendering code. And then there's pseudo-HTML inline in the code, where you can do full-blown Rust-pattern-matching to properly handle such a
Result-type and simply render the appropriate UI element.No horrid multi-line ternaries, no uninitialized variables, no separate boolean checks before accessing a variable. You simply know at all times what information is actually available.
What's also really nice with backend and frontend in the same language, is that you get compile-time-guaranteed compatibility between them, because you can simply use the exact same model types and API route constants.
It is still a relatively young ecosystem, so there are still breaking changes every so often. And well, obviously you won't find anywhere close to the number of UI component libraries as you can find for JS. So, for an experienced JS dev, it is likely a step back in productivity.
But if you've got Rust expertise instead or only backend folks on your team, then I heartily recommend it.
Check out Greg Johnston's interview with Primeagen. Greg's just an awesome dude all around. I just hope one day there comes a solution for the large bundle sizes associated with wasm frameworks
Vue/Nuxt + ASP.NET Core + PostgreSQL
I've used Nuxt a few times, but I end up in absolute hell sometimes tracing down bugs and incompatabilities. More so with Nuxt 3. Probably not an issue for more experienced Devs.
I find myself coming back to the simplicity of running a separate backend, even though that reintroduces a lot of the problems that Nuxt alleviates.
/me Sort by top
wat
HTMX, Python, JavaScript.
Though I would like to try Go for the backend if I would just find some time for it.
Also Svelte and Sveltekit is very nice
svelte front end, golang backend, postgres for database. But it depends on the needs of the project. Choose technology because it's the right fit for the job, not because it's your favorite.
100000%
I think this is strictly less than 100% true. There is significant value in using tools you know and like
Well it's difficult when the main difference between technologies is mostly preference. Real pros and cons require tons of analysis.
TypeScript React (although I like Svelte better, it's hard to pitch for business projects), C# ASP.NET Core API, Postgresql.
React, Go, GraphQL, and PostgreSQL
How's Go for a backend? I've used it abit, stupid fast.
React / TypeScript / Vite (sometimes Redux) for the front end, C# .net / SQL for the backend..
Fast-ish to get up and running, scales to a medium-large project with minimal headaches
Yessss.
C#/.Net backends are the best. The long term stability, DevX, and the "it just works" nature of all the tooling makes it a great choice. It's also fast, which makes scaling for most applications a non-issue.
I've switched to postgres for DB from SQL server, have never looked back, would recommend.
Yup all valid points. And I find Nuget to be a heaps less painful package manager than other ecosystems
php + cobol
:(
Typescript React from cloudront Typescript express on ecs. PSQL on RDS
.Net + EF Core + Vue/TS + Postgres. Redis as needed, Kafka as needed.
I can get applications built extremely quickly, and their maintenance costs are incredibly low. The backends are stable, and can hang around for 5, 10+ years without issue or problems with ecosystem churn.
You can build a library of patterns and reusable code that you can bring to new projects to get them off the ground even faster.
Would recommend.
But .NET has a 3 year LTS schedule unless you're on the invincible .NET Framework 4.
You'll have to update your server OS at some point and then your .NET version will be too old to be installed and then you'll have fun bugs to squash from all the new versions of things interacting...
Javascript/Preact/Lesscss on frontend with a backend written i Go, using Postgres for data needs. Sometimes with websockets in between if needed.
Go and Next.js. For data, PostgreSQL or SQLite depending on the need.
markdown+frontmatter+handlebars, bun, sqlite.
HTMX + Go.
Go as a backend has a very nice multithreading model to extract more speed and value from your app.
The built-in standard libraries provide many good abstractions.
Also the templating engine is very nice to use.
I hate go templating, I really really do. I don't even really know why. I just hate it.
Vue + Express + Typescript + Postgres
Though I am playing around with Firebase and Firestore at the moment so that simpler projects have less backend overhead
React +python + postgres/sqlite
SvelteKit + PocketBase + CapRover.
Typescript, svelte, django, postgresql with a dash of celery, redis and pushpin
Depends:
For websites: Htmx + AlpineJs on the front end, ASP.NET Razor Pages and PostegreSQL on the backend.
For Web Apps; Blazor and PostgreSQL
My current favorite is mostly Rust-based with the tide crate, tide-jsx crate, vanilla JS, postgres crate, and Postgres in Docker. Super easy, super fast (to develop and run), but I haven't made any large web projects with this stack yet, just small stuff.
Mocha, C, Informix
Nuxt + graphql or C# (the latter I’m still studying but it’s not bad).
Definitely not JS or Java
How are you doing Nuxt and GraphQL without JS?
I meant as in with Express and similar
Go with the frontend kept as simple as possible.
Leptos + SurrealDB
Total beginner here, but I like VueJS with Pug Templating for the front end. I also could go with just HTML/Pug for most of my projects since they are small.
On the backend I only really have experience with NodeJS, but have created small personal applications with the Express, Hapi, and Fastify frameworks. For databases, I have only worked with MariaDB and Sqlite, with Knex/ObjectionJS the only query builder/ORM-like libraries I've utilized thus far. I hear a lot about PrismJS for a full fledged ORM and will probably look into that at some point. I've played around with Postgres, but have yet to build anything using it yet, and have not worked with GraphQL or Redis either.
I'm intrigued by the Python FastAPI and Flask frameworks (no interest in Django tbh). I also am intrigued by Go for servers, but have yet to even write a single line of Go code yet.
On the Front End, I'm looking to learn React next as it's everywhere, but am much more interested in learning Svelte and HTMX.
I'm seriously very surprised to still see so many relational databases in the top responses... guess I'm just in fantasy land. I hate writing SQL... good at it, but it's not fun (to me).
I hate when I have to work with non SQL based persistence.
To each their own I guess. 😇
API gateway all the things... it's annoying at times, but I don't want to have to manage a dbs... or write SQL.
Of course, there's always some data store to manage, but I prefer the ones with fewer switches and easier scaling (like DynamoDB).
In the end, it's a matter of preference. I prefer writing custom map reduce functions, you prefer SQL indexes.
Honestly, the amount of requests and data I'm handling for personal projects could be easily handled by the filesystem... so, ddb is great and I stay free tier... like always.
Use an ORM. With NoSQL on relational data, you're guaranteed going to write a worse, relational solution than what relational databases provide. SQL is shit, but rewriting relational logic is worse.
Except when you're not worried about scale because you're building a small side project... I don't want to pay for a db (or the hardware to host it) for my play projects. My in-home play server is a very old home PC that is very underpowered for today's software.
Not sure I get what you're saying. Sqlite exists and works on very underpowered hardware.
Ah, yes... good old sqlite... I guess the main reason I go the route I go is that I like writing map/ reduce functions... much more than reorganizing tables because I structured them poorly to start.
In fact, the project I'm on right now at paid job has a lot of structure transformation... and I'm enjoying it so much that I'm not even pining for one of my million side projects.
While it's not the most performant way to do things, I feel like data structure manipulation is one of the easiest to read ways to get from point a to point b.
Express, JavaScript (with JSDocs+TS for type-checking) and Postgres
Laravel (PHP) + Vue (JS)
WordPress wirh custom templates running on a LAMP stack.
Does streamlit displaying data from a csv file count?
Streamlit + Snowflake DB
It is very limited but it's the best framework for dashboards.
Django/DRF has really grown on me as I've been working in it more, also I always feel myself come back to flask for small projects.
FastAPI was fun but I don't feel it will have enough longevity
I'm Definitely a backend python fanboy
Frontend: react is neat but I'd like to explore Vue more again
I'm used to : Angular or React + Pyramid(Python) or Strapi(Nodejs)