Ask HN: If you are starting in 2024, what is the most productive solo dev stack?
Most answers to tech stacks take into account "knowing what you know best".
However, for people who are starting out, without the goal or aim becoming a software engineer and aside of the golden trio (html, css, javascript). What would you learn today to build web apps (both static content and interactive experiences)?
97 comments
[ 3.1 ms ] story [ 116 ms ] threadEven Python will take someone starting from zero anywhere between 10-100 hours to fully grok. A phenomenal time investment if you have any professional interest at all in computers, but if you truly don't, a ridiculous one.
Maybe Wordpress or Squarespace if you want to do something dynamic.
Anything beyond that and you will need to become a software engineer, or at least learn some programming and server ops.
So for someone just starting out, I agree - just pick one. You'll learn it, it is will make sense, you will be productive, and because you only know one thing everything else will seem weird. If you keep doing things, you'll learn more and then things will seem less weird.
In a Dunning-Kruger kind of way? As in, without having the familiarity with other options, you can't recognize how slow and difficult it is?
I personally prefer Symfony over Laravel because of it's modularity and extensibility, but Laravel has the edge on getting started quickly and available SaaS features (such as billing modules and stuff).
If you need SPA-ish features, you could use htmx and if you need some on-site interactivity, I like Alpine.js.
Not if we are talking about productivity, as asked here. HTML is rather simple to learn, but can be annoying enough to write. And let's not start talking about CSS is for a beginner...
Using some flavor of markdown and convert it to html would be far more productive. There is enough software around for enabling people a fast start, and you have the option to still enhance it with html&css (probably javascript too?).
These days you can probably just write whatever format you like and Claude or ChatGPT will convert it to HTML.
https://naereen.github.io/StrapDown.js/
But I've generally seen sites using this strategy to be a lot more bloated and slow, so please be considerate of that if you can.
My point was that if you count the time spent looking for the perfect renderer, HTML is faster and easier to write than Markdown unless you're writing a book. You just added another option someone has to spend time evaluating to the pile.
There's also file includes, template syntax like loops/if-statements, inherited templates, inline Javascript syntax, "filters" for including Markdown and other languages, and much more
If you are experienced, Rails/Laravel but I'd loop Clojure in too.
Dealing with the DB is extremely easy too - it handles relations within databases, queries, and the UI of Parse Dashboard is simple like your regular online spreadsheets. It's very easy to normalize DBs and all that.
Old article I wrote on how to set it up in half an hour: https://smuzani.medium.com/setting-up-a-mobile-backend-serve...
For front end, JS + jQuery + Bootstrap works fine for basic interactive experiences.
You probably don't need React level stuff unless you're building a social media site or similar. One of the advantages of React is that it's easy to communicate what's happening to team members without documentation, but this is unneeded if you're solo.
There's disadvantages though - you have to optimize things like all your JS files, and handle reloading from cache when you've updated a JS file. There's no "clean" or "modular" code; if you made a bar like the " new | threads | past ..." the top of this page, you use find and replace. But I have sites that run perfectly fine for years on this, without much issue in maintenance.
Another bonus with simple HTML+CSS+jQuery+Bootstrap is that you can also host it on some really cheap servers. Netlify is free at first, but it does not scale well to say, 10k visits/day.
On a glance, it looks like Pocket Base is easier and faster to set up but Parse Server might scale better, just because it's tied in with MongoDB by default. SQLite is an interesting choice, but 10k persistent real time connections is pretty much near the point where you should be hiring someone to scale it up.
Supporting Google login out of the box is a major plus, and the dashboard works great on mobile.
I do like it as a middle "low code option" as opposed to the complex no code options like Wordpress or doing the whole stack to build something that might not even sell. Honestly, Firebase has caught up to it in development speed and documentation, but Firebase feels ironically less scalable.
I usually use Laravel, Vue, and InertiaJS for the fullstack. Even though I considered trying a new stack for [1], I decided to stick with what I am familiar with. One reason is because Laravel already integrates well with queues. However, I am not a fan of MySQL and am thinking about switching to a different database.
[1] https://replyhub.co
If you know Python choose a Python stack, if you know Java choose a Java stack.
within the language you know choose the most used one or the most boring one who existed for more than 10 years.
What is the advice here exactly: "never learn anything new"?
The real take away is, there's always new web tech you've never heard of that makes you infinitely more productive.
Blazor is peak web development for me right now. The ability to design components and not have to leave C# for UI logic is amazing.
If you're starting in 2024 and want/need to be productive right away, use what you already know.
Nobody said anything about "never learn anything new". If you have a job and other people are paying you, the expectation is to deliver, not to "learn this cool thing" and be in awe about you "journey of self discovery" while on the payroll. If you really believe you can learn a language, it's libs and frameworks "in a weekend" and forget that's just another humble brag nerds tend to tell others, then we don't even can proceed with this conversation.
Learning is good and needed, learning is hard and takes time. Respect it.
There are too many un-opinionated answers like this. What if I don't respectfully don't know any stack? (my case).
Thats what the initial question was about.
However, I'm interested in Erlang/Elixir, so I'd like to hear what the upsides of Phoenix are.
And follow the prompts
Site: https://vitejs.dev/guide/
Using libraries that have been around for a few years and have accumulated a lot of training data is a huge productivity boost here, because LLM tools can both write code that uses them and usefully explain and debug them when they go wrong.
It's weird and a little uncomfortable to have this as part of my selection criteria, but if I want to maximize the rate at which I can build things it's honestly a useful rule of thumb.
Seriously. The only way that works for me is to spend a bunch of time messing around with a model trying out different things.
I really want to have a more repeatable process for this. I've been tinkering with a way of setting up my own automated evals to run against different models but I'm a fair way off having something usable there.
For programming libraries I find that my assumptions usually hold: if a live set is widely used and has been around for a few years it's likely to get good results.
I picked the WTForm Python library recently for this reason.
ChatGPT learns from blog posts, forums, etc. If there's a vibrant and helpful community around a stack, ChatGPT has a lot to work with. If it's obscure, not so much.
The difference is that I didn't use to rate that as one of my highest selection criteria, because if a new library was well designed and well documented enough I wouldn't feel the need for large amounts of community support.
Today if a new library is well designed and well documented I still might pick a more mature competitor purely for the LLM advantage.
It might seem non-important to many, but I was writing a big amount of boilerplate code, tests, etc. and I have a feeling I would've been much more productive just sticking with C.
Picking a framework advice: https://youtu.be/RTLSSGPoASU?si=UeVO_rHtYK_YS48v
Understanding the different types of frontend frameworks: https://youtu.be/CQuTF-bkOgc?si=EMKfE_sNZNqf6c-x
shadcn-svelte: https://www.shadcn-svelte.com/
BE: .NET or Spring Boot
Database: SQLite (eventually PostgreSQL in Docker container)
Hosting: Hetzner
In the time it takes a big team to schedule a pre-meeting for discussing changing a schema, solo-devs can whip through many huge cross-cutting refactors across their entire architecture without anyone complaining about broken merges.
Building a real, successful thing generally involves more time and more learning about the customer space than you expect at the outset. As a single dev, you have a massive advantage over big teams in your ability to make huge fast change in the architecture of your product.
Here's the controversial part of this: if you want to maximize your ability to make big changes, you want a strongly-typed codebase (for me that's TypeScript on the front-end and C# on the backend because of the quality of the refactoring tooling for it). There's no formal guarantee that strong typing will keep your code working across big refactorings, but in practice it just works. You focus on getting the inner loops right and the compiler and IDE takes care of the rest.
Yes, you can probably write the first iteration faster in a dynamically typed language, but when you start making those big changes that are your unfair competitive advantage against larger teams, the strong typing combined with modern IDE tooling capabilities means a working system remains a working system even as you treat it like completely malleable clay.
I'm also a fan of modular monoliths, again for ease of major refactoring (if you're not familiar with it, check out for example TurboRepo in the node.js space). You can organize an enormous amount of code well using this technique, including having things partitioned to hand off to other devs or multiple teams if you happen to eventually want to scale up from single dev to multi-dev.