Hacker News Reader

Comment by andrew_ | Hacker News Reader

My one and only beef with frameworks like this is that one ends up learning the idioms of the framework to deploy as a first class citizen, then when faced with deployment issues, having to learn the basics of the target cloud platform as a second class citizen. I get why this is appealing, much in the way jQuery was appealing over raw DOM back in the day. However, I much prefer abstractions that are closer to the bare metal which still provide convenience and good DX such as CDK or Terraform.

View on HN

I relate. I have had the 3 citizen problem of Azure + Terraform + Kubernetes on a project I worked on and yeah figuring out issues requires navigating all that.

The 2/3 citizen problem is everywhere in tech. Look out for it and avoid if you can. It is probably an innovation token. That is why I am less enthusiastic about things like Supabase (picking on the one I remember) and it’s ilk over just Postgres.

Maybe I am waffling on the basic point of: boring is good, at least as a default to be convinced from.

I feel lured towards Supabase's immediacy. Is it much more opaque to debug than an equivalent assembly of suitable components ?

Hey Andrew, thanks for checking it out. I think that the tradeoff between control and convenience is super important. We've tried to focus on convenience for Nitric, but also make the plugins and APIs transparent so you can regain that control when you need it. That said, it's hard to balance. Have you checked out Pulumi? They're another great option we like if you want control like CDK or Terraform.

for me at least it's less about control and more about comprehension, and the hidden costs of a lack thereof

Yeah, there is a cognitive cost to frameworks like this. Ruby on Rails is the same, where there are conventions to learn and pitfalls to avoid, but like DHH said "look what I don't have to do".

I've worked at companies that have had bare metal DX and they used it to stab themselves. I mean, anyone can be contrarian, and that's not what I'm trying to do here, but there is value in "idk what the queue is or how it's implemented, but I know how to call it". If you're not using an abstraction layer for everyday engineers (on a project that has 20+ engineers on it), then that means either your building one yourself, or you're forcing your teammates to engage with DevOps themselves.

If I were to start a company from scratch, I'd use something like encore.dev, because even though there's a framework to learn, it's a DevOps-less, or less-DevOps approach to building software fast without boilerplate.

And I'm not sure what it is about express.js, but everyone seems to have their own way of doing it. It's cool to see paradigms solidify, like tRPC and Nest.js, and now this.

I don't see any value in developers not knowing anything about the inner workings of their app. None. The only value that it gives is that they can bath in ignorance.

Where is the value that when your devs push something that breaks, you need to rely on external people to un-break it?

It's a business model, it only gives value to the company that build the framework. It only gives debt to the people using it...

I'll take a devil's advocate bite and offer: Onboarding. It's easier to get junior and mid-level devs started on a repo/project if they don't have to understand 100% of the full, entire stack. Maybe I'll bathe the babies in early ignorance to hook them and help them grow.

That said, if they stay in baby form and never grow...

You can give a baby a smaller piece of pie instead of some completely different pie that's baby friendly.

Personally I am for bathing babies in pie, so :thumbsup:

As always, it's a matter of where you draw the line around what counts as part of your app, and what you count as external dependencies. The level of abstraction that is safe to use changes by use case.

It wasn't all that long ago that it would be unusual for a programmer to not understand assembly code - and before that, to have an understanding of how transistors/vacuum tubes are assembled to make complex circuits.

But of course, nowadays for web development everybody trusts the CPU architecture to operate efficiently, the OS to do reasonable things, TCP/IP to remain reliable, browsers to support Javascript, etc etc. In the last few years we've even seen some stabilization even around the historically churny realm of javascript UI libraries - most developers don't even need to know how React works under the hood, let alone how V8 runs.

The reasonable level of abstraction has grown immensely, and the number of web developers who deeply understand the true stack is probably fewer than 10. For most use cases, a service that abstracts over the various cloud provider options is perfectly fine - and when its not, that's generally a "good problem" to have (because it means your app is having scale issues).

All business models are meant to give value to the business. The successful ones also give value to the customers.

Reply on news.ycombinator.com