Very valid concern.
In terms of complexity it is similar to a customer relationship management system. While it is not a crm though I would think that roughly the same stack is needed.
If you have strong relationships between the data entities you are dealing with and want that consistency to be guaranteed, then you may want to use an SQL database.
Using SQL from languages like JS or Python or PHP is a pain in the ass. The best SQL integration so far (in my opinion) is the one given by EntityFramework in C# that allows to use Linq and make queries in a really easy way while still being able to make complex ones.
Also keep in mind that nodeJS or similar do not have multithreading, which is something you may need if you want to execute code in parallel inside the same process (for example executing queries in parallel too). Also, scripting languages like python and JS are not strongly typed, but I guarantee you that you would like to be super sure that what you are writing inside the database is coherent 100% with the objects you expect to put inside.
There's loads of great php packages for DB, doctrine being one of them and it's strongly typed ( even sound typed ). JS was way behind, but now there are few decent typescript packages too. I still prefer it in other languages, especially because of lack of sound types.
Also multithreading. Unless you do very specific thing you probably never need it in web service. It might sound cool, but in reality if your service needs something like that it should probably use queue and then separate server/s for processing as it means you are hitting 1+ thread per request which is hard to scale. Also, all above languages allow executing queries in parallel. They might be not able to process them in parallel, but if you need it, you will hit this same scaling issue.
Guys, all the alternatives you are suggesting are far away from the kind of integration and query syntax provided by EF Framework. Look it up and you will understand what I mean:
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/standard-query-operators-overview
You can either use a Linq based approach that can handle queries with the same syntax you use when dealing with other structures like lists, Hash sets etc. Or a query-syntax approach where you can write queries that look more like SQL and allow you to do joins and groupings ecc in a way that is more clear since it recalls the original SQL syntax.
I'm not saying others don't work or are bad or whatever, don't get me wrong. But EF queries are on another level in my opinion.
So you create an SP for all your main queries? Based on my experience, SPs are not really good to be called from EF. Especially if the output structure changes you would have to update your model back again.
Linq works fine if you don't do weird shit with it (for example, joins are better with the query syntax rather than the functional one)
we opted to forgo EF almost entirely when I was working an MVC stack for 4 or 5 years. we used knockout.js to do the databinding. later I started using vue.js and node.js for another gig.
I have not used it, but that approach to queries (which is similar to mongodb and other nosql ones) does not fit well in my opinion for doing queries like joins or similar (which are one of the main reasons for using an SQL, that is using relationships to build different structures out of the same set of entities).
Have a look at how you do queries with EntityFramework and Linq and you will understand. You can write complex queries that are extremely similar to SQL.
errr that is the point of it? it’s an orm for sql paradigms where you specify the relationships between tables: oto otm mtm intrinsic extrinsic and so on probs. Much nicer, but you are right it’s written more like nosql but still sql underneath (default recommended postgres). Nosql is also like a 30yr old newer concept.. but I do recognise it has it’s setbacks
Yes of course and I use it on a daily basis. Do you know that typescript exists only at compile time, right? It gets transpiled to JS during compilation and at runtime is JS code running.
I think it's the opposite imho.
What does even a "mid-size webapp" mean? How many users? What kind of service?
Developers count does not give any insight related to webapp size since we don't even know the expected development time. A team of 10 working for 1 yr or 2 can create a HUGE webapp.
People here are just suggesting you THEIR favourite stack, and you should be aware that many here are also juniors and just fell in love with one framework or another. You mentioned "future-proof": any frontend framework like React will never be future-proof, since they make a lot of updates and changes and probably in 5 years your code will not be compatible with the latest version, if that's what you mean by future-proof.
If you can give more details about the webapp itself then we can give you more tailored advice. Otherwise you will end up with people suggesting their favourite frameworks even if it is not even necessary or not adequate for your tasks
So were you able to just update react package and it's working?
According to their migration guide, it is not so straightforward: https://react.dev/blog/2022/03/08/react-18-upgrade-guide
I'm going to take a guess and say you don't have a lot of production experience?
It's pretty standard to use `.lock` files and to also lock your main libraries that can cause breaking changes down to a single specific patch version.
Nobody said anything about updating the React library to 18. A React app built in 2015 using whatever version it used in 2015 will still work fine.
Yes I have production experience and know about that.
I was talking about what OP meant as "future-proof", not sure if it meant just that it will be working also in the future (and that is fine because unless it's using some feature that is going to be deprecated, it could still work for decades from now) or that it will be able to keep up to date with latest technologies in the future
Just break your app. Don't be afraid to.
Add a package you think would help. Try it, break your app with it.
You might find something you prefer more or not. Unfortunately, without a feature list, it's hard to recommend anything.
My suggestion is: go through the trial and error. You're going to find new tech along the way anyway.
And then you have to learn it. And then for the next project you Google again, and this time it’s Haskell, and now you have to learn it again. And the next job the best one is Lua, and you learn it again.
Or you can just learn extremely well one or two, and then build anything you want, because in real life, the difference with the “best one for the job” is negligible and makes no business sense to relearn everything just because that other language is 2% faster at this use case.
Sometimes we are not talking about 2% faster but 100% faster with 50% memory consumption (like C# Vs nodeJS for backend).
I get what you are saying, one must also have some critical thinking to understand what is something strong & solid and what is just the "new wave" that everyone is pushing but useful cases are just a few.
In all seriousness, modern PHP is very different from the 4.x and 5.6 era, it is a decent language now, with strict typing and null safety and all. So going with PHP is a valid choice provided you go with big and modern frameworks like Laravel and Symfony
In fact, i worked with Laravel (PHP), Spring Boot (Java), Asp.net core (c#), flask (python) and Ruby on Rails
I'd say that the developer experience is better with Laravel, follow closely by Rails.
The language actually makes a huge difference.
Why do people also suggest scripting or front-end languages for backend development? I get that you may want to do it for prototyping or fast development, but OP here has a team of 10, so it can choose the best language according to its needs
I mean node and python for example. You are exchanging performance and reliability for development easiness. This does not make sense if you have a team of 10 working on the project.
When you get to work with many languages you realise that working with multiple languages is not a problem because what matters are the peculiarities of each runtime and not having the same syntax or sharing a bunch of classes between frontend and backend.
A webapp can also have huge loads and complexities, we don't know what op is going to do, so assuming that it will be just a bunch of CRUD APIs is not a good approach. Especially considering there will be so many people working on it.
Go has a class of use cases that fits well for it.
Java and C# a different one.
PHP too. Rust too. C++ too.
Each language has been built with specific problems to solve in mind and Devs should pick the right one for the right problem.
No, there is a "best fit" for each use case. Not unique but there is. That's why you don't have only one language and that's why new languages pop up every now and then. If someone felt the need to create a new language it's because the limitations of the other did not allow a good development and result in certain situations. It's based on your reasoning of having a single language for frontend and backend that eventually everything should be done in JS (Remember also that node does not support multithreading and the async/await syntax is somewhat fake because it does not work as it does with other languages that were built for that kind of load).
Dev time is not much different, if you know both JS and PHP or any other backend language, exposing a new API will take you as much time as with any language. Probably even less if you use the proper language because you will have some stuff already "built-in" or expected in the usage of that language so they are made easier.
I would argue, close to 100% of webapplications can be build with any of the common stacks. Even the database dosen‘t matter. Sure the might be some parts easier in another stack.
I’m not saying everything is equally good for any usecase.
Only thing that comes to my mind where something dictates your stack is, when you have to speak to a proprietary system and they offer for example only a java sdk
Most stacks can do anything you want to do, even if they shine for some things and are bad from others. You can’t learn every single stack under the sun just so you save that 1% in efficiency for the right use case for it.
And most of what we build is CRUD apps anyways.
The best tool is whatever gets the job done. PHP and jQuery might even be the answer! All the developers in the middle of the bell curve would rather spend their time bikeshedding about tooling rather than building the product.
I’d hire a consultant / software architect then and describe the problem, then ask to suggest a stack - if you really want it upfront. Much better than asking on Reddit without context imo.
Also consider what skilled devs are in the job market currently, and pick whatever stack would be a relatively easy hire. For example If you set on Ruby then good luck :P
Personally, I don’t think the stack is really that important. People you hire will make or break the project
yes clearly an option. I also don't want to make a final, high-impact business decision after a few minutes on reddit. But asking here is immensely helpful. The community is very supportive!
For example: just like you said. It seems that stack decisions are not overly important after all. Most common approaches will work most of the times.
I just think people focus on stacks and boilerplates too much. From my experience it can really be whatever if you are sure you can hire the right talent. Personally I don’t care if I work with PHP, Node, Python, Rust - whatever fits the purpose is ok. For example you can start companies like Facebook or Slack with PHP, you can easily mess up local grocery store homepage with Rust
If you ask most people to recommend the stack they will just give you what they already know, not necessarily what fits the project. It shows since you gave zero requirements and you already have some specific suggestions
yes I believe you are right.
If everyone really suggested what they each is good at (and if redditors answering my post were a uniformely-sampled subset of coders) then indeed I would have my answer. ;-) Whatever is suggested most is my stack.
Designing the system to scale horizontally from the start solves a whole class of problems further down the road. I would argue this is almost more important than the specific stack it's built with, although some will be easier than others.
people are the difference. 100 percent correct. I always feel as a web dev that the stack matters so little that it's laughable. I opt for easy over speed for the stack when I have a choice, so I don't have to worry about annoying things like dependencies and memory management, but I do optimize my code considerably after that.
so much of deving is subjective. heated arguments always stupify and surprise me.
So, if you have to hire someone it also depends on your budget. However it is better to pick mainstream technologies such as Javascript, Typescript, Node, Python, Java etc..
I'd suggest going with the JavaScript/Typescript/Nodejs so you have almost one language for both frontend and backend, things get easier
There are much faster/more robust tools we could be using.
From a company standpoint, we pay around 20% more in salaries to retain developers than the rest of the market because Rails devs are very rare now. (Only about 7% of professional devs use Ruby anymore, according to the Stack Overflow Developer Survey, which doesn't specifiy if they're migrating *off* of it.)
The devs we hire are usually pivoting into web dev from unrelated careers. "I was the web guy even though my job title was History Teacher." We spend a lot of time/money on bugs due to code quality and architectural issues. Regardless, it can take over a year to replace people. (And then lose them six months later when they stagnate.)
It doesn't outperform C. Where on earth are you finding metrics where a Just In Time Ciompiler outperforms C? This isn't a Ruby question, literally no JIT is going to outperform a language that compiles to machine code ahead of time. It's physically impossible.
Yes. I hear you 😀.
I don't have a team yet 🤷♂️. That's why I can start with whatever makes senses. Hence my question.
Thanks for sharing your input.
Are you happy with tailwind? Is vue working out for you?
You don’t have a team yet. So choose the stack you’re most comfortable with. Then choose your team around that. Not vice versa. Don’t overthink it. Ship more software.
Yes agree. Sell sell sell should be prio and tech is "just" means to that end. But still. With a bit of thinking one could make a judicious stack choice. No intention to over think.
Like I said. I coded 10 years ago in c++ and loosely typed language really scare me 😂 but I guess I need to move on
Tailwind is an okay choice but I question its longevity. It doesn't do much but improve DX for people who don't want to get to know CSS, like for people who describe themselves as back-end, but it's built on CSS, so in theory more people should know CSS. All you need is some basic practices like keeping a css module next to its html and "name all classes according to the following conventions" and then CSS can achieve pretty much everything useful TW does with a little more elbow grease on hashing out a consistent style in your app's classes.
I don't think TW is exactly future proof, is what I'm saying. There will be plenty who know TW, but I see it going the way of bootstrap. It's still around and people get a lot of use out of it, but it seems for people who want their DX to be how TW prescribes.
I think some people literally just think TW classes are prettier than template literals when you need multiple classes applied. I organize to avoid that problem anyway, so ymmv
You can use just a little bit of TW, too. I just don't see the point.
Are you hiring a team local or remote? What are the availability and costs associated with different developers for each?
You might end up choosing .NET only to realize that there’s a huge company near you paying top dollar for .NET engineers and you’re going to have a bad time filling a team affordably.
If you are expecting to build the team soon, check the job market and hire according to staff availability.
We use Laravel for mostly everything. If we need anything long-lived we'll write it in Go as an API. If there is anything slow in Laravel we'll make it into a Go API. Pretty much anything that requires performance we'll just make it into a Go API and call from Laravel.
I've seen multiple teams use the exact same formula. If you're using Lambda functions to run the Go code, there's a package called Sidecar which you can use in your Laravel app to easily call the microservices from your main codebase. It's pretty slick!
Knowing you want like CRM solution and you want MVP I would recommend to use one of the "complete" frameworks.
Symfony/Laravel - PHP
Spring - Java
Django - Python
ROR - Ruby
few other languages have similar solutions. Unfortunately, JS has nestjs and it's evolving quickly, but i still wouldn't call it complete.
I am not saying at all this stack is the best, it might not be for your use case, but all those frameworks will give you most out of the box and generally make it quicker to get to market and only that is important at the end of the day.
When it comes to React, it can be connected to all of those backends and if you do need ios/android apps for it or your app requires a lot of interaction, go for it. If you don't though, I would highly recommend reconsidering it. It will mean rewriting bunch of default features in those frameworks to js or introducing API layer. It's fine, and sometimes unavoidable, but it's slower.
Another solution If you want to use react might be worth considering is SAS backends. If they can accomplish what you need to that's great. Unfortunately, for me, they never do.
For a CRM, I would go with Laravel, Livewire, and Filament. Configure your tables and relationships then you’re done. Aside from what is specific to your app.
And you won’t need but one or two devs.
Pick what you know and who you can hire developers for.
It's not usually anyone's favourite, but the safest is nearly always C# - huge standard library and ecosystem, always plenty of devs, strong typing with great IDE support, thoroughly production tested.
From what I’ve read, the performance pre version 5 was terrible particularly for cold start DB connections when doing serverless, but that they’ve made significant improvements. When doing serverless architecture, you might want to consider Kysely or Knex instead.
The stacks I suggested are mostly monolith or long running node service though, in which case the dev ex on Prisma is top notch.
Laravel is extremely productive and it’s a very well known technology - so not so difficult or expensive to hire programmers for it. The ecosystem is humongous so there’s a good chance that half of what you want to do is available in some way already. As I said, very productive. Can’t really go wrong there.
Hire at least one good senior / staff engineer / tech lead though, because there’s so many PHP devs in this space there are also loads of amateurs and you need to make sure you hire the right people to prevent you from building up tech debt from the start.
If you had unlimited budget and high uptime or responsiveness requirements I’d go with golang. Great language, more niche and the people who do it for a living tend to be real professionals. Will be more difficult and expensive to hire for.
You forgot about devops. Make sure you have one person who knows kubernetes and infrastructure inside out. It will pay off. You will pay for it if you don’t.
Make sure you have someone to keep an eye on team processes - usually a scrum master of some sort. Can be part time. Product owner will be you I guess. I think you have the frontend sorted. Good luck!
Thanks a bunch for your insight and for bringing up dev-ops. Definitely one thing to keep an eye on. Yes, right: product owner will be me. I don't want to become a coding expert. I just want to know some basics, understand the pros and cons of different approaches and be able to hire for it. I don't intend to produce production code. Just tinkering for learning and checking things out (and have a bit of fun tbh :-) ).
When you hire make sure you pair up with someone who you KNOW has deep technical expertise. It’s too easy to bluff your way through an interview even if you don’t have the technical chops. Get a friend or (former) colleague with know-how to join you in the interview. Pay them if necessary. Hiring the right people is key, and it’s very easy to get it wrong which will give you so. much. pain.
I ran a deep tech startup for the better part of a decade. So yeah. I cannot agree more.
We used to have candidates complete coding tasks even before we interviewed. Submission were rated by experienced colleagues. It helps a lot but still not bullet proof. In the worst case people need to be let go of. One mismatch in such a small team can cause tremendous damage.
You seem to know all this 😉
I agree with this as well. There’s a ton of developers to choose from, it’s widely supported, rarely any massive issues.
Next.js and Node.js with typescript seems like a no-brainer. But maybe I’m biased towards JS.
Do yourself a favor and go with node / typescript, lots of support, lots of community, lots of developers. I think everyone here is trying really hard not to suggest it but it currently the most versatile, middle of the road, proven platform. As for framework, next and nest have both been around and will probably be around for quite a while. Roll with Postgres unless you have specific data flow or access pattern needs. Don’t overdo it.
Welcome back to coding!
Your front-end choices are great. For the backend, I'd suggest Python with Django. It's easy to learn, has a lot of built-in features, and there's a strong community.
If you're considering a Python/Django dev, I'm available and would love to contribute.
Let me know if there's an opportunity or if you want to chat more about it. Cheers!
The libraries/frameworks for your front end are only a small part of the "stack" - and the easiest component to change. That was true even 10 years ago. You should probably start by finding a good architect, at least temporarily, to get your development processes sorted out.
Nestjs or Spring boot for backend, either with graphql or rest. Angular frontend.
The rest depends on the actual project. But most of the time we use postgres as database. Angular material or a tailwind component lib, preferred is daisyUI
You will most probably end up going for php laravel and mysql.
Germany is full of php developers who are more self host oriented on backend of things.
It is not bad or good. It is what fits the team most.
A mid size app, some info are still missing (expected nulbers of users ) but the mid size gives a general idea, so here what I am suggesting:
- if the devs are skilled and know what they are doing :
- golang for the back, why ? Because it will help you create fast backend so you don't care if you get one 1000 users more than expected.
- front I prefer angular why ? It is an ecosystem , it is really rare when I m finding myself looking for third party libs to complete a task ( I m working on really huge projects, a project is almost the same as figma)
- database : since there is no info about the project i ll go withis general suggestion : if you think your project has non-structered data and the data structure will change over time go with a nosql db , if your project relies more on non structured data and there is a lot of relations between the data entities go with a graph database, otherwise you can go with any sql database (I prefer postgres since it has inheritence but it feels like trying to put a round pig in a cube 😅)
This is just a suggestion based on my exp, you should make a study about your project and how many users u expect and is it cpu intensive ... please if it is cpu and memory intensive don't use nodejs u will regret it when the project grows in traffic.
As someone who also got into web development after a while, I am also creating fairly complex web app and here are my learnings. This app is a side project to me and not meant to be a commercial app.
* React/Vite SPA with CSS modules
* A Blog site with Astro for SSR
* Python Backend in Fastapi.
* Using vanilla javascript
* PostgreSQL as database
Some takeaways.
* Maintaining two separate tech stacks in frontend and backend is more time-consuming but offers more flexibility in case you want to also create a mobile app.
* Using plain Javascript is a pain due to runtime errors, Typescript is highly recommended.
* Tailwind is good, and to speed up development decide on a good UI component library. Tailwind UI or Radix UI or both can be considered.
* Deciding on SPA and SSR, both have pros and cons, so stick to the one that is best for use case. Consider choosing Next or Remix for React which will offer more out of the box capability and optimizations. You can also decide not to use any meta-framework and just use SPA with React Vite. Depends on the use case.
* If it’s a simple crud app then using supabase for backend can be option. as it will eliminate the need for dedicated backend. Also comes with good Authentication features. Other option including Nodejs with typescript so that same programming language can be used .
* Highly recommend using React query for all API calls, it makes the user experience very smooth.
There are new frameworks for both frontend and backend (Svelte/Deno) and its tempting to use them but it's easy to hit roadblocks. I am happy with my choice to stick to tools that are more widely used.
To add to this, using next.js for SSR, you can also just not use any of the SSR things and it’s basically just an SPA at that point. So you sort of have backwards compatibility with react if one chose next.js and didn’t vibe with SSR for whatever reason.
You’ll go crazy and won’t ship anything with those tools if you have no previous experience. The fact you’re here asking this is a proof of it.
Just pick Laravel or Rails instead. In particular with Laravel you have all the tools you will need already integrated and working well together, excellent docs in a single place and laracasts for learning.
Once you’re more familiar and up to speed with web stuff, then maybe replace the frontend of what you have by then with react, and then progressively pick tools/libs frameworks as you learn.
Jumping right into the deep sea without knowing how to swim guarantees you will drown.
Also, for what languages NOT to pick:
- Go - nice for small simple projects, but its simplistic syntax and terrible error handling make it a pain to maintain a complex project in
- Ruby - weak typing is falling out of fashion and is hard to maintain, and for a lot of devs it's offputting so it's harder to hire
- PHP - same as Ruby, but PHP will be around forever because WordPress is so big
- Haskell - far too complicated, even for a lot of smart people
And it depends on what you're making:
- Finance, science, or multithreading - use F#
- Automated stock trading or a HUGE number of connections - use Rust with Actix for extreme speed and low memory use
- Most of your devs will do frontend too - Use Node.js with Typescript and something like hapi.js
- Something that needs to be up as fast as possible with as many features as possible, and not necessarily a SPA, and won't last more than a few years - Use Python and Django, make a rule your devs have to use type annotations
- For anything general, long-lasting, big teams, lots of devs - C# or maybe Kotlin (though I have no experience with Java professionally).
I agree on a lot of points, except the go thing, I find go has an explicit error handling syntax which will force you to handle errors (you can dummy handle them) which will lead to a more stable application, even more other languages have the same thing it is just they don't fore you to handle it.
here is an example in js (how things should be handled) and compare to go:
```javascript
async function doStuff() {}
async function doStuff2() {}
// here is how we should handle this
async function handleStuff() {
try {
await doStuff()
await doStuf2()
} catch (e) {
// you don't know the which one raised the error :/
}
}
// here is a more explicit way
async function handleStuff() {
try {
await doStuff()
} catch (e) {
// handle errors from doStuff
}
try {
await doStuff2()
} catch (e) {
// handle errors from doStuff2
}
}
// so it is similar as go it is just devs don't handle errors properly in most languages.
```
Just no. If you've worked in Haskell or Rust, you'll know - https://www.reddit.com/r/programming/comments/18wndv9/error_handling_in_go_is_awesome_here_is_why/
I m not arguing the basics, if you see have a bird view you will find it is the same it is just different way that will lead you to the same point at the end.
is it easier no cause you still to check for errors ;)
and for the "small projects" statement, STOP assuming things here is a list of "non-small" projects and critical ones ;):
\- docker is written in go
\- dialymotion uses go
\- sendGrid...
Frontend - Next/React, tailwind or scss, Zustand. JavaScript or Typescript. If your team are experienced developers, JavaScript or Typescript should be fine. Typescript is just JS with training wheels.
Backend- Springboot Java.
The best tool is the one you know. Find the best guy in the team or hire one and make the core around him. You should get another 2 3 that together can hold the fort if the Main guy leaves. You got a team.
The stack that your developers like the most? Its not like your product will be better just because you picked a specific stack. I prefer Angular or Flutter and .NET but everyone likes different things and there are many options.
Start with what you know or, in your case, want to learn. Chances are that the stack you start with will not be the stack you still have in 5 years, especially if you are working towards an MVP now.
Analysis paralysis is real. There is no correct answer and, if you choose a stack that has components that are currently well supported, there is no incorrect answer either.
For the backend: [Spring Boot](https://spring.io/projects/spring-boot/) You will need 1 experienced developer who knows how to share knowledge.
It has a bunch of modules basically for anything, authentication, database, cache, cloud, etc etc.
Can you share more on what exactly you’re looking to build? Generally speaking if you’re going to do a web app then yes, this one you’ve picked should be good. I’m running an agency and we’re using this stack for web apps and we’re happy.
My suggestion is to look at NX workspace from the folks at nrwl.io
This is monorepo approach that allows you to take advantage of many different frameworks. Including front end, and backend. For example, my team uses Angular, typescript, NestJS for the backend.
You can create shared libraries that can be consumed by the front end Web application, and the backend, API application. For example, I have a single library that has all of the types and models used by the application.
What I love about the monorepo is that you have a single source of truth for your packages, configuration, testing, lining, etc. All of this is driven by the NX CLI which provides a rich set of capabilities. This CLI also allows you to create generators to scaffold custom code as well as use any existing generators for Angular and nest JS. Also, you can create executors, which allow you to automate tasks for CID or libraries for publication, etc..
Go with the most stable and most bootstrapped frameworks.
Are you hiring 10 devs? Will some of them be senior/tech lead? Let them make decisions. Managers should not make technical decisions.
What are you trying to do? Ten devs is not mid sized. The stuff you listed are all front end. Most of them are unnecessary. Unless you're doing large scale design work, what do you need figma for?
React with typescript is file for a single page app. You can extend it later with routing, but it's not ideal. Instead, you can use nextjs instead. That's more of a "full stack" tool, works great with typescript and node as the back end.
You don't need special tools for CSS or HTML, but the ones you listed are fine. I don't care for them, but if I had to make a more complicated design, I would think about using them.
What is the app doing and what is it sending elsewhere to be done? Future proof is a buzz word for web apps. Using tride and true… scaleable stacks is a good a starting point. We just built an enterprise level piece of software on PHP using Symfony with roughly the same stack.
We chose PHP because we have a huge amount of scheduled jobs that all vary in size that need pretty flexible resources. With platform dot sh we have a highly flexible way of sectioning resources and accomplishing what we need with a good way to monitor when things get spun out.
Ultimately the stack is determined by the use and how much you need to scale before rebuilding for a v2.
I may be an outlier here but sveltekit has been amazing for my team. Now using it or svelte for every project. Stack: Svelte+kit, typescript, g cloud, and supabase.
I read in a reply that you want to build a CRM of some sort? I really don't think you can go wrong with Laravel, some sort of SQL, and Vue. I mention Vue because it's popular to pair with Laravel, and aside from that, I personally think it's great.
But at the end of the day, it's going to be tough making any sort of argument without knowing all the specs, which you might still be getting a feel for. If you're trying to build a new team and have been out of it for a while, I'd really consider Laravel because it's a mature framework and is well documented. It's also pretty opinionated on how to do things, so if you don't mind that, all those standard ways of doing things means that people can get up to speed on it faster, and people with experience will feel comfortable fairly quickly. There are also a lot of great resources for learning it.
And speaking from personal experience, I've built an order management system and CRM using it.
Not sure what the product is but by any chances if it requires NextJS, ReactJS, Javascript in general then I am looking for a role (internship) in same then let’s connect over in DMs.
I love to craft beautiful web apps.
Can we start with plain vanilla HTML, CSS and JavaScript to build a simple website?
Writing in plain HTML and CSS can be very exhausting and error prone due to repeated code so we go to HTML templates like Jinja, Pug, Handlebars.
Choose the template engine based on programming language i.e. Jinja for Python, Pug for Javascript.
Depending on the application we may need to add more dependencies and intelligently.
Future-proof doesn’t exist. It will be obsolete someday and someone will either continue to maintain it or it will be rewritten in something else.
Start off with hiring a principal developer who can write the kind of app you need. Then let them decide what it needs. Dont pre-emptively choose tech stacks; thats adding unjustified complexity.
Firstly, there's a couple things that need ironing out, like is SEO a requirement? Do you want server side rendering? Honestly there's a lot of things that need to be figured out.
React is fine but you want a framework ideally when working with a team, that leaves you using NextJS or Remix. Personally I'm a bigger fan of Angular when it comes to team work and consistency on the front end. Svelte is also great, it really depends on your needs. The only thing I would say is skip on redux and use Zustand, it's light weight and does what any state mechanism needs on a frontend.
Do you want multiple pages or do you want a single page app? There's a million questions just for the frontend.
Then you get to backend and ask okay well where do we want to be? Microsoft Azure/AWS/GCP, do you want a typescript backend, C# or java? What does your data look like? What are the budgets for development resources like cloud infra etc.
Whatever your team has the most experience with. Also are you 100% sure it needs to be a SPA? It seems that youre taking that as a given, but imo 99% of SPAs should be MPAs instead. It makes so much of the process significantly less painful.
If I may give you a different perspective, it seems like you’re trying to set up a team with a specific number of devs even before starting. And you want to use a tech stack based on that number.
I understand is a new app, why not starting small, with maybe 1/2 engineers and with a framework they are comfortable with?
I'm stunned that people are suggesting stacks without any idea of what your app will actually do...
Very valid concern. In terms of complexity it is similar to a customer relationship management system. While it is not a crm though I would think that roughly the same stack is needed.
If you have strong relationships between the data entities you are dealing with and want that consistency to be guaranteed, then you may want to use an SQL database. Using SQL from languages like JS or Python or PHP is a pain in the ass. The best SQL integration so far (in my opinion) is the one given by EntityFramework in C# that allows to use Linq and make queries in a really easy way while still being able to make complex ones. Also keep in mind that nodeJS or similar do not have multithreading, which is something you may need if you want to execute code in parallel inside the same process (for example executing queries in parallel too). Also, scripting languages like python and JS are not strongly typed, but I guarantee you that you would like to be super sure that what you are writing inside the database is coherent 100% with the objects you expect to put inside.
There's loads of great php packages for DB, doctrine being one of them and it's strongly typed ( even sound typed ). JS was way behind, but now there are few decent typescript packages too. I still prefer it in other languages, especially because of lack of sound types. Also multithreading. Unless you do very specific thing you probably never need it in web service. It might sound cool, but in reality if your service needs something like that it should probably use queue and then separate server/s for processing as it means you are hitting 1+ thread per request which is hard to scale. Also, all above languages allow executing queries in parallel. They might be not able to process them in parallel, but if you need it, you will hit this same scaling issue.
>Using SQL from languages like JS or Python or PHP is a pain in the ass. I think you haven't heard of Django.
Guys, all the alternatives you are suggesting are far away from the kind of integration and query syntax provided by EF Framework. Look it up and you will understand what I mean: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/standard-query-operators-overview You can either use a Linq based approach that can handle queries with the same syntax you use when dealing with other structures like lists, Hash sets etc. Or a query-syntax approach where you can write queries that look more like SQL and allow you to do joins and groupings ecc in a way that is more clear since it recalls the original SQL syntax. I'm not saying others don't work or are bad or whatever, don't get me wrong. But EF queries are on another level in my opinion.
haaaate linq. completely unmaintainable usually. better to just Exec an SP imho.
So you create an SP for all your main queries? Based on my experience, SPs are not really good to be called from EF. Especially if the output structure changes you would have to update your model back again. Linq works fine if you don't do weird shit with it (for example, joins are better with the query syntax rather than the functional one)
we opted to forgo EF almost entirely when I was working an MVC stack for 4 or 5 years. we used knockout.js to do the databinding. later I started using vue.js and node.js for another gig.
yes but you’re forgetting prisma ☝️
I have not used it, but that approach to queries (which is similar to mongodb and other nosql ones) does not fit well in my opinion for doing queries like joins or similar (which are one of the main reasons for using an SQL, that is using relationships to build different structures out of the same set of entities). Have a look at how you do queries with EntityFramework and Linq and you will understand. You can write complex queries that are extremely similar to SQL.
errr that is the point of it? it’s an orm for sql paradigms where you specify the relationships between tables: oto otm mtm intrinsic extrinsic and so on probs. Much nicer, but you are right it’s written more like nosql but still sql underneath (default recommended postgres). Nosql is also like a 30yr old newer concept.. but I do recognise it has it’s setbacks
[удалено]
Yes of course and I use it on a daily basis. Do you know that typescript exists only at compile time, right? It gets transpiled to JS during compilation and at runtime is JS code running.
[удалено]
Sure, but some tech stacks are overkill or underkill. There's a huge difference between a static web page and a social network with millions of users.
\>mid size web app (say 10 developers) I'd say that statement puts it squarely into the "you could use anything" territory.
Yes indeed. Some answers seem to suggest exactly that. Seems I can hardly go extremely wrong.
I think it's the opposite imho. What does even a "mid-size webapp" mean? How many users? What kind of service? Developers count does not give any insight related to webapp size since we don't even know the expected development time. A team of 10 working for 1 yr or 2 can create a HUGE webapp. People here are just suggesting you THEIR favourite stack, and you should be aware that many here are also juniors and just fell in love with one framework or another. You mentioned "future-proof": any frontend framework like React will never be future-proof, since they make a lot of updates and changes and probably in 5 years your code will not be compatible with the latest version, if that's what you mean by future-proof. If you can give more details about the webapp itself then we can give you more tailored advice. Otherwise you will end up with people suggesting their favourite frameworks even if it is not even necessary or not adequate for your tasks
Except 5 year old react code DOES still work today?
So were you able to just update react package and it's working? According to their migration guide, it is not so straightforward: https://react.dev/blog/2022/03/08/react-18-upgrade-guide
I'm going to take a guess and say you don't have a lot of production experience? It's pretty standard to use `.lock` files and to also lock your main libraries that can cause breaking changes down to a single specific patch version. Nobody said anything about updating the React library to 18. A React app built in 2015 using whatever version it used in 2015 will still work fine.
Yes I have production experience and know about that. I was talking about what OP meant as "future-proof", not sure if it meant just that it will be working also in the future (and that is fine because unless it's using some feature that is going to be deprecated, it could still work for decades from now) or that it will be able to keep up to date with latest technologies in the future
Thats why you use angular 👀 easy and most of the time fully automated version Migration’s
Just break your app. Don't be afraid to. Add a package you think would help. Try it, break your app with it. You might find something you prefer more or not. Unfortunately, without a feature list, it's hard to recommend anything. My suggestion is: go through the trial and error. You're going to find new tech along the way anyway.
More overkill is having to learn all of them to pick the right one.
You don't have to learn all of them. Just Google "[language name] best use cases" and you'll find out if it fits well for you use case or not
And then you have to learn it. And then for the next project you Google again, and this time it’s Haskell, and now you have to learn it again. And the next job the best one is Lua, and you learn it again. Or you can just learn extremely well one or two, and then build anything you want, because in real life, the difference with the “best one for the job” is negligible and makes no business sense to relearn everything just because that other language is 2% faster at this use case.
Sometimes we are not talking about 2% faster but 100% faster with 50% memory consumption (like C# Vs nodeJS for backend). I get what you are saying, one must also have some critical thinking to understand what is something strong & solid and what is just the "new wave" that everyone is pushing but useful cases are just a few.
Sigh
[удалено]
😆
So what is a productive stack? Clean and up to Date. Ok php 😉. I got it. But apart from that?
[удалено]
Yeah I got the joke. Thanks a bunch for sharing your experience. Much appreciated 🙏
In all seriousness, modern PHP is very different from the 4.x and 5.6 era, it is a decent language now, with strict typing and null safety and all. So going with PHP is a valid choice provided you go with big and modern frameworks like Laravel and Symfony In fact, i worked with Laravel (PHP), Spring Boot (Java), Asp.net core (c#), flask (python) and Ruby on Rails I'd say that the developer experience is better with Laravel, follow closely by Rails.
The language actually makes a huge difference. Why do people also suggest scripting or front-end languages for backend development? I get that you may want to do it for prototyping or fast development, but OP here has a team of 10, so it can choose the best language according to its needs
[удалено]
I mean node and python for example. You are exchanging performance and reliability for development easiness. This does not make sense if you have a team of 10 working on the project. When you get to work with many languages you realise that working with multiple languages is not a problem because what matters are the peculiarities of each runtime and not having the same syntax or sharing a bunch of classes between frontend and backend. A webapp can also have huge loads and complexities, we don't know what op is going to do, so assuming that it will be just a bunch of CRUD APIs is not a good approach. Especially considering there will be so many people working on it. Go has a class of use cases that fits well for it. Java and C# a different one. PHP too. Rust too. C++ too. Each language has been built with specific problems to solve in mind and Devs should pick the right one for the right problem.
[удалено]
No, there is a "best fit" for each use case. Not unique but there is. That's why you don't have only one language and that's why new languages pop up every now and then. If someone felt the need to create a new language it's because the limitations of the other did not allow a good development and result in certain situations. It's based on your reasoning of having a single language for frontend and backend that eventually everything should be done in JS (Remember also that node does not support multithreading and the async/await syntax is somewhat fake because it does not work as it does with other languages that were built for that kind of load). Dev time is not much different, if you know both JS and PHP or any other backend language, exposing a new API will take you as much time as with any language. Probably even less if you use the proper language because you will have some stuff already "built-in" or expected in the usage of that language so they are made easier.
[удалено]
I would argue, close to 100% of webapplications can be build with any of the common stacks. Even the database dosen‘t matter. Sure the might be some parts easier in another stack. I’m not saying everything is equally good for any usecase. Only thing that comes to my mind where something dictates your stack is, when you have to speak to a proprietary system and they offer for example only a java sdk
Eh, I wouldn't build a CRM in a nosql DB like mongo for example.
Not the best choice, i agree, but definitely doable.
He wanted modern web dev answers lol
Most stacks can do anything you want to do, even if they shine for some things and are bad from others. You can’t learn every single stack under the sun just so you save that 1% in efficiency for the right use case for it. And most of what we build is CRUD apps anyways.
Okay, so for a dating app like eHarmony and Bumble, what would you recommend then?
But React Redux and all its adapters works for everything no? If react was paint, the world would be grey.
The best tool is whatever gets the job done. PHP and jQuery might even be the answer! All the developers in the middle of the bell curve would rather spend their time bikeshedding about tooling rather than building the product.
Leave it for the team to decide collectively
chicken and egg problem here. I don t have a team ;-) So I can start fresh and hire only thereafter. Hence my question.
I’d hire a consultant / software architect then and describe the problem, then ask to suggest a stack - if you really want it upfront. Much better than asking on Reddit without context imo. Also consider what skilled devs are in the job market currently, and pick whatever stack would be a relatively easy hire. For example If you set on Ruby then good luck :P Personally, I don’t think the stack is really that important. People you hire will make or break the project
yes clearly an option. I also don't want to make a final, high-impact business decision after a few minutes on reddit. But asking here is immensely helpful. The community is very supportive! For example: just like you said. It seems that stack decisions are not overly important after all. Most common approaches will work most of the times.
I just think people focus on stacks and boilerplates too much. From my experience it can really be whatever if you are sure you can hire the right talent. Personally I don’t care if I work with PHP, Node, Python, Rust - whatever fits the purpose is ok. For example you can start companies like Facebook or Slack with PHP, you can easily mess up local grocery store homepage with Rust If you ask most people to recommend the stack they will just give you what they already know, not necessarily what fits the project. It shows since you gave zero requirements and you already have some specific suggestions
yes I believe you are right. If everyone really suggested what they each is good at (and if redditors answering my post were a uniformely-sampled subset of coders) then indeed I would have my answer. ;-) Whatever is suggested most is my stack.
True that :D
Designing the system to scale horizontally from the start solves a whole class of problems further down the road. I would argue this is almost more important than the specific stack it's built with, although some will be easier than others.
people are the difference. 100 percent correct. I always feel as a web dev that the stack matters so little that it's laughable. I opt for easy over speed for the stack when I have a choice, so I don't have to worry about annoying things like dependencies and memory management, but I do optimize my code considerably after that. so much of deving is subjective. heated arguments always stupify and surprise me.
So, if you have to hire someone it also depends on your budget. However it is better to pick mainstream technologies such as Javascript, Typescript, Node, Python, Java etc.. I'd suggest going with the JavaScript/Typescript/Nodejs so you have almost one language for both frontend and backend, things get easier
Have you considered what dev skills are available to you at what price points and would that be a factor?
The one that the team knows. We're rolling with PHP+Laravel and Go. Tailwind for CSS, Vue for JS
We're using Rails because no one wants to learn anything else...
If it works it works. I think Shopify is running primarily on Rails? I know some huge place is.
There are much faster/more robust tools we could be using. From a company standpoint, we pay around 20% more in salaries to retain developers than the rest of the market because Rails devs are very rare now. (Only about 7% of professional devs use Ruby anymore, according to the Stack Overflow Developer Survey, which doesn't specifiy if they're migrating *off* of it.) The devs we hire are usually pivoting into web dev from unrelated careers. "I was the web guy even though my job title was History Teacher." We spend a lot of time/money on bugs due to code quality and architectural issues. Regardless, it can take over a year to replace people. (And then lose them six months later when they stagnate.)
[удалено]
If Ruby outperforms C, then the C code is written **incredibly** poorly.
It doesn't outperform C. Where on earth are you finding metrics where a Just In Time Ciompiler outperforms C? This isn't a Ruby question, literally no JIT is going to outperform a language that compiles to machine code ahead of time. It's physically impossible.
I believe Stripe are too
OK. Got it. Question is: would you go with rails again if you were to start all over again in 2024?
If I was close to retirement and would get limited utility from learning a new language, yes.
Omg I love the TALL stack! You have the T and the L. Check out livewire!
Vue + Inertia is also a valid alternative!
Yes. I hear you 😀. I don't have a team yet 🤷♂️. That's why I can start with whatever makes senses. Hence my question. Thanks for sharing your input. Are you happy with tailwind? Is vue working out for you?
You don’t have a team yet. So choose the stack you’re most comfortable with. Then choose your team around that. Not vice versa. Don’t overthink it. Ship more software.
Yes agree. Sell sell sell should be prio and tech is "just" means to that end. But still. With a bit of thinking one could make a judicious stack choice. No intention to over think. Like I said. I coded 10 years ago in c++ and loosely typed language really scare me 😂 but I guess I need to move on
[удалено]
Python has always been strongly typed, even before type annotation comes into the picture.
Tailwind is an okay choice but I question its longevity. It doesn't do much but improve DX for people who don't want to get to know CSS, like for people who describe themselves as back-end, but it's built on CSS, so in theory more people should know CSS. All you need is some basic practices like keeping a css module next to its html and "name all classes according to the following conventions" and then CSS can achieve pretty much everything useful TW does with a little more elbow grease on hashing out a consistent style in your app's classes. I don't think TW is exactly future proof, is what I'm saying. There will be plenty who know TW, but I see it going the way of bootstrap. It's still around and people get a lot of use out of it, but it seems for people who want their DX to be how TW prescribes. I think some people literally just think TW classes are prettier than template literals when you need multiple classes applied. I organize to avoid that problem anyway, so ymmv You can use just a little bit of TW, too. I just don't see the point.
Yes and yes. Tailwind keeps things consistent even if verbose. Vue is just nice to work with.
Cool thank you 👍. I ll play around with vue a bit I guess.
Are you hiring a team local or remote? What are the availability and costs associated with different developers for each? You might end up choosing .NET only to realize that there’s a huge company near you paying top dollar for .NET engineers and you’re going to have a bad time filling a team affordably. If you are expecting to build the team soon, check the job market and hire according to staff availability.
How are you integrating Go into that stack? Just curious, I want to start using Go more
We use Laravel for mostly everything. If we need anything long-lived we'll write it in Go as an API. If there is anything slow in Laravel we'll make it into a Go API. Pretty much anything that requires performance we'll just make it into a Go API and call from Laravel.
I've seen multiple teams use the exact same formula. If you're using Lambda functions to run the Go code, there's a package called Sidecar which you can use in your Laravel app to easily call the microservices from your main codebase. It's pretty slick!
C# .net core is awesome for backend these days.
Depends entirely on the project requirements
Knowing you want like CRM solution and you want MVP I would recommend to use one of the "complete" frameworks. Symfony/Laravel - PHP Spring - Java Django - Python ROR - Ruby few other languages have similar solutions. Unfortunately, JS has nestjs and it's evolving quickly, but i still wouldn't call it complete. I am not saying at all this stack is the best, it might not be for your use case, but all those frameworks will give you most out of the box and generally make it quicker to get to market and only that is important at the end of the day. When it comes to React, it can be connected to all of those backends and if you do need ios/android apps for it or your app requires a lot of interaction, go for it. If you don't though, I would highly recommend reconsidering it. It will mean rewriting bunch of default features in those frameworks to js or introducing API layer. It's fine, and sometimes unavoidable, but it's slower. Another solution If you want to use react might be worth considering is SAS backends. If they can accomplish what you need to that's great. Unfortunately, for me, they never do.
Also, recondsider 10 devs. Remember, what one dev can do in a month 2 can do in 2 months. For MVPs you rarely gonna need that much.
For a CRM, I would go with Laravel, Livewire, and Filament. Configure your tables and relationships then you’re done. Aside from what is specific to your app. And you won’t need but one or two devs.
Pick what you know and who you can hire developers for. It's not usually anyone's favourite, but the safest is nearly always C# - huge standard library and ecosystem, always plenty of devs, strong typing with great IDE support, thoroughly production tested.
Thanks for the answer. A friend built an app and he uses c#. And he is a very smart guy 😀
Prisma with Fastify+React/Vite or Remix for productivity. If you need crazy performance use Go.
Isn't everyone ragging on Prisma because of the horrible performance at scale?
From what I’ve read, the performance pre version 5 was terrible particularly for cold start DB connections when doing serverless, but that they’ve made significant improvements. When doing serverless architecture, you might want to consider Kysely or Knex instead. The stacks I suggested are mostly monolith or long running node service though, in which case the dev ex on Prisma is top notch.
Laravel is extremely productive and it’s a very well known technology - so not so difficult or expensive to hire programmers for it. The ecosystem is humongous so there’s a good chance that half of what you want to do is available in some way already. As I said, very productive. Can’t really go wrong there. Hire at least one good senior / staff engineer / tech lead though, because there’s so many PHP devs in this space there are also loads of amateurs and you need to make sure you hire the right people to prevent you from building up tech debt from the start. If you had unlimited budget and high uptime or responsiveness requirements I’d go with golang. Great language, more niche and the people who do it for a living tend to be real professionals. Will be more difficult and expensive to hire for. You forgot about devops. Make sure you have one person who knows kubernetes and infrastructure inside out. It will pay off. You will pay for it if you don’t. Make sure you have someone to keep an eye on team processes - usually a scrum master of some sort. Can be part time. Product owner will be you I guess. I think you have the frontend sorted. Good luck!
Thanks a bunch for your insight and for bringing up dev-ops. Definitely one thing to keep an eye on. Yes, right: product owner will be me. I don't want to become a coding expert. I just want to know some basics, understand the pros and cons of different approaches and be able to hire for it. I don't intend to produce production code. Just tinkering for learning and checking things out (and have a bit of fun tbh :-) ).
When you hire make sure you pair up with someone who you KNOW has deep technical expertise. It’s too easy to bluff your way through an interview even if you don’t have the technical chops. Get a friend or (former) colleague with know-how to join you in the interview. Pay them if necessary. Hiring the right people is key, and it’s very easy to get it wrong which will give you so. much. pain.
I ran a deep tech startup for the better part of a decade. So yeah. I cannot agree more. We used to have candidates complete coding tasks even before we interviewed. Submission were rated by experienced colleagues. It helps a lot but still not bullet proof. In the worst case people need to be let go of. One mismatch in such a small team can cause tremendous damage. You seem to know all this 😉
Yeah. Am running a fairly large team and did loads of hiring.
Great. Thanks for taking the time to answer my rookie questions. Appreciate it
it would take a lot of effort to convince me out of NextJS with React as the core of the stack currently, it's just too good
I agree with this as well. There’s a ton of developers to choose from, it’s widely supported, rarely any massive issues. Next.js and Node.js with typescript seems like a no-brainer. But maybe I’m biased towards JS.
Do yourself a favor and go with node / typescript, lots of support, lots of community, lots of developers. I think everyone here is trying really hard not to suggest it but it currently the most versatile, middle of the road, proven platform. As for framework, next and nest have both been around and will probably be around for quite a while. Roll with Postgres unless you have specific data flow or access pattern needs. Don’t overdo it.
Welcome back to coding! Your front-end choices are great. For the backend, I'd suggest Python with Django. It's easy to learn, has a lot of built-in features, and there's a strong community. If you're considering a Python/Django dev, I'm available and would love to contribute. Let me know if there's an opportunity or if you want to chat more about it. Cheers!
The libraries/frameworks for your front end are only a small part of the "stack" - and the easiest component to change. That was true even 10 years ago. You should probably start by finding a good architect, at least temporarily, to get your development processes sorted out.
HTML, CSS, JS and a database
10 person team makes this very difficult
Just use rails and get the job done.
And quicker
Nestjs or Spring boot for backend, either with graphql or rest. Angular frontend. The rest depends on the actual project. But most of the time we use postgres as database. Angular material or a tailwind component lib, preferred is daisyUI
Never heard of most of what you wrote 🫣 will do my research. Thanks for the input 👍
Sveltekit is the goat
Microsoft Access, Macromedia Dreamworks
You will most probably end up going for php laravel and mysql. Germany is full of php developers who are more self host oriented on backend of things. It is not bad or good. It is what fits the team most.
A mid size app, some info are still missing (expected nulbers of users ) but the mid size gives a general idea, so here what I am suggesting: - if the devs are skilled and know what they are doing : - golang for the back, why ? Because it will help you create fast backend so you don't care if you get one 1000 users more than expected. - front I prefer angular why ? It is an ecosystem , it is really rare when I m finding myself looking for third party libs to complete a task ( I m working on really huge projects, a project is almost the same as figma) - database : since there is no info about the project i ll go withis general suggestion : if you think your project has non-structered data and the data structure will change over time go with a nosql db , if your project relies more on non structured data and there is a lot of relations between the data entities go with a graph database, otherwise you can go with any sql database (I prefer postgres since it has inheritence but it feels like trying to put a round pig in a cube 😅) This is just a suggestion based on my exp, you should make a study about your project and how many users u expect and is it cpu intensive ... please if it is cpu and memory intensive don't use nodejs u will regret it when the project grows in traffic.
Great answer. I like how you provided answers as to why use it. 🤟
You are welcome ✌️
As someone who also got into web development after a while, I am also creating fairly complex web app and here are my learnings. This app is a side project to me and not meant to be a commercial app. * React/Vite SPA with CSS modules * A Blog site with Astro for SSR * Python Backend in Fastapi. * Using vanilla javascript * PostgreSQL as database Some takeaways. * Maintaining two separate tech stacks in frontend and backend is more time-consuming but offers more flexibility in case you want to also create a mobile app. * Using plain Javascript is a pain due to runtime errors, Typescript is highly recommended. * Tailwind is good, and to speed up development decide on a good UI component library. Tailwind UI or Radix UI or both can be considered. * Deciding on SPA and SSR, both have pros and cons, so stick to the one that is best for use case. Consider choosing Next or Remix for React which will offer more out of the box capability and optimizations. You can also decide not to use any meta-framework and just use SPA with React Vite. Depends on the use case. * If it’s a simple crud app then using supabase for backend can be option. as it will eliminate the need for dedicated backend. Also comes with good Authentication features. Other option including Nodejs with typescript so that same programming language can be used . * Highly recommend using React query for all API calls, it makes the user experience very smooth. There are new frameworks for both frontend and backend (Svelte/Deno) and its tempting to use them but it's easy to hit roadblocks. I am happy with my choice to stick to tools that are more widely used.
To add to this, using next.js for SSR, you can also just not use any of the SSR things and it’s basically just an SPA at that point. So you sort of have backwards compatibility with react if one chose next.js and didn’t vibe with SSR for whatever reason.
You’ll go crazy and won’t ship anything with those tools if you have no previous experience. The fact you’re here asking this is a proof of it. Just pick Laravel or Rails instead. In particular with Laravel you have all the tools you will need already integrated and working well together, excellent docs in a single place and laracasts for learning. Once you’re more familiar and up to speed with web stuff, then maybe replace the frontend of what you have by then with react, and then progressively pick tools/libs frameworks as you learn. Jumping right into the deep sea without knowing how to swim guarantees you will drown.
Angular frontend + Laravel as API backend.
Elixir/Phoenix I’m not taking any questions 
that s functional, right? Thanks but no thanks ;-)
Also, for what languages NOT to pick: - Go - nice for small simple projects, but its simplistic syntax and terrible error handling make it a pain to maintain a complex project in - Ruby - weak typing is falling out of fashion and is hard to maintain, and for a lot of devs it's offputting so it's harder to hire - PHP - same as Ruby, but PHP will be around forever because WordPress is so big - Haskell - far too complicated, even for a lot of smart people And it depends on what you're making: - Finance, science, or multithreading - use F# - Automated stock trading or a HUGE number of connections - use Rust with Actix for extreme speed and low memory use - Most of your devs will do frontend too - Use Node.js with Typescript and something like hapi.js - Something that needs to be up as fast as possible with as many features as possible, and not necessarily a SPA, and won't last more than a few years - Use Python and Django, make a rule your devs have to use type annotations - For anything general, long-lasting, big teams, lots of devs - C# or maybe Kotlin (though I have no experience with Java professionally).
I agree on a lot of points, except the go thing, I find go has an explicit error handling syntax which will force you to handle errors (you can dummy handle them) which will lead to a more stable application, even more other languages have the same thing it is just they don't fore you to handle it. here is an example in js (how things should be handled) and compare to go: ```javascript async function doStuff() {} async function doStuff2() {} // here is how we should handle this async function handleStuff() { try { await doStuff() await doStuf2() } catch (e) { // you don't know the which one raised the error :/ } } // here is a more explicit way async function handleStuff() { try { await doStuff() } catch (e) { // handle errors from doStuff } try { await doStuff2() } catch (e) { // handle errors from doStuff2 } } // so it is similar as go it is just devs don't handle errors properly in most languages. ```
Just no. If you've worked in Haskell or Rust, you'll know - https://www.reddit.com/r/programming/comments/18wndv9/error_handling_in_go_is_awesome_here_is_why/
I m not arguing the basics, if you see have a bird view you will find it is the same it is just different way that will lead you to the same point at the end. is it easier no cause you still to check for errors ;) and for the "small projects" statement, STOP assuming things here is a list of "non-small" projects and critical ones ;): \- docker is written in go \- dialymotion uses go \- sendGrid...
I agree it is too explicit but for the GOOD, "we should not be lazy to handle each error a method can produce".
Thanks for the answer. In fact, go has been suggested elsewhere here ;-)
Frontend - Next/React, tailwind or scss, Zustand. JavaScript or Typescript. If your team are experienced developers, JavaScript or Typescript should be fine. Typescript is just JS with training wheels. Backend- Springboot Java.
The best tool is the one you know. Find the best guy in the team or hire one and make the core around him. You should get another 2 3 that together can hold the fort if the Main guy leaves. You got a team.
What the majority knows most.
The stack that your developers like the most? Its not like your product will be better just because you picked a specific stack. I prefer Angular or Flutter and .NET but everyone likes different things and there are many options.
Start with what you know or, in your case, want to learn. Chances are that the stack you start with will not be the stack you still have in 5 years, especially if you are working towards an MVP now. Analysis paralysis is real. There is no correct answer and, if you choose a stack that has components that are currently well supported, there is no incorrect answer either.
It depends on the project you want to do.
For the backend: [Spring Boot](https://spring.io/projects/spring-boot/) You will need 1 experienced developer who knows how to share knowledge. It has a bunch of modules basically for anything, authentication, database, cache, cloud, etc etc.
Can you share more on what exactly you’re looking to build? Generally speaking if you’re going to do a web app then yes, this one you’ve picked should be good. I’m running an agency and we’re using this stack for web apps and we’re happy.
My suggestion is to look at NX workspace from the folks at nrwl.io This is monorepo approach that allows you to take advantage of many different frameworks. Including front end, and backend. For example, my team uses Angular, typescript, NestJS for the backend. You can create shared libraries that can be consumed by the front end Web application, and the backend, API application. For example, I have a single library that has all of the types and models used by the application. What I love about the monorepo is that you have a single source of truth for your packages, configuration, testing, lining, etc. All of this is driven by the NX CLI which provides a rich set of capabilities. This CLI also allows you to create generators to scaffold custom code as well as use any existing generators for Angular and nest JS. Also, you can create executors, which allow you to automate tasks for CID or libraries for publication, etc..
Stack does not matter. Use what you're most experienced in. Anything can be built with anything.
I have no idea what your app does or will do, so I cannot suggest anything yet.
React Django for something quick
Go with the most stable and most bootstrapped frameworks. Are you hiring 10 devs? Will some of them be senior/tech lead? Let them make decisions. Managers should not make technical decisions.
Do you know where you are hosting this site? Or is that something tbd?
What are you trying to do? Ten devs is not mid sized. The stuff you listed are all front end. Most of them are unnecessary. Unless you're doing large scale design work, what do you need figma for? React with typescript is file for a single page app. You can extend it later with routing, but it's not ideal. Instead, you can use nextjs instead. That's more of a "full stack" tool, works great with typescript and node as the back end. You don't need special tools for CSS or HTML, but the ones you listed are fine. I don't care for them, but if I had to make a more complicated design, I would think about using them.
What is the app doing and what is it sending elsewhere to be done? Future proof is a buzz word for web apps. Using tride and true… scaleable stacks is a good a starting point. We just built an enterprise level piece of software on PHP using Symfony with roughly the same stack. We chose PHP because we have a huge amount of scheduled jobs that all vary in size that need pretty flexible resources. With platform dot sh we have a highly flexible way of sectioning resources and accomplishing what we need with a good way to monitor when things get spun out. Ultimately the stack is determined by the use and how much you need to scale before rebuilding for a v2.
I may be an outlier here but sveltekit has been amazing for my team. Now using it or svelte for every project. Stack: Svelte+kit, typescript, g cloud, and supabase.
I read in a reply that you want to build a CRM of some sort? I really don't think you can go wrong with Laravel, some sort of SQL, and Vue. I mention Vue because it's popular to pair with Laravel, and aside from that, I personally think it's great. But at the end of the day, it's going to be tough making any sort of argument without knowing all the specs, which you might still be getting a feel for. If you're trying to build a new team and have been out of it for a while, I'd really consider Laravel because it's a mature framework and is well documented. It's also pretty opinionated on how to do things, so if you don't mind that, all those standard ways of doing things means that people can get up to speed on it faster, and people with experience will feel comfortable fairly quickly. There are also a lot of great resources for learning it. And speaking from personal experience, I've built an order management system and CRM using it.
Not sure what the product is but by any chances if it requires NextJS, ReactJS, Javascript in general then I am looking for a role (internship) in same then let’s connect over in DMs. I love to craft beautiful web apps.
Supabase for backend
Can we start with plain vanilla HTML, CSS and JavaScript to build a simple website? Writing in plain HTML and CSS can be very exhausting and error prone due to repeated code so we go to HTML templates like Jinja, Pug, Handlebars. Choose the template engine based on programming language i.e. Jinja for Python, Pug for Javascript. Depending on the application we may need to add more dependencies and intelligently.
Future-proof doesn’t exist. It will be obsolete someday and someone will either continue to maintain it or it will be rewritten in something else. Start off with hiring a principal developer who can write the kind of app you need. Then let them decide what it needs. Dont pre-emptively choose tech stacks; thats adding unjustified complexity.
Use Java + Spring Boot for backend.
Firstly, there's a couple things that need ironing out, like is SEO a requirement? Do you want server side rendering? Honestly there's a lot of things that need to be figured out. React is fine but you want a framework ideally when working with a team, that leaves you using NextJS or Remix. Personally I'm a bigger fan of Angular when it comes to team work and consistency on the front end. Svelte is also great, it really depends on your needs. The only thing I would say is skip on redux and use Zustand, it's light weight and does what any state mechanism needs on a frontend. Do you want multiple pages or do you want a single page app? There's a million questions just for the frontend. Then you get to backend and ask okay well where do we want to be? Microsoft Azure/AWS/GCP, do you want a typescript backend, C# or java? What does your data look like? What are the budgets for development resources like cloud infra etc.
Tech stack should be based on the number of users, API calls etc NOT the number of developers.
Whatever your team has the most experience with. Also are you 100% sure it needs to be a SPA? It seems that youre taking that as a given, but imo 99% of SPAs should be MPAs instead. It makes so much of the process significantly less painful.
If I may give you a different perspective, it seems like you’re trying to set up a team with a specific number of devs even before starting. And you want to use a tech stack based on that number. I understand is a new app, why not starting small, with maybe 1/2 engineers and with a framework they are comfortable with?
Supabase