The creator of Rails on JavaScript FE vs. Classic Server-side Rendering
Vložit
- čas přidán 27. 07. 2023
- Where should your logic live? Frontend, backend, somewhere out in space?? David Heinemeier Hansson, creator of Ruby on Rails, talks about what worked for him when you have a small team (and what might work for you). He also tells us a little about Hotwire. Watch the video to find out!
Check out the home for untold developer stories around open source, careers and all the other cool stuff developers are doing at cult.honeypot.io.
Honeypot is a developer-focused job platform, on a mission to get developers great jobs. Wanna see what we're all about? Visit honeypot.io to find a job you love.
To learn more about Honeypot: bit.ly/47clUXJ
Follow David Heinemeier Hansson:
Website: dhh.dk/
Podcast: 37signals.com/podcast/
Twitter: / dhh
Follow us:
Twitter: / honeypotio
Facebook: / honeypotio
LinkedIn: / honeypotio
Instagram: / honeypot.cult - Věda a technologie
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 😀
czcams.com/video/NaEG5Dz7xzM/video.htmlsi=9lJx12kFe8zsV7Lx
We need the full conversation, please. So much practical insights
As a web dev for 20+ years, couldn't agree more with him.
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.
SSR with your framework of choise + HTMX seems to be a nice solution these days.
Since you've come to the client side vs server side arena, it's time to expect some Svelte content :)
Cool. Thanks. That's all I wanted to listen.
What if my favorite programming language is js/ts?
I agree with David.
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.
I love this man, The DHH ❤
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.
The way you would it until recently in next was that you made your backend logic in whatever language and exposed as json api endpoints and then use next for fetching initial data from those apis and render the initial html server side, but basically just writing front end code in next that happen to also run on the server (for the initial fetch and render)
As for the "why", you might have alot of backend logic and alot of frontend logic which are different ways of thinking about an application and you might want experts in each field only focusing on their area without to much need for syncing development other that planning the json interface between the two
@@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.
Great advice
I too enjoy sending at least five network requests to filter a list through a search box.
I enjoy more filtering a list by refreshing the entire page for each click and send the user to the top of the page and make them find the list filtered further down themselves
@@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.
@@rickdg oh, I see now. You were promoting not doing everything on the server because you don't need to involve the server in everything, while I though you were doing the opposite because using js (for sending Ajax requests) are bad and you just wanted to drop js altogether
Rudy on Rails
Why is he sitting in a door way?! 😆
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
I agree for applications, but most web pages are just pretty content with little user interaction other than links, so for those solutions it would make sense to make everything backend
@@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.
He's absolute marmite but the guy speaks a lot of sense
He's a mermaid?
@@gradientO mermaid on toast
I think like you, why use Javascript for frontend that has such a complicated syntax
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.
How does JS reduce network roundtrip?
I've heard of this guy before 🤔
Ah one of of my favorite people in the world
Backend vs frontend is also a battle of millennials vs zoomers
HTML is great until you need a non-web client like a mobile app
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