4 ms·

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 sa

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.

dncornholio 4y ago
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...
- fwip 4y ago
  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.
- jakswa 4y ago
  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...
  - dncornholio 4y ago
    You can give a baby a smaller piece of pie instead of some completely different pie that's baby friendly.
    - jakswa 4y ago
      Personally I am for bathing babies in pie, so :thumbsup:

dncornholio 4y ago

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...

fwip 4y ago
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.
jakswa 4y ago
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...
- dncornholio 4y ago
  You can give a baby a smaller piece of pie instead of some completely different pie that's baby friendly.
  - jakswa 4y ago
    Personally I am for bathing babies in pie, so :thumbsup: