Dear Honeypot team, You are now free of your sin of making React documentary. P.S. Please make a documentary on DHH and Hotwire. This man deserve much more attention than those react lunatics. He has done more good to startups (and webdev in general) than a boatload of VCs.
@@ivan.jeremic Most apps don't need react, its just added complexity. And React doesn't solve anything, because your business logic WILL be on the backend, no matter what. React is just a way to structure state in the front end. But you're duplicating state, because the one true state will always be on the backend. In 99% of apps, you're wasting your time and introducing added complexity, cost, and defects.
2:12 when using SSR techniques, I honest don’t know how you would separate front end development from backend development. They are fundamentally tied together. I don’t know why you would want to do that either. Maybe there should be prototyper developers and finisher developers, both full stack, but one gets things implemented and working, the other polishes and cleans and improves the prototype. But I’ve never understood the frontend/backend separation.
@@emilz0r ah yeah, that’s another great point! Many apps are written that way. But API driven sites have the same issues as what I’m talking about. I guess there are three scenarios here: 1) the API and UI are owned by the same team. 2) The API is owned by a different team in the same company. 3) the API is owned by a team in a different company. For 1, it would be super slow to make changes with separate frontend and backend development. For 2 and 3, the UI would never talk directly to those APIs, there would be a backend that consumes the other teams APIs first, which manipulates and/or combines with additional data before presenting in the UI layer. Because the data driving the site and the UI to present that data are fundamentally tied together, development will always be quicker if the backend driving the UI and the UI are developed in unison. So it should be done by the same developer and not different developers with different skill sets. I don’t see how it can be effective to only have front end devs and only have backend devs. Especially when in the same organisation. It would be super slow to make changes for a team that separates backend development from frontend development. It’s always better to have have devs working on both. If you want to talk about division of focus due to complexity in the code, different teams of devs could focus on certain parts on the app. Eg one team focuses on a particular tool or module of a site, while another team focuses on the platform aspect of a site, like authentication and authorisation and how each feature and new features can hook into that platform seamlessly. Also, yeah you may have a very complex function in the backend, but that functionality would be handled by an expert team, the Integration of that into the app would be done by devs of the site, they would develop the connections to the complex functionality within the backend, and also build the front end. Effectively, the complex app would have an API of some sorts, but it’s the backend code that wraps that API, but the UI should be built by the same people that manage the backend wrapper around the API to the complex functionality.
@@sleekism no data. I’ve only been on the end of full stack… so I honestly don’t know how front end and back end development can be separated how communication and coordination of work can be done efficiently and effectively in a way that doesn’t just add time in comparison. When you develop the backend and front end together, nothing needs to be coordinated because you just do it together. Happy to hear others insights into how it works.
For Rails my recommendation for you 1. Increase the quality of the documentations as still some pages are shown as in progress for years. 2. Build something official railcasts so that more people will come. 3. Build more official high quality gems. Everyone likes rails but official learning resources are limited compared to other stacks. Also gems in git many of them are outdated.
@@emilz0r This is a bit tong-in-cheek as we know that for local interactions SSR folk still use JavaScript. David is just making making a line on the sand to stand on one side.
You have to do that anyway, just with JSON. It's the same thing. Unless you plan to dump your entire db table into the frontend. Which, by the way, you can absolutely do without something like React. It just breaks down when you're making something past a toy app. Whether you're using React or not, your data retrieval patterns WILL live in the backend, no matter what. So you don't gain anything from extra client side code, besides complexity.
Serverside applications in my experiences tend to get less snappy, less userfriendly cause they just too far from the input and events in the browser. Also Backend Devs tend to Fokus on what's the easiest for the architecture they've built and not what makes most sense and value for the user. There is even more to say I guess. Will create a talk about it maybe
Always preferred Laravel over Rails, but I do appreciate DHH's sentiment here, and I agree that the pendulum has swung too far towards FE everything these days. That said, some FE code is not a bad thing (although I'm not a fan of how Hotwire does it).
There are values in both. JS can be used to reduce network roundtrip, UX and SSR is great for speed rendering and better at security management. So.. SSR framework FTW.
What he is missing is that using JavaScript does not mean you need to do all the work on the client, there is a thing called JavaScript on the server he might not have heard of it.
@@nafcho1because he doesn’t allow political debates to take place at his company. This is apparently “evil” in the eyes of politically deranged Americans, even though it’s literally considered polite in every other part of the world.
@@consumedata4544yeah, imagine wanting the people who you pay to work actually produce something, rather than engaging in endless political debates that never change anyone’s minds! 🤯
![ร้อยพ่อพันแม่ - WanMai [Official MV]](http://i.ytimg.com/vi/XY2pNYASEbg/mqdefault.jpg)
Thank you,
Please give us a longer video on Ruby on Rails Documentary, like the one you did on Vue, Elixir, React.
Yeah there should be one from around 2007 I think.
Ruby is so good!
😏
@@Honeypotio due to public demand 😀
th-cam.com/video/NaEG5Dz7xzM/w-d-xo.htmlsi=9lJx12kFe8zsV7Lx
We need the full conversation, please. So much practical insights
Dear Honeypot team,
You are now free of your sin of making React documentary.
P.S. Please make a documentary on DHH and Hotwire. This man deserve much more attention than those react lunatics.
He has done more good to startups (and webdev in general) than a boatload of VCs.
"You are now free of your sin of making React documentary." Talking about lunatics... lol you guys are funny.
As a web dev for 20+ years, couldn't agree more with him.
jQuery old or Web1 old?
SSR with your framework of choise + HTMX seems to be a nice solution these days.
if your iq is under 90 and not able to grasp React.js yes.
@@ivan.jeremic Most apps don't need react, its just added complexity. And React doesn't solve anything, because your business logic WILL be on the backend, no matter what. React is just a way to structure state in the front end. But you're duplicating state, because the one true state will always be on the backend. In 99% of apps, you're wasting your time and introducing added complexity, cost, and defects.
Is there gonna be a bigger interview like video with DHH ?? Or is that it ?
Stay tuned🤭
@@Honeypotio of course!!!! haahahhahahahahah
Thank you from bottom of my heart.
Since you've come to the client side vs server side arena, it's time to expect some Svelte content :)
i agreed! the trends always not the same so the basic and core logic will be same. if you are rails developer you must have blocks concept
2:12 when using SSR techniques, I honest don’t know how you would separate front end development from backend development. They are fundamentally tied together. I don’t know why you would want to do that either. Maybe there should be prototyper developers and finisher developers, both full stack, but one gets things implemented and working, the other polishes and cleans and improves the prototype. But I’ve never understood the frontend/backend separation.
@@emilz0r ah yeah, that’s another great point! Many apps are written that way. But API driven sites have the same issues as what I’m talking about. I guess there are three scenarios here: 1) the API and UI are owned by the same team. 2) The API is owned by a different team in the same company. 3) the API is owned by a team in a different company. For 1, it would be super slow to make changes with separate frontend and backend development. For 2 and 3, the UI would never talk directly to those APIs, there would be a backend that consumes the other teams APIs first, which manipulates and/or combines with additional data before presenting in the UI layer. Because the data driving the site and the UI to present that data are fundamentally tied together, development will always be quicker if the backend driving the UI and the UI are developed in unison. So it should be done by the same developer and not different developers with different skill sets. I don’t see how it can be effective to only have front end devs and only have backend devs. Especially when in the same organisation. It would be super slow to make changes for a team that separates backend development from frontend development. It’s always better to have have devs working on both. If you want to talk about division of focus due to complexity in the code, different teams of devs could focus on certain parts on the app. Eg one team focuses on a particular tool or module of a site, while another team focuses on the platform aspect of a site, like authentication and authorisation and how each feature and new features can hook into that platform seamlessly. Also, yeah you may have a very complex function in the backend, but that functionality would be handled by an expert team, the Integration of that into the app would be done by devs of the site, they would develop the connections to the complex functionality within the backend, and also build the front end. Effectively, the complex app would have an API of some sorts, but it’s the backend code that wraps that API, but the UI should be built by the same people that manage the backend wrapper around the API to the complex functionality.
@@br3nto is the efficiency argument based on data? It seems to make sense but have you experienced both paradigms in a working environment?
@@sleekism no data. I’ve only been on the end of full stack… so I honestly don’t know how front end and back end development can be separated how communication and coordination of work can be done efficiently and effectively in a way that doesn’t just add time in comparison. When you develop the backend and front end together, nothing needs to be coordinated because you just do it together. Happy to hear others insights into how it works.
@@br3nto What you've outlined makes sense to me
For Rails my recommendation for you
1. Increase the quality of the documentations as still some pages are shown as in progress for years.
2. Build something official railcasts so that more people will come.
3. Build more official high quality gems.
Everyone likes rails but official learning resources are limited compared to other stacks. Also gems in git many of them are outdated.
Cool. Thanks. That's all I wanted to listen.
I too enjoy sending at least five network requests to filter a list through a search box.
@@emilz0r This is a bit tong-in-cheek as we know that for local interactions SSR folk still use JavaScript. David is just making making a line on the sand to stand on one side.
You have to do that anyway, just with JSON. It's the same thing. Unless you plan to dump your entire db table into the frontend. Which, by the way, you can absolutely do without something like React. It just breaks down when you're making something past a toy app. Whether you're using React or not, your data retrieval patterns WILL live in the backend, no matter what. So you don't gain anything from extra client side code, besides complexity.
Why is he sitting in a door way?! 😆
I love this man, The DHH ❤
Serverside applications in my experiences tend to get less snappy, less userfriendly cause they just too far from the input and events in the browser.
Also Backend Devs tend to Fokus on what's the easiest for the architecture they've built and not what makes most sense and value for the user. There is even more to say I guess. Will create a talk about it maybe
@@emilz0r yes that's true as well. If it's a website I pre render statically. Done. I usually differ between apps and websites
Hell yes, server side rules.
Always preferred Laravel over Rails, but I do appreciate DHH's sentiment here, and I agree that the pendulum has swung too far towards FE everything these days. That said, some FE code is not a bad thing (although I'm not a fan of how Hotwire does it).
Great advice
I agree with David.
Notice that you did not give really any justification or pros/cons.
As is, pretty useless video.
Rudy on Rails
He's absolute marmite but the guy speaks a lot of sense
He's a mermaid?
@@gradientO mermaid on toast
Backend vs frontend is also a battle of millennials vs zoomers
Ah one of of my favorite people in the world
I've heard of this guy before 🤔
Davis Kenneth Robinson Deborah Thompson Maria
There are values in both. JS can be used to reduce network roundtrip, UX and SSR is great for speed rendering and better at security management.
So.. SSR framework FTW.
HTML is great until you need a non-web client like a mobile app
What he is missing is that using JavaScript does not mean you need to do all the work on the client, there is a thing called JavaScript on the server he might not have heard of it.
Yeah he seems like getting started with web dev ...
Palabras de un NO PROGRAMADOR
meh. im just gonna stick with Next.Js
Man there is literally nothing more trash than Ruby on Rails. It’s like the guy made it for himself, the adoption is weak, and nobody likes the syntax
Nobody? Not me included.
I love Rails
I love Rails
What don't you like about the syntax?
@@doubleandy what do you hate about Ruby?
It pays my bills, that is why I love it
Ugh this guy. Not a great look Honeypot. Rails is fine, Ruby is fine, and the debate about SSR is great. But not from DHH.
Why?
@@nafcho1because he doesn’t allow political debates to take place at his company. This is apparently “evil” in the eyes of politically deranged Americans, even though it’s literally considered polite in every other part of the world.
@@consumedata4544yeah, imagine wanting the people who you pay to work actually produce something, rather than engaging in endless political debates that never change anyone’s minds! 🤯
@@consumedata4544 who wants to debate politcs haha. I wouldn't want to do that in or out of the workplace, but especially not in the workplace