Comment by davepeck | Hacker News Reader

Comment by davepeck | Hacker News Reader

Parent Full thread

These are excellent, thank you.

I maintain similar Django and Flask + compose stacks on behalf of the startup studio I work for so it’s fun to compare notes.

For our Django stack, for instance, we have also settled on Postgres, on celery+redis, and on whitenoise. black/flake8/isort also seem universally agreeable. We also throw in pyright and generally make extensive use of type hints.

For the front-end, we’re currently Create React App with TypeScript and Tailwind. I’d love for us to move away from CRA, so your use of esbuild is helpful to see. (I’d personally be happy using HTMX or Turbo/Stimulus but for the moment a JSON API backend with a React SPA front-end seems more comfortable for more of the CTOs who hop on board.)

We also supply some minimally opinionated glue at the API layer. On the back end we have a base View that provides a few helper methods for transmuting invalid Form instances to nice JSON replies that the TypeScript API invocation code works with gracefully. (We used to push DRF but have lots of feedback from older startups than ran with it and had regrets down the road.)

Offtopic, but I've googled Tailwind because of this comment. This seems absolutely crazy to me, in the worst sense imaginable. So, there was (and still is) "style" attribute in HTML. It leads to lots of repetition and yadda yadda, so people started using classes instead to write their CSS. There are dozens of schools of "best practices", or meta-frameworks, or actual frameworks to make it all more manageable, but now typically each element still has like 5 different classes specifically to define styles. So, finally someone got tired of it and came up with an ingenious solution: JS framework that dynamically defines CSS-classes with CSS-property-like names to write styles right in the HTML again, but to use class attribute instead of style attribute?! What's even the point?!

Hah! This was pretty much my response when I encountered Tailwind for the first time.

This post by Tailwind’s author gives some more perspective: https://adamwathan.me/css-utility-classes-and-separation-of-...

I had the same concern, this article perfectly captures the problem and gives perspective to the solution Tailwind provides - Thanks for sharing!

Classes are not perfect, they introduce relative meaning (or meaninglesness) and in prototyping its often a huge waste of time.

Other than that I agree.

no offense, but man, the amount of tooling you guys are using sounds to me insane. How is a person able to oversee and understand everything. The older i get the more i feel distantiated and disconnected to these modern practices. I am afraid that if I ever have to find a new workspace i wont be able to succeed because of this.

I definitely relate to this but frequently challenge myself and then overcome it. You just have to bite the bullet and carve out some time to try them out.

The key thing to understand is that all these things are shrouded in incomprehensible jargon and alien sounding names that make it incredibly intimidating to get started. But the fact is, it is a wide but shallow pool of jargon sitting on top of the same old computing fundamentals that have been around since the 1970s.

You will find if you know your fundamentals, then the jargon is far less difficult to overcome than it seems. You just need a bit of exposure and if you spend any amount of time playing with the tech it just starts to happen by osmosis. (If there are fundamentals you aren't solid on, treat it as an opportunity to bed that in - even these things are not generally super complex in the end).

I'm so-called full stack developer so I have to be on top of it and it's hard. I'm constantly behind so I spend quite a lot of time catching up whenever I'm getting chance. It's possible (e.g. I think that I can one-handed build an application with react frontend and java/golang/node backend, build a k8s cluster and deploy everything, following best practices), but it's lot of things that you'll forget eventually.

I think that one sane way is specialization. Become an expert in writing nginx-ingress yamls in some big corporation. Another sane way is to throw away modern tech and stay with old tech. You can deploy perl cgi to OpenBSD just like you could 20 years away. Another way is to carefully select technologies which were proven for 7+ years. I'm trying to follow this way.

No offense but that list of tools is miniscule and you should pause if you think it's anywhere near "insane". For comparison a regular handyman with a basic set of tools easily has 50+ if they just started. It's definitely possible to understand all of that and way more. Unless you're fresh out of uni and never worked on a professional company with more than a couple of people you'd see many more.

I'm not GP, but I used to write firmware. I had a C compiler, a debugger, and emacs.

IIUC, if you write a web application in the MS world, you have Visual Studio, ASP.Net, and IIS.

There doesn't have to be piles of libraries.

No offense taken. As a fellow old person (whose first computer as a young kid was a TI-99/4A) I definitely feel this pain.

But because I am also an old engineer who works with a lot of other old engineers we are lucky to have a shocking number of human-years’ accumulated experience not only selecting a pile of tools and frameworks but also sticking with them from zero to $BIGCO. Put another way, I’ve shot myself in the foot more times than I can count with these tools and I do it less often and in more esoteric ways these days.

I can’t claim the same degree of experience with all these tools, of course. Pyright is bleeding edge. Tailwind is still the new kid. Relative to (say) Python and Django or Flask, React is new too. Most of the pain and learnings come from these newer moving parts.

Is it “better”? That depends on the axes of evaluation. As a startup studio where the 70% case might be “SaaS that takes a back-office process held together today by Excel & email and makes it way better” the answer is: sometimes, unequivocally yes. Not just because of the tools and the potential velocity they can confer, but because of the kinds of teams we can build around them. Sometimes, plain old Django with nothing added is a clearly better choice.

In the end, every startup is its own snowflake. We try to select “starter stacks” that balance industry familiarity with our ability to offer meaningful operational perspective. We definitely don’t think of them as the final world.

I think it was a subtle trend of making everything in tiny blocks while javascript / html5 evolving a lot, it created a jungle. But deno/bun/esbuild minded tools are more integrated, faster and leaner it seems (hot reload, typechecking, high perf all in one)

Reply on news.ycombinator.com