If you make the mistake of googling or searching on YouTube, choosing a web stack seems to be one of the most important decisions you could make in your lifetime. Forget about your career, your spouse or where to live: this is the big one. As an outsider, there seems to be more web frameworks that atoms in the known universe, and everyone has very different, strong opinions on how you should build a website.
After much searching around and listening to many of their arguments, I humbly and wholeheartedly disagree with the underlying premise. If you are starting out, I don't think that it hardly matters at all. My ignorant take is that unless you are a company the size of google, where your decision will turn the fate of 100s of developers, for 95% of the websites out there you can use whatever you feel like. If it works and it looks decently nice, the user won't care (This applies to many different things, but I won't get into it) and you are incredibly unlikely to run into the limitations of any platform for at least a few years after you learn how to declare your first variable. Getting started at all is more important.
I still have to choose though, so this was my criteria:
It can't be to niche. If I learned anything from my time working in Bioinformatics is that being able to google your problem, really matters. It's the difference between spending 10 minutes troubleshooting something vs 10 hours. Between the calming feeling of realization with a "Oh, that was the mistake, now I get it" to yelling at the wall "They could have made the fucking thing more clear, eh?" when you finally find the missing docstring in a deprecated branch of the repository, or the package author explaining how the parameters really work in a 15 year old email list. I'm down to try to cool new thing on my own time, but if I need stuff to work, I want it to just work.
The less code, the better. That's almost always true. Writing simple, straightforward code makes your projects easier to read, better to maintain and faster to iterate over. Large repositories should be large due to the complexity of the task, and nothing else.
The less dependencies, the better. This is not always true, but it is when learning something new. I don't really care if I end up using 20 different libraries in one python file, but the difference is that I already know python. I can quickly tell if the error is mine or external, and when It's my fault, quickly correct it. It's easier to learn one thing at the time, and when you don't even know how to write a function in this brand-new programming language, it becomes really hard to understand where the language ends and a library begins. You are always better off learning 1 new thing at the time.
The goals define the tools and Good enough is enough. I am a bioinformatician and data scientist first, so making websites is not my job and never will be. Most of my needs are covered if I can build a modern looking UI with some responsive user inputs, display good looking data charts, probably a table, maybe authentication. My product is not the website but the thing that lives underneath it, so unlike other technologies I've learnt before, it is not critical for me to become an expert at this.
There must still be a learning path. I mean, I just said that I don't care for web development, but that may not always be the case, right? So ideally, I find a learning path that allows me to add more tools on top, progressively, as I master the ones I am using.
Decision paralysis was a thing. I asked around and got a ton of different answers, and none convinced me. At times it felt like choosing a job, since whatever I chose would dictate how I would spend a non-trivial amount of time. In the end, I ignored most of my friends' suggestions and ended with what I thought would be best for me to start with.
The first version of this blog was finally built using FastAPI, HTMX and Bootstrap.