The creator of Rails on JavaScript FE vs. Classic Server-side Rendering
Вставка
- Опубліковано 6 вер 2024
- 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/...
Twitter: / dhh
Follow us:
Twitter: / honeypotio
Facebook: / honeypotio
LinkedIn: / honeypotio
Instagram: / honeypot.cult
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 😀
ua-cam.com/video/NaEG5Dz7xzM/v-deo.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.
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 :)
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.
What if my favorite programming language is js/ts?
Hell yes, server side rules.
Cool. Thanks. That's all I wanted to listen.
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.
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
I love this man, The DHH ❤
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
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.
I agree with David.
Great advice
Why is he sitting in a door way?! 😆
Rudy on Rails
Notice that you did not give really any justification or pros/cons.
As is, pretty useless video.
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).
I think like you, why use Javascript for frontend that has such a complicated syntax
Backend vs frontend is also a battle of millennials vs zoomers
He's absolute marmite but the guy speaks a lot of sense
He's a mermaid?
@@gradientO mermaid on toast
Ah one of of my favorite people in the world
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.
HTML is great until you need a non-web client like a mobile app
I've heard of this guy before 🤔
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.
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