Amazing and refreshing discussion! So happy to have people like DHH be a rational voice in the tech industry. It's never been as noisy (especially with hype) as right now.
I think raw Kubernetes (no service meshes and other add-ons) is also on the path to simplification, full-stack enablement and a good, future-proof investment. While Docker image format is the standard for containers, Kubernetes is the STANDARD for container orchestration.
Why, because you want to have much better DX and code guarantees. I wouldn't touch the any project without a type system, just like I wouldn't touch any project without tests.
I love the main idea, but the ts hate is most likely user error. Its the cheapest abstraction imaginable and theres ways to skip build hell if you really want to.
@@brokula1312 Okay hear me out. I'm not totally opposed to typescript, but there are a few things you have to consider. In my personal projects I usually end up writing plain JavaScript. Why? 1. I'm the only one who reads it. 2. Maintainance without type cluttering (what's the point adding complex types to a complex solution to make my code completely unreadable? I want to get shit done!) 3. No compiler step If you don't use JavaScript libraries, fair. It brings convenience and less confusion in a big code base using libraries with type declaration. A developer who encounters a library in a big project that doesn't provide types can slow down development time. I get that. I was there. Collaborative projects in OSS or in companies are different beasts. It has to be maintained by a team and/or over years by different people. In that scale Typescript makes sense. Here are some of the problems I constantly faced over the years with TypeScript: - Typescript is lying to you: Typescript doesn't only add typings to your code. On compile it mutates your code (and not always to the better). You have to think in typescript, because if you know certain valid(!) ways to code in JavaScript you get in trouble. It touches things that is none of typescript's business. - Vendor-lock-in: TS is not designed to give you the option. M$ has an incentive to keep you in their bubble. That's why they don't care about proper tooling to make DX with JS libraries better and don't provide proper tooling for those who code plain JS. I really love declaration files, because they don't get in my way and help me add more complex types without adding complexity inside of my code base. Unfortunately TS doesn't provide a JS to DTS compiler. You have to do your research and install yet another package. Additionally to that I found myself often in that position that I needed a single DTS file, because tooling in vscode sucks with plain JS. I'm kind of spoiled by the deno tooling in vscode, but my JS is mostly in browser and not on server, so I often end up don't need deno at all, but still want it's benefits. Kinda sadge. The real issue is the tooling in my opinion. It could be better - and I mean by a lot.
@@brokula1312 The problem is a tooling issue. Try play around with deno and work with JS and TS in tandem. It's a completely different experience. Unfortunately the native tools in vscode are not that great and could be improved - and I mean by a lot.
42:25 it isn't that hard to predict the future, though. Knowing that most things are hyped and progress is far slower helps you make far better predictions. Knowing how and why some people who predict huge changes helps too. Knowing some of the related history also helps. Anyone who saw old sci fi should know that AI has a long history of hype. Historic trends like that generally continue. Anyone who knows the predictions Elon Musk shared a decade ago knows that Elon Musk spews mostly BS about everything he sells. Knowing Elon Musk's predictions are wrong can help you make better predictions. You can more accurately predict that much less changes will happen than Elon Musk says because you know that's what has happened in the past. You can also learn to largely ignore what Elon says. You can also get better at finding the truth about the present. You can find people who have historically shared more accurate predictions that came true and learn from them.
As a full stack developer I agree. But a lot of it is because the frontend requirements evolves very quickly. Backend is basically CRUD most of the time.
@@popopooooooooooooooo really? what in front end has really evolved in the last 10 years that justifies its complexity? Nothing. In fact a lot of its pretty much made full circle as SSR is back in vogue again. All of frontend's complexities are due to its own self created problems of trying to be more clever than is necessary.
@@darylphuah Look, it's mostly about client requirements, you know? They come in and are like, "I want the XYZ feature just like Facebook/Instagram/Slack/whatever." After 20 years in this biz, I just don't give a crap about that whole stack competition thing anymore. People tend to talk crap about stuff they don't even understand, right?
@@casadogaspar Sure! it’s how capitalism works! “Let’s just spend more money and time in complexity” - No way! I've fallen into this trap of doing things the old way. Try it yourself. You can simply evaluate the amount of “variables” and logical conditions involved in the FE and BE requirements, without writing a single line of code and draw the conclusions for yourself.
If only that were true. A solid 50% of custom types I’ve encountered in TS and Java codebases are just noise. They provided no meaningful information, did not clarify the domain, and only served to further abstract and complicate code that would have otherwise been plenty easy and simple enough to work on. TS is essentially using complexity to try to manage complexity. Other than describing the shape of an object, I find it fails to add any additional value.
DHH's ideas are anticapitalist! People invent useful things out of curiosity or need to make their lives easier in some way, and capitalism takes these things and makes them worse by engineered obsolescence, subscription type models, etc.
@@hephestosthalays2700 Just try to analyze his commentary a bit more in detail. Capitalism is only incentivised by monetary gain. This monetary gain does not necessarily need to come from making products better. It most often comes from market power. That's why, as he mentions, pharma companies don't make cures but are more focused on "subscription" type drugs. Consumers have no way to influence this outside of governmental policy, as there's no leverage from a consumer side, since the market of pharmaceuticals is not competitive by nature. Another example is engineered obsolescence. When light bulbs were invented, they had quite long lifespans. I'm talking about decades. Light bulb companies saw this as a problem from their earnings, so they started engineering light bulbs to have shorter lifespans!
Another hour of DHH after he was on ThePrimeagen for 2 hours? Sign me up. I could listen to this man all day. He needs a podcast.
He has a podcast through his company 37signals.
He has one, it's called rework
i have no words to explain the feeling i got after listening to this. This is just dope.
Amazing and refreshing discussion! So happy to have people like DHH be a rational voice in the tech industry. It's never been as noisy (especially with hype) as right now.
DHH is so easy to interview. You just say anything to him and he goes on a minutes long rant until you stop him. You did well to keep him on topic!
Thank you for giving us the opportunity to develop a competitive product individually.
DHH just keeps winning, now I know why rails is relevant in 2024
Thanks for bringing DHH, there are tons of insights and inspirations we can learn from
Such a great title in this video and it's true for most modern tech stacks & products.
This was such a fun listen. Great interview.
This guy is a modern-day philosopher.
Luca my respects 🎉🎉. Greetings from your former coachee ! Happy to see you grow day after day .
Thank you so much Flavio! ❤🙏 It means a lot
wow this is amazing
I'm so happy this is starting to get talked about.
This is a great interview. Good job with the questions!
❤🙏
Great interview :)
This is really amazing
I think raw Kubernetes (no service meshes and other add-ons) is also on the path to simplification, full-stack enablement and a good, future-proof investment. While Docker image format is the standard for containers, Kubernetes is the STANDARD for container orchestration.
DHH makes me feel seen 😍
My impression of this man is, you listen to him and you become a better person (not just programmer).
I feel SOOO validated with this. Every time I see TS everywhere, even on components that are just a couple of lines of code I'm like.... why???
Why, because you want to have much better DX and code guarantees. I wouldn't touch the any project without a type system, just like I wouldn't touch any project without tests.
Dude TS is free and you can choose to just not to use it.
I love the main idea, but the ts hate is most likely user error. Its the cheapest abstraction imaginable and theres ways to skip build hell if you really want to.
@@brokula1312 Okay hear me out. I'm not totally opposed to typescript, but there are a few things you have to consider.
In my personal projects I usually end up writing plain JavaScript. Why?
1. I'm the only one who reads it.
2. Maintainance without type cluttering (what's the point adding complex types to a complex solution to make my code completely unreadable? I want to get shit done!)
3. No compiler step
If you don't use JavaScript libraries, fair. It brings convenience and less confusion in a big code base using libraries with type declaration. A developer who encounters a library in a big project that doesn't provide types can slow down development time. I get that. I was there.
Collaborative projects in OSS or in companies are different beasts. It has to be maintained by a team and/or over years by different people. In that scale Typescript makes sense.
Here are some of the problems I constantly faced over the years with TypeScript:
- Typescript is lying to you: Typescript doesn't only add typings to your code. On compile it mutates your code (and not always to the better). You have to think in typescript, because if you know certain valid(!) ways to code in JavaScript you get in trouble. It touches things that is none of typescript's business.
- Vendor-lock-in: TS is not designed to give you the option. M$ has an incentive to keep you in their bubble. That's why they don't care about proper tooling to make DX with JS libraries better and don't provide proper tooling for those who code plain JS.
I really love declaration files, because they don't get in my way and help me add more complex types without adding complexity inside of my code base. Unfortunately TS doesn't provide a JS to DTS compiler. You have to do your research and install yet another package. Additionally to that I found myself often in that position that I needed a single DTS file, because tooling in vscode sucks with plain JS. I'm kind of spoiled by the deno tooling in vscode, but my JS is mostly in browser and not on server, so I often end up don't need deno at all, but still want it's benefits. Kinda sadge.
The real issue is the tooling in my opinion. It could be better - and I mean by a lot.
@@brokula1312 The problem is a tooling issue. Try play around with deno and work with JS and TS in tandem. It's a completely different experience. Unfortunately the native tools in vscode are not that great and could be improved - and I mean by a lot.
The pendulum is swinging back!
I remember when DHH and Jason said adobe and everyone else SHOULD do subscription based software.
42:25 it isn't that hard to predict the future, though. Knowing that most things are hyped and progress is far slower helps you make far better predictions. Knowing how and why some people who predict huge changes helps too. Knowing some of the related history also helps. Anyone who saw old sci fi should know that AI has a long history of hype. Historic trends like that generally continue. Anyone who knows the predictions Elon Musk shared a decade ago knows that Elon Musk spews mostly BS about everything he sells. Knowing Elon Musk's predictions are wrong can help you make better predictions. You can more accurately predict that much less changes will happen than Elon Musk says because you know that's what has happened in the past. You can also learn to largely ignore what Elon says. You can also get better at finding the truth about the present. You can find people who have historically shared more accurate predictions that came true and learn from them.
Show me where Elon touched you? Electric cars? CHECK. Self-landing rockets CHECK. Self driving cars? CHECK
Now I realized I cannot seriously trust anyone who hates and bashes DHH's viewpoints.
Same for me, he has quite good points he said in this interview. Especially the dividends on learning new skills is something I believe in too
First minute into this video, all I can think of is Next.js and Vercel 😂
Frontend developers took complexity to another level.
As a full stack developer I agree. But a lot of it is because the frontend requirements evolves very quickly. Backend is basically CRUD most of the time.
@@popopooooooooooooooo really? what in front end has really evolved in the last 10 years that justifies its complexity? Nothing. In fact a lot of its pretty much made full circle as SSR is back in vogue again. All of frontend's complexities are due to its own self created problems of trying to be more clever than is necessary.
@@popopooooooooooooooo Its doesn't evolve quick, just it's complexity evolve.
@@darylphuah Look, it's mostly about client requirements, you know? They come in and are like, "I want the XYZ feature just like Facebook/Instagram/Slack/whatever." After 20 years in this biz, I just don't give a crap about that whole stack competition thing anymore. People tend to talk crap about stuff they don't even understand, right?
@@casadogaspar Sure! it’s how capitalism works! “Let’s just spend more money and time in complexity” - No way! I've fallen into this trap of doing things the old way. Try it yourself.
You can simply evaluate the amount of “variables” and logical conditions involved in the FE and BE requirements, without writing a single line of code and draw the conclusions for yourself.
Anyone have a link to the kid making a game/chatbot using an LLM as a pair programmer?
yes! here it is: x.com/rickyrobinett/status/1825581674870055189
I only hear vercel, vercel, vercel :))
Types reduce complexity by offloading more work from your brain to the compiler
If only that were true.
A solid 50% of custom types I’ve encountered in TS and Java codebases are just noise. They provided no meaningful information, did not clarify the domain, and only served to further abstract and complicate code that would have otherwise been plenty easy and simple enough to work on.
TS is essentially using complexity to try to manage complexity. Other than describing the shape of an object, I find it fails to add any additional value.
I had to look on video to be sure that's DHH not Jordan Peterson talking
Looking like NFKRZ's Dad
I agree with his general sentiment, but what a rambler!
Turbo Tax
Can we just have good things again?
Webpack sucksssss the soul out of my body! 😅
I have spent most of today just trying to understand a few things that Microsoft is doing. So complicated.
Lewis Mary Garcia Margaret Perez James
Lewis James Young Gary Jackson Helen
Thompson Scott Jones Melissa Smith Timothy
Im so drunk rn
DHH's ideas are anticapitalist! People invent useful things out of curiosity or need to make their lives easier in some way, and capitalism takes these things and makes them worse by engineered obsolescence, subscription type models, etc.
What on earth
@@hephestosthalays2700 Just try to analyze his commentary a bit more in detail. Capitalism is only incentivised by monetary gain. This monetary gain does not necessarily need to come from making products better. It most often comes from market power. That's why, as he mentions, pharma companies don't make cures but are more focused on "subscription" type drugs. Consumers have no way to influence this outside of governmental policy, as there's no leverage from a consumer side, since the market of pharmaceuticals is not competitive by nature.
Another example is engineered obsolescence. When light bulbs were invented, they had quite long lifespans. I'm talking about decades. Light bulb companies saw this as a problem from their earnings, so they started engineering light bulbs to have shorter lifespans!
Nothing he said stands against capitalism.
You know DHH is literally a capitalist right?
He owns a company that employs 70 people and makes millions.
Oh lord ...