321–330 of 573 posts
Is this the "new magic" that DHH teased on Twitter, or are we still waiting to see what that is? Also, should we expect this to be included in a future version of Rails? My first impression is that the API seems a little convoluted, but that might just be me. In an ideal world, I'd love to just build components (similar to React components) on the server side, and let the framework intelligently handle synchronizing…
But I doubt they'll integrate this into Rails. They'll just create better and better tooling to make using this with rails a cinch.
I think this will just remain backend agnostic, like turbolinks and stimulus were before "hotwire".
Earlier quoted context omitted.
I’m glad this technique is making a comeback. The last 10 years of JavaScript on the client have been an utter shit show that left me wondering wtf people were thinking.
You have the benefit of hindsight at this time. You can draw parallel to history of flight and all the crazy contraptions that people attempted. Great technology can emerge from the combination of numerous shit shows. The whole is greater than the sum of the parts.
This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we ar…
Earlier quoted context omitted.
The backend here _is_ your frontend. This supports my argument that there is tight coupling.
Between what? Your frontend is serving the html/css/js, that's your frontend. You can have another background service behind it, as many layers as you want. This separation doesn't have to be at the http level.
You can update it more freely to shining new JS frameworks because it is not entirely tied to your backend.
Also, if your client/boss asks you to build a native IOS frontend, you already have built an API, useful no?
It took a decade for the industry to realize that JS frameworks were overhyped and the degraded productivity because of them was not worthy. I think they will be replaced by Hotwire-like technologies in the next decade. The same thing will happen to micro services (especially, distributed monolith) and Kubernetes. They are just overhyped. Productivity matters most!
I don't think this is going to happen. Hotwire-like technologies have existed for a long time with turbo-links, adoption is low and it's very unpractical to work with compared to a split backend api + frontend (framework or not as you prefer).
This is just demonstrably false. Both paradigms have areas where they shine. One or the other is not better across the board.
I guess the point of Hotwire is that there isn't pretty much anything you can't do with the "old tech" that you can with the modern javascript CF.
In case anyone from Basecamp sees this thread: The introductory video is far too long, far too technical (I know a lot about web dev but don't know a lick of Ruby or Rails) and far too fast to follow. I was really interested in Hotwire because of the comments here and now… not so much anymore. (Which of course doesn't say anything about the quality of the tech. I just thought I'd post my first impression of the websi…
the tech is dope
Earlier quoted context omitted.
And here's some additional followup. Minor speculation that maybe his location is what caused slowdown. https://twitter.com/swyx/status/1292825527116369922
That's one of the reasons SPA aren't going anywhere: trying to handle all the user microinteractions on the server is great when you leave next to it, but it falls apart when your users are spread across the world, especially if it's not western-ish world with fast internet connections.
I'm a big fan of pure HTML pages because of performance and simplicity, but the techniques presented here are neither of those. For performance, server-side rendering is just bad. It won't scale to high volume traffic, cost too much money and is complicated to maintain. Hosting a static HTML files is more performant than that. For simplicity, the current protocol relies on so much "magics" to give the impression of s…
The comparison is only between server rendered HTML vs backend API + some frontend rendering locally (which is not as performant) and more importantly is a lot more complex to implement technically.