41–50 of 533 posts
I think if Rails had focused on giving real first party support to interoperability with whatever frontend framework you brought to the table it would be so much bigger right now. They put a lot of work into Hotwire but I just want to use React, and I'm sure others want to use what they're familiar with.
Many teams use this with React.
I’ve written a bit of rails and still don’t really get what the raving is about. It was perfectly fine, I didn’t find anything extra special about it. Having just hit severe scaling issues with a python service I’m inclined to only write my servers in Go or Rust anymore. It’s only a bit harder and you get something that can grow with you
There's really nothing to rave about because the ideas it introduced have all become standard. Rails is aggressively OK.
Like yeah, I know you can do it. But it was much more effort to do things like writing robust migrations or frontend templates. I’d love to find something in Go or Typescript that made me feel quite as productive as Rails did.
I switched from Rails to the node.js ecosystem back in the 3.2 to 4 transition, however looking back I share a similar sentiment as the OP. I recently initiated the backmigration and my approach thus far however has been to take out the "administrative" part out into Rails to benefit from all the useful conventions there, but keep the "business services" in JS or Python and have the two communicate. Best of both worl…
Rail is probably one of the most intuitive framework that I have ever used. No doubt it is highly opinionated but it hides all the complexity for small to medium applications.
It’s funny how some claim it’s intuitive while others complain about its magical nature.
I never really got the appeal of SSR, and I've implemented it a cuouple times with Next.JS and things like htmx. Can anyone come up with the ideal use case where SSR shines? I'm willing to buy it if I see it.
Most websites are significantly simpler to build and maintain with SSR and traditional tools. An entire generation has forgotten this it seems and still thinks in terms of JS frameworks even when trying SSR.
As one example take this website, which serves the page your wrote your comment on using an obscure lisp dialect and SSR.
Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router,…
I believe allowing the dynamic loading of scripts was a mistake, and we should undo support for it. So were iframes. Everything after ready should have been static content.
Rails is still wonderful. But someone should fork Rails so it ceases to be associated with DHH. CEOs who reveal who they really are become really toxic to the brand. We've seen that happen with Tesla.
When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving” ? The answer is always: put text on screen . When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.
When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving” ? The answer is always: put text on screen . When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.
The reasons I prefer client-side rendering: (1) separation of concerns UX in the front, data/business in the back (2) Even as a back-end dev, prefer Vue to do front-end work rather than rendering text + scripts in the backend that run in the browser, (3) at scale it's better to use the client hardware for performance (other than initial latency).
When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving” ? The answer is always: put text on screen . When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.