Ask HN: What tech stack would you use to build a new web app today?
74 comments
I would pick what I know best and get the product out with that. Or better: I would pick the most popular framework I know best.
Most known and good frameworks can do what you want. If the product becomes succesfull, scaling up your team with good engineers is harder than scaling the product.
As long as you can do raw queries on your complex database, I do not see how a backend framework you don’t know yet will help you. You will sell the product, not the framework it is running on. If your current stack is still widely used in the industry, focus on the product, not on new tech
Small addition: if it is for hobby or learning: pick one new framework and keep the rest of the stack.
Most known and good frameworks can do what you want. If the product becomes succesfull, scaling up your team with good engineers is harder than scaling the product.
As long as you can do raw queries on your complex database, I do not see how a backend framework you don’t know yet will help you. You will sell the product, not the framework it is running on. If your current stack is still widely used in the industry, focus on the product, not on new tech
Small addition: if it is for hobby or learning: pick one new framework and keep the rest of the stack.
Rails 7 with Turbo and Tailwnd. Use the Jumpstart Pro template.
https://jumpstartrails.com/
Host on Heroku.
The boilerplate features are covered. Productive developer patterns are already in place. Great test coverage.
You can jump right in to building out the business logic.
https://jumpstartrails.com/
Host on Heroku.
The boilerplate features are covered. Productive developer patterns are already in place. Great test coverage.
You can jump right in to building out the business logic.
The one you have the most experience with.
Unless you have specific requirements where that stack isn't a good fit, or other reasons not to choose it like it's too niche to hire people for.
Or if you're doing this for fun, use the most exciting one that still looks like it's at least somewhat stable and won't cause you too much trouble.
Unless you have specific requirements where that stack isn't a good fit, or other reasons not to choose it like it's too niche to hire people for.
Or if you're doing this for fun, use the most exciting one that still looks like it's at least somewhat stable and won't cause you too much trouble.
Really, whatever you know. But since that's a boring answer, so I'll assume you know exactly what I know. Anyway, as usual, "it depends," but there's probably a big split based on a specific question:
"How rich is your frontend?" (and how rich will it need to get in the next few years)?
If the answer is "rich enough" - ie you want a fair deal of dynamic content and a web-app feel, I'd do:
- ReactJS via create-react-app with typescript and ReactQuery for talking to the API
- Rails in api mode serving a rest api
- Postgres for the db and Redis for caching/job storage.
- Heroku
If the answer is "not that rich," save yourself some complexity:
- Normal Rails with server-rendered pages
- Postgres/redis
- Heroku
Note: swap out Rails with whatever similar thing is in a language you know: Django, Phoenix, Laravel, etc.
Now, all that said, I strongly suspect the dominant answer to this question is shifting. There seems to be a new wave of JS-based tools like Next.JS and RedwoodJS that seem batteries-included-enough to replace Rails as the getting-off-the-ground-quickly framework of choice. We'll see, though- it's still early.
"How rich is your frontend?" (and how rich will it need to get in the next few years)?
If the answer is "rich enough" - ie you want a fair deal of dynamic content and a web-app feel, I'd do:
- ReactJS via create-react-app with typescript and ReactQuery for talking to the API
- Rails in api mode serving a rest api
- Postgres for the db and Redis for caching/job storage.
- Heroku
If the answer is "not that rich," save yourself some complexity:
- Normal Rails with server-rendered pages
- Postgres/redis
- Heroku
Note: swap out Rails with whatever similar thing is in a language you know: Django, Phoenix, Laravel, etc.
Now, all that said, I strongly suspect the dominant answer to this question is shifting. There seems to be a new wave of JS-based tools like Next.JS and RedwoodJS that seem batteries-included-enough to replace Rails as the getting-off-the-ground-quickly framework of choice. We'll see, though- it's still early.
I have been exposed to many different tech stacks over the years. This https://github.com/gengstrand/clojure-news-feed repo contains the code used to evaluate thirteen different stacks which is what I can share publicly. What I can say is that the best choice of tech stack depends on what is being called for. Is this for an early stage startup or an intrepreneurial greenfield project? Is this for an MVP or just the next component in an already formalized microservice architecture? What are the skillsets of the developers that you will have access to? Have you reached agreement that you can throw it all away and start over or are you expected to have to live with the choice of tech stack for the life of the product? Are you mobile first? These are all important questions that very much shape the decision.
I'd start with a .NET 6 MVC application. The default templates will get you started with robust routing and authentication, and you can back it with anything you want for database access. You might find it valuable to start with Entity Framework (EF) - depending on whether or not you want/like to use an ORM. That would provide pretty robust tools for managing database migrations, etc.
It's "boring" but C# is an extremely developer-friendly language these days, and it's hard to beat the availability of documentation, examples, and libraries.
EDIT: and on the front-end, the MVC templates that Microsoft provides start with Bootstrap. I've found Bootstrap and some native Javascript provides more than enough flexibility for quite a while. Bootstrap is great for an MVP, and has a lot of flexibility to make it look good!
It's "boring" but C# is an extremely developer-friendly language these days, and it's hard to beat the availability of documentation, examples, and libraries.
EDIT: and on the front-end, the MVC templates that Microsoft provides start with Bootstrap. I've found Bootstrap and some native Javascript provides more than enough flexibility for quite a while. Bootstrap is great for an MVP, and has a lot of flexibility to make it look good!
MVC 6? not Core?
.NET 6 is Core. Microsoft hasn't used the Core moniker since .NET 5 dropped it.
I meant that "MVC 6" is quite old, ain't it?
https://stackoverflow.com/questions/38109524/what-is-the-dif...
https://stackoverflow.com/questions/38109524/what-is-the-dif...
MVC 6, was "never" released. As this answer[0] describes.
[0]: https://stackoverflow.com/a/38109745
[0]: https://stackoverflow.com/a/38109745
Ditto.
downside: you have to run on windows
Not really true any more! I've done most of my development in Windows, true, but my understanding is that development on Linux is pretty much a first-class citizen these days.
You can definitely deploy/host the application on Linux just fine - we do it all the time!
You can definitely deploy/host the application on Linux just fine - we do it all the time!
And how does it work now? I remember I tried it in the old days, but noticed serious memory leaks after 30 days or so, so I decided to periodically restart the server to avoid them as debugging this stuff was a real PITA.
.NET 6 runs on Linux without issues (for web applications, it's mostly GUI applications where there are still major differences between platforms).
Run what? You can run it on Linux and Macos:
https://dotnet.microsoft.com/en-us/download
https://dotnet.microsoft.com/en-us/download
No, you don't. I work for an enterprise software company that built on .NET for 20 years. We just upgraded the codebase to .NET 5, and all future deployments will be on Linux.
Wow. This is more than half a decade old joke.
that wouldn't be true: https://docs.microsoft.com/en-us/dotnet/core/install/linux#u...
Phoenix + Liveview + TailwindCSS + Postgres
Unless a static site or buy option fits right, otherwise it doesn't get any better than a Liveview based app for continued productivity.
Unless a static site or buy option fits right, otherwise it doesn't get any better than a Liveview based app for continued productivity.
I suggest you add more details, like advantages and disadvantages, and tell us how many years of experience you have working with projects in this technology/frameworks.
I am curious about something that works on node buy is as boring but robust as a LAMP stack, I just hate maintaining shit where stuff is already deprecated after just a few years, but upgrading is not an option because there are 100 dependencies and we are in the hell where 10 packages are vulerable but can't be updated, 10 are abandoned and I need to research replacements and somehow make time to transplant them...
My question is this, Ruby has Rails, PHP has Laravel or Sympony, Python has Django , what is the equivalent for node backends (something that is old,stable and not a mix of 100 packages from 100 random dudes)?
I am curious about something that works on node buy is as boring but robust as a LAMP stack, I just hate maintaining shit where stuff is already deprecated after just a few years, but upgrading is not an option because there are 100 dependencies and we are in the hell where 10 packages are vulerable but can't be updated, 10 are abandoned and I need to research replacements and somehow make time to transplant them...
My question is this, Ruby has Rails, PHP has Laravel or Sympony, Python has Django , what is the equivalent for node backends (something that is old,stable and not a mix of 100 packages from 100 random dudes)?
Elixir is modern tooling on top of the BEAM / Erlang Virtual Machine. This is tech that has been running Telecom systems, companies like Whatsapp, Discord, Klarna, and software like RabbitMQ, etc for decades. The core libraries are very active and well maintained.
I tend to prioritize "capabilities to build compelling systems" which, to me, means getting to production quickly so user feedback / product-market-fit tests can occur, but then also scaling a team to maintain the application over time because once you've found a good fit its time to grow.
To me stateless CRUD isn't compelling. Its too easy - if your app just provides a GUI in front of a database for Create/Read/Update/Delete operations your app is a database not an app and if all it takes for someone to clone your app is 5 minutes of CRUD generators, then that's not exactly a defensible position to build a business on.
Phoenix like other web frameworks provides generators and quick paths for your usual Web + Database applications. Run some commands and you've got a web app with database persistence. Everyone can do this nowadays (Django, Rails, etc) What Elixir and Phoenix does better than anyone else is distribution, concurrency, fault-tolerance, and real time streaming. These capabilities are possible because of deep details on the virtual machine level and become trouble for cooperatively scheduled runtimes elsewhere (e.g. Python, JS, Java, Ruby, etc).
If you're building something with: websockets, collaboration, chat, i.e. anything real time between many users - save yourself the trouble and look into an Elixir/Erlang solution like Phoenix/Liveview/Channels/Presence.
On the human side Elixir has top tier documentation (example: https://hexdocs.pm/phoenix/channels.html#content) - we've found it doesn't take long for developers with at least a few years under their belt to pick up the language/framework and be productive. You don't have to know everything - just build some familiarity of where to look and you'll figure it out. Its very important that this human side be scalable as well, and that means developer experience, documentation, on-boarding, etc.
I've been using Elixir/Phoenix every day since 2017 to build apps, glue systems together, rebuild Ruby/Rails/PHP/Python apps that don't scale anymore and in general just ship features on time consistently.
The thing that I'd toss in as an "it depends" on the technical scaling side is Postgres - its a boring single server relational database that just works but is still a single server architecture made for spinning disk persistence. SSD/NVME/Persistent Memory and more are new foundations for persistence which means new databases on the new foundations may warrant attention soon. 99% of the time just use Postgres/MySQL though. If you're not sure just use Postgres. For many apps in finance or with stringent auditability that are log-centric using a time series and/or event sourcing database makes sense for the projection / read model flexibility. That said you can use Postgres for that so there's no good excuses for not using it.
I'd say the biggest disadvantage/con to using Elixir/Erlang is that its more of an expert's tool-set. These are sharp tools made for engineers that make sense to engineers with experience to know they want fault tolerance and concurrency. What this means is that a newbie developer might not know what they don't know they want to know when building an app the first time. This caveat is probably true with any tech stack, but there will be a lot to learn about the backend because there's more possibilities on this backend stack. These backends-as-a-service (Firebase, Hasura, etc) will get things rolling quickly but in my experience all the real juicy core problems of your business will end up in backend code and when that happens you'd better hope those quick solutions don't get in the way.
I tend to prioritize "capabilities to build compelling systems" which, to me, means getting to production quickly so user feedback / product-market-fit tests can occur, but then also scaling a team to maintain the application over time because once you've found a good fit its time to grow.
To me stateless CRUD isn't compelling. Its too easy - if your app just provides a GUI in front of a database for Create/Read/Update/Delete operations your app is a database not an app and if all it takes for someone to clone your app is 5 minutes of CRUD generators, then that's not exactly a defensible position to build a business on.
Phoenix like other web frameworks provides generators and quick paths for your usual Web + Database applications. Run some commands and you've got a web app with database persistence. Everyone can do this nowadays (Django, Rails, etc) What Elixir and Phoenix does better than anyone else is distribution, concurrency, fault-tolerance, and real time streaming. These capabilities are possible because of deep details on the virtual machine level and become trouble for cooperatively scheduled runtimes elsewhere (e.g. Python, JS, Java, Ruby, etc).
If you're building something with: websockets, collaboration, chat, i.e. anything real time between many users - save yourself the trouble and look into an Elixir/Erlang solution like Phoenix/Liveview/Channels/Presence.
On the human side Elixir has top tier documentation (example: https://hexdocs.pm/phoenix/channels.html#content) - we've found it doesn't take long for developers with at least a few years under their belt to pick up the language/framework and be productive. You don't have to know everything - just build some familiarity of where to look and you'll figure it out. Its very important that this human side be scalable as well, and that means developer experience, documentation, on-boarding, etc.
I've been using Elixir/Phoenix every day since 2017 to build apps, glue systems together, rebuild Ruby/Rails/PHP/Python apps that don't scale anymore and in general just ship features on time consistently.
The thing that I'd toss in as an "it depends" on the technical scaling side is Postgres - its a boring single server relational database that just works but is still a single server architecture made for spinning disk persistence. SSD/NVME/Persistent Memory and more are new foundations for persistence which means new databases on the new foundations may warrant attention soon. 99% of the time just use Postgres/MySQL though. If you're not sure just use Postgres. For many apps in finance or with stringent auditability that are log-centric using a time series and/or event sourcing database makes sense for the projection / read model flexibility. That said you can use Postgres for that so there's no good excuses for not using it.
I'd say the biggest disadvantage/con to using Elixir/Erlang is that its more of an expert's tool-set. These are sharp tools made for engineers that make sense to engineers with experience to know they want fault tolerance and concurrency. What this means is that a newbie developer might not know what they don't know they want to know when building an app the first time. This caveat is probably true with any tech stack, but there will be a lot to learn about the backend because there's more possibilities on this backend stack. These backends-as-a-service (Firebase, Hasura, etc) will get things rolling quickly but in my experience all the real juicy core problems of your business will end up in backend code and when that happens you'd better hope those quick solutions don't get in the way.
>To me stateless CRUD isn't compelling.
Most of the time getting started with a project involves the boring CRUD stuff, a table with users, login, register, reset password stuff. Then on top of that you add some business logic, this days if you do an SPA that will be done mostly in frontend and in backend you need to validate stuff so users don't send you garbage. The initial comment just had a list of names and no explanation, like what languages/tech is used and for what is good and what are disadvantagtes, now you comment is welcomed and is very clear what this tools are good at.
Most of the time getting started with a project involves the boring CRUD stuff, a table with users, login, register, reset password stuff. Then on top of that you add some business logic, this days if you do an SPA that will be done mostly in frontend and in backend you need to validate stuff so users don't send you garbage. The initial comment just had a list of names and no explanation, like what languages/tech is used and for what is good and what are disadvantagtes, now you comment is welcomed and is very clear what this tools are good at.
Any thoughts on using React or another frontend framework with liveview?
Don’t.
Not necessary in 99.9999999999999% of cases and would just duplicate most functionality.
And no, your app is not that 0.000000000001%
And no, your app is not that 0.000000000001%
Just theorycrafting here, not saying I have an app that fits the description.
Wouldn't you want client side statefulness if you have an app like an online spreadsheet (google sheets, microsoft excel) that could occasionally lose connection but you still want users to be able to continue working on their document?
Wouldn't you want client side statefulness if you have an app like an online spreadsheet (google sheets, microsoft excel) that could occasionally lose connection but you still want users to be able to continue working on their document?
Yeah offline or complex client side state management is a good use case for Javascript. There are Hooks and Push Events with Liveview for real time integrations with Liveview in those scenarios. In my experience offline requirements are rare and often in mobile scenarios where a native or Flutter-like approach is a good option.
Complex client side state or collaborative features might use something like https://github.com/slab/delta-elixir or https://www.inkandswitch.com/local-first/ which is where I'd want JS.
Complex client side state or collaborative features might use something like https://github.com/slab/delta-elixir or https://www.inkandswitch.com/local-first/ which is where I'd want JS.
React might make sense for some specific components wired up with hooks in Liveview for real-time interactions. So if you have a complex client side component that is already available in React and you don't want to recreate it - I'd just add the JS dependency to Phoenix and embed it in a view somewhere. There are definitely complex client side interactions where integration with Liveview would be preferred, however in those cases React isn't necessarily the best option - vanilla JS or D3 or something of that nature tends to be the winning ticket.
TBH I wouldn't greenfield a new web app with React if I could avoid it - either wrapping a Liveview in a React component or React in a Liveview the purpose would be to gradually transition away from React running the whole DOM/view for a large existing app.
A GraphQL server with Phoenix/Absinthe for a multi-platform app web + mobile (android + ios) is reasonable but still a bigger company/team solution. React + State management like Redux is a ridiculous amount of overhead by default and I would never implement a greenfield web app that way in 2021.
A Liveview interaction follows something like
Backend State <query/command> Liveview <websocket> Client/Browser (where only minimal diffs of changed state is sent over the wire)
and React is
Backend State <query/command> Controller <JSON/HTTP> Axios <Redux/State Management> Virtual DOM <> Browser/Client (where whole json payloads are sent and encoded/decoded over the wire)
Where new state means re-fetching all the state each loop instead of just what changed. The amount of data sent over the wire by default is massive with this React + HTTP/JSON model.
The encoding/decoding of JSON and having to send full payloads then having state management occur in multiple places and languages - it ends up being a lot more to know and think through. The lines of code to write and amount over the wire with the classic JSON over REST + React/Redux makes it almost 100% required to have separate front/backend developers which then means coordination costs for every new feature.
So TLDR; React could make sense for complex components you don't want to reinvent the wheel for or when those interactions are complex and client side. Existing web apps with a lot of React code that is too much to port over all at once can be done piece by piece (where I'd recommend heading towards handling navigation in Phoenix/Liveview and components in React).
TBH I wouldn't greenfield a new web app with React if I could avoid it - either wrapping a Liveview in a React component or React in a Liveview the purpose would be to gradually transition away from React running the whole DOM/view for a large existing app.
A GraphQL server with Phoenix/Absinthe for a multi-platform app web + mobile (android + ios) is reasonable but still a bigger company/team solution. React + State management like Redux is a ridiculous amount of overhead by default and I would never implement a greenfield web app that way in 2021.
A Liveview interaction follows something like
Backend State <query/command> Liveview <websocket> Client/Browser (where only minimal diffs of changed state is sent over the wire)
and React is
Backend State <query/command> Controller <JSON/HTTP> Axios <Redux/State Management> Virtual DOM <> Browser/Client (where whole json payloads are sent and encoded/decoded over the wire)
Where new state means re-fetching all the state each loop instead of just what changed. The amount of data sent over the wire by default is massive with this React + HTTP/JSON model.
The encoding/decoding of JSON and having to send full payloads then having state management occur in multiple places and languages - it ends up being a lot more to know and think through. The lines of code to write and amount over the wire with the classic JSON over REST + React/Redux makes it almost 100% required to have separate front/backend developers which then means coordination costs for every new feature.
So TLDR; React could make sense for complex components you don't want to reinvent the wheel for or when those interactions are complex and client side. Existing web apps with a lot of React code that is too much to port over all at once can be done piece by piece (where I'd recommend heading towards handling navigation in Phoenix/Liveview and components in React).
Personally, Django.
I know it so I can develop relatively quickly with it plus it has so much built in already.
It's also a mature framework so chances of running into bugs for normal tasks is lower than newer/cutting edge and if I do need help there are high chances that someone else has already dealt with it.
Deployment and scaling can also be taken care of by something like Heroku which already supports Django so I can best use my time focusing on the development of valuable business logic rather than reinventing the wheel and maintenance.
I know it so I can develop relatively quickly with it plus it has so much built in already.
It's also a mature framework so chances of running into bugs for normal tasks is lower than newer/cutting edge and if I do need help there are high chances that someone else has already dealt with it.
Deployment and scaling can also be taken care of by something like Heroku which already supports Django so I can best use my time focusing on the development of valuable business logic rather than reinventing the wheel and maintenance.
I would also recommend just going for something boring and fast (for you the developer).
It's a poc, the only thing that matters is getting it out the door. In fact code might not even be necessary for a poc.
If this were me, I would dig up my last abandoned monolith with all the boring details like routing, migrations, seeding, auth all figured out, rip out the old code and start from there.
It's a poc, the only thing that matters is getting it out the door. In fact code might not even be necessary for a poc.
If this were me, I would dig up my last abandoned monolith with all the boring details like routing, migrations, seeding, auth all figured out, rip out the old code and start from there.
> that can scale for a few years
I don't think "boring and fast" is the only consideration you should take. You should also consider: "are you going to be able to read your code without wanting to tableflip after a year?"
I don't think "boring and fast" is the only consideration you should take. You should also consider: "are you going to be able to read your code without wanting to tableflip after a year?"
This is the best answer. Don't just build what you know, use something you've already built (if you have it.) Maybe upgrade to the latest, first. And also: If you are trying to create a new business, go as boring as possible. Do you want to experiment with technology, or with business logic? Decide this up-front and if its business logic, go with boring, stable, mature, steady, proven. You can always create experimental services once the boring monolith business takes off.
All my poc are in vanillajs. Quick and dirty.
NextJS, Prisma, Postgres via Supabase as data store + Postgraphile connected (for GraphQL).
Some Go/Deno microservices deployed via GCP Cloud Run where needed.
On NextJS side, use React Query (https://react-query.tanstack.com) to call GraphQL & cache where needed. For CSS, use Tailwind & some nice primitive components from Radix UI (https://www.radix-ui.com/docs/primitives/overview/introducti...). Deployed on Vercel.
Tech choices are mostly motivated by how good tooling for it is in VSCode.
I'd maybe switch React Query with Relay (https://relay.dev) but Relay seems more complex.
Some Go/Deno microservices deployed via GCP Cloud Run where needed.
On NextJS side, use React Query (https://react-query.tanstack.com) to call GraphQL & cache where needed. For CSS, use Tailwind & some nice primitive components from Radix UI (https://www.radix-ui.com/docs/primitives/overview/introducti...). Deployed on Vercel.
Tech choices are mostly motivated by how good tooling for it is in VSCode.
I'd maybe switch React Query with Relay (https://relay.dev) but Relay seems more complex.
I wouldn’t go very fancy unless I have specific requirements or challenges. Starting point:
- Backend: Express + Sequelize + Postgres
- Frontend: Svelte + TailwindCSS + Webpack
Do I need to iterate very quickly on the database schema? Use a document DB like MongoDB (JSONB on PG is great but has caveats such as atomicity)
Do I need to handle a high volume of background jobs? throw Redis into the mix.
Do I want HA? Make the app stateless (JWTs help in this case but come with their own caveats), duplicate the server 2 more times and put a cloud load balancer in front of all 3 servers.
Do I need to serve low bandwidth or low power devices? I go vanilla JS and limit how much interactions does the page have, or move to server-side rendering only altogether.
And the list goes on. But with no specific constraint, my personal preference goes to that initial stack (and I’m very productive in it).
- Backend: Express + Sequelize + Postgres
- Frontend: Svelte + TailwindCSS + Webpack
Do I need to iterate very quickly on the database schema? Use a document DB like MongoDB (JSONB on PG is great but has caveats such as atomicity)
Do I need to handle a high volume of background jobs? throw Redis into the mix.
Do I want HA? Make the app stateless (JWTs help in this case but come with their own caveats), duplicate the server 2 more times and put a cloud load balancer in front of all 3 servers.
Do I need to serve low bandwidth or low power devices? I go vanilla JS and limit how much interactions does the page have, or move to server-side rendering only altogether.
And the list goes on. But with no specific constraint, my personal preference goes to that initial stack (and I’m very productive in it).
What is your favourite stack? Django and Rails are both accelerators.
Personally, I'd go with Django and React with PostgreSQL and probably Bootstrap, because that's what I know. I would be running on my domain on day 1.
What frameworks would have you and your team up and running on day 1? Pick those.
Personally, I'd go with Django and React with PostgreSQL and probably Bootstrap, because that's what I know. I would be running on my domain on day 1.
What frameworks would have you and your team up and running on day 1? Pick those.
With Django you also get the free admin tool which is an add-on in most frameworks.
For Ajax-y stuff, I am really excited by the new crop of "HTML-as-a-Service" or "HTML-over-the-wire."
https://htmx.org/
https://hotwired.dev/
https://htmx.org/
https://hotwired.dev/
Two choices:
- Node with no fancy stuff like TypeScript, just JavaScript, jest for tests, React on frontend, require 100% test coverage (or less test coverage but use TypeScript).
- Java with Sptrig Boot and their reactive web framework and React on frontend.
Reasons:
- Either of those provides _fast_ feedback loop. Node.js is even faster.
- Either of those have got _huge_ ecosystem and a library for anything.
- Either of those is supported by major cloud vendors and first-class citizens.
- The amount of googleable information on the web if you need some docs or help is enormous.
- The amount of devs to hire is huge.
- IDE support for both is excellent.
- There are official base docker images for either, there are version management tools for either that are very easy to use (mvnvm, sdkman, nvm).
- If your webapp grows you have _a lot_ of scaling opportunities.
KISS database side and use Postgres. Try to make someone else to manage it for you, something like Aurora from AWS or whatever there’s out there. If you _really_ sure that your database model is solid and won’t change and/or you’ve got lots of money to through at problems you may want to consider something managed NoSQL like DynamoDB or what was that, Cosmos from MS?
Host on something like Heroku but be aware that they lack a lot of Enterprise required compliances, we recently moved away from it because of that (we have to be compliant).
- Node with no fancy stuff like TypeScript, just JavaScript, jest for tests, React on frontend, require 100% test coverage (or less test coverage but use TypeScript).
- Java with Sptrig Boot and their reactive web framework and React on frontend.
Reasons:
- Either of those provides _fast_ feedback loop. Node.js is even faster.
- Either of those have got _huge_ ecosystem and a library for anything.
- Either of those is supported by major cloud vendors and first-class citizens.
- The amount of googleable information on the web if you need some docs or help is enormous.
- The amount of devs to hire is huge.
- IDE support for both is excellent.
- There are official base docker images for either, there are version management tools for either that are very easy to use (mvnvm, sdkman, nvm).
- If your webapp grows you have _a lot_ of scaling opportunities.
KISS database side and use Postgres. Try to make someone else to manage it for you, something like Aurora from AWS or whatever there’s out there. If you _really_ sure that your database model is solid and won’t change and/or you’ve got lots of money to through at problems you may want to consider something managed NoSQL like DynamoDB or what was that, Cosmos from MS?
Host on something like Heroku but be aware that they lack a lot of Enterprise required compliances, we recently moved away from it because of that (we have to be compliant).
I would use something boring[1] since the virtues and vices are well known, documentation, libraries, and code samples will be plentiful, and I would not need to waste a ton of time getting a team up to speed on something cutting edge or finding and fixing edge cases that had not been ironed out yet.
[1] https://mcfunley.com/choose-boring-technology
[1] https://mcfunley.com/choose-boring-technology
I would go with where my strengths are currently.
Python + FastAPI + SQLAlchemy + Postgres. With React on the FE. Maybe try a CSS framework that plays nice.
However, I am a Python developer with some JS experience. If I was, say, a Java developer by day I'd probably pick Java and a corresponding framework.
Go to war with the army (of knowledge) you have.
Python + FastAPI + SQLAlchemy + Postgres. With React on the FE. Maybe try a CSS framework that plays nice.
However, I am a Python developer with some JS experience. If I was, say, a Java developer by day I'd probably pick Java and a corresponding framework.
Go to war with the army (of knowledge) you have.
I’d write it in assembly and output it to punch cards organized in standard 5ft tall filing cabinets. /s
Ruby on Rails.
I'm currently working on better integration with reactjs, something like this: https://www.viget.com/articles/phoenix-and-react-a-killer-co...
Then I will use react too.
I'm currently working on better integration with reactjs, something like this: https://www.viget.com/articles/phoenix-and-react-a-killer-co...
Then I will use react too.
Rails mostly.
Don't get stuck on technical details. It is a mental blocker and hinders from actually solving the problem.
I used to think about the best stack and how easy it is to maintain in the future, but never managed to finish any side projects.
For my last project Flashdictation.com I used such an unconventional stack for me: Next.js and Supabase. It just solves my problem. Exposing the database would have been such an huge mental blocker, but with the proper safety it just works.
Sidenote: I am just trying out the above stack, just pick one with which you are comfortable and think about what you want to solve.
I used to think about the best stack and how easy it is to maintain in the future, but never managed to finish any side projects.
For my last project Flashdictation.com I used such an unconventional stack for me: Next.js and Supabase. It just solves my problem. Exposing the database would have been such an huge mental blocker, but with the proper safety it just works.
Sidenote: I am just trying out the above stack, just pick one with which you are comfortable and think about what you want to solve.
I'd use something like https://prisma.io or https://hasura.io
I would just build a simple web service using FastAPI and use React on the FE. FastAPI is a really nice framework for prototyping or even for building POCs. When the need arises to scale you don't have to to undo a lot of your work. Swagger first class support is a boon. Pydantic and all other database related support also comes at no cost.
You already know about React so just go for it.
DB - You won't go wrong with either MySQL or Postgres or you could save some setup time and go with one of the PaaS offerings from Google or AWS.
You already know about React so just go for it.
DB - You won't go wrong with either MySQL or Postgres or you could save some setup time and go with one of the PaaS offerings from Google or AWS.
Backend: Firebase, between Firestore and Real-Time Database you get enough flexibility to quickly iterate on your db schema, Functions are also good enough to handle any kind of backend (easy to integrate with express). They have a dropin authentication UI/backend that take care of all the signin/signup/forgot password logic.
Frontend: Vue.js + Vuetify, you get a simple frontend framework that gets you started in a couple of minutes, and more than enough UI components that you'd need for a POC
Frontend: Vue.js + Vuetify, you get a simple frontend framework that gets you started in a couple of minutes, and more than enough UI components that you'd need for a POC
Depends obviously.
I'd start with Phoenix + Postgres, it'll handle stuff from beginning to very end. When i started with rails, time from project start to first optimization/adding caching milestone was really short. With phoenix it took maybe years because naive code still working fine and there are no need to tune/add caching/optimize things
Keep frontend as boring and plain as possible, then either something like Vue.js or LiveView - highly depends on use case
I'd start with Phoenix + Postgres, it'll handle stuff from beginning to very end. When i started with rails, time from project start to first optimization/adding caching milestone was really short. With phoenix it took maybe years because naive code still working fine and there are no need to tune/add caching/optimize things
Keep frontend as boring and plain as possible, then either something like Vue.js or LiveView - highly depends on use case
As a non-web developer I have no stack that I already know so I gave a try something I've been following for a while - Deno. I once tried node.js and I had to install node... and npm... and nvm... and whatnot. What I like most about Deno is that it's more self-contained - just the Deno executable. I think it's by the Node's author(s) so I suppose they know of mistakes to fix with Deno :)
For you requirements, you can't wrong with postgres, nodejs and react. Why juggle between two languages when you can just use one?
Jesus… not React.
The HOWL (Hypermedia On Whatever you’d Like) stack
pick one: htmx, unpoly, Hotwire
pick one: vanillajs, alpine, hyperscript
pick a css framework you like
and then use whatever backend you prefer
pick one: htmx, unpoly, Hotwire
pick one: vanillajs, alpine, hyperscript
pick a css framework you like
and then use whatever backend you prefer
A full stack framework on any language you prefer, such as Laravel or Rails. Interactive parts with hotwire/livewire or Unpoly.
Definitely not a bare bones one (express, flask, Sinatra, etc...) And absolutely NOT an SPA.
Deploy on heroku until it gets expensive (like, an ops salary expensive) then move to AppEngine.
Definitely not a bare bones one (express, flask, Sinatra, etc...) And absolutely NOT an SPA.
Deploy on heroku until it gets expensive (like, an ops salary expensive) then move to AppEngine.
geeked on Nextjs lately, but I would definitely give a hard look at rails7 with HotWire if I was starting fresh today on a new project.
A good static-generation/CDN hosting story would be essential for any choice I made.
Also Firebase tools: Firestore, Firebase Functions & Firebase Auth.
A good static-generation/CDN hosting story would be essential for any choice I made.
Also Firebase tools: Firestore, Firebase Functions & Firebase Auth.
I am right now doing one and going with Deno, firebaseauth, redisgraph and redis, not yet decided on css .. might go with the https://gdcss.netlify.app/docs.html
Flask and plain vanilla JavaScript.
Angular + Angular Material + Firebase. If you make if beyond certain point on the Angular learning curve, which is certainly very steep, coding turns into easy cruising. In my opinion unbeatable for SaaS projects.
Rails or Laravel or Phoenix if you're lucky. Postgres for the db backend. Don't overly complicate the Javascript if you can avoid it.
Vanilla JS is extremely underrated.
Vanilla JS is extremely underrated.
Depends.
If you ask me to build a web app, I'll role with Flutter Web and Firebase for hosting / auth/ data storage.
But your sorta limited with that. Vue is cool too
If you ask me to build a web app, I'll role with Flutter Web and Firebase for hosting / auth/ data storage.
But your sorta limited with that. Vue is cool too
C#, ASP NET Core, Postgres (If SQLite is a problem)
Go with:
* sqlc to connect to PostgreSQL Aurora.
* zerolog for logging.
* chi for router.
* jQuery for JS interactivity.
Those are where my strength lies. I can add or reduce components at a lightning speed using Go.
* sqlc to connect to PostgreSQL Aurora.
* zerolog for logging.
* chi for router.
* jQuery for JS interactivity.
Those are where my strength lies. I can add or reduce components at a lightning speed using Go.
> Obviously things depend a bit on the use case
A bit? It's one giant "it depends" as far as I'm concerned.
A bit? It's one giant "it depends" as far as I'm concerned.
I’d go for what you already know or what excites you :) Phoenix Liveview or try the whole Remix stack craze.
Go, Cassandra, HTMX, Alpine.js.
Rails with Hotwire, Postgres
SvelteKit + Supabase or Rails.
Based on familiarity alone:
backend: python flask, sqlalchemy
frontend: react, bootstrap
backend: python flask, sqlalchemy
frontend: react, bootstrap
angular/asp.net
I know angular isn't popular these days but I am still convinced it is superior in every way to react.
fastapi + sqlmodel, probably; just because i'm very comfortable in python and don't care about front-end very much.
Laravel, baby.
temporal .. https://temporal.io
[deleted]
- React
- Vite
- PostgreSQL
- AWS CDK
- Vite
- PostgreSQL
- AWS CDK
If you were to build a new web app product with a fairly complex database schema and functionality, what tech stack would you use as a starter? Obviously things depend a bit on the use case, but let's assume it's a web application that doesn't need high concurrency.
More like building a PoC of a web app start-up that can scale for a few years.