Don't make me think, or why I switched to Rails from JavaScript SPAs
91–100 of 490 posts
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#92read quite some articles like switching from SPAs to rails|django|laravel, basically from the new cool kid back to the old man in the backyard. but, what about using Go with its web frameworks(e.g. Gin), it has everything you need to build a web application, and it could be all in one binary, and if you want to scale it's not hard too.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#93Am I the only one who simply looks at the business requirements when considering an SPA? Ive built music players, games, real-time chat apps, etc that would be very difficult or impossible with a server side rendering app.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#94I recently started a new project in the same stack [1], and partway through paused because it was taking so long to deliver customer value. I jumped back into Rails, inspired by their new Hotwired framework [2]. And, holy shit - the speed of development became insanely quick. Not only that, but I've been able to achieve a higher level of polish than I would have with a single-page JS app. Specifically - building in real-time updates only took a few lines of code. It was possible to achieve this level of polish with an SPA, but realistically it would have taken me so much time that I would have never prioritized it.
I hadn't touched Rails in over a decade. As a junior developer, I felt overwhelmed because Rails had solutions for so many problems I had not yet encountered. But, returning to Rails with some more experience - I appreciate its "omakase" [4] approach so much more. So many best practices are built in or easy-to-install. Queues, cron, async jobs, audit logs, email click tracking, end-to-end testing, real-time updates, caching, sessions, URL slug "friendly IDs", image resizing, rate limiting, admin interfaces, rich text fields, S3 integrations, sitemaps - they all just work!
With the new Version 7, Rails is truly a "One Person Framework" [5].
[3] https://bookletupdates.substack.com/p/comments-directory-and...
[4] https://dhh.dk/2012/rails-is-omakase.html
[5] https://world.hey.com/dhh/the-one-person-framework-711e6318
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#95I used to write Rails professionally for many years This comparison isn't a good one. Rails is an all-encompasing framework. If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have. --- EDIT: To clarify (because it is confusingly named), NestJS is a framework mode…
The point here is that you do not have to think about choices, there is a "rails way" for every problem. There is no such thing as "the node way". They are hundreds of ways, some of them are dead ends.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#96Earlier quoted context omitted.
The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core. * React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web f…
> Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core Maybe 5-10 years ago, there is no need anymore > React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework. Depends on your needs. Small app? React on its own is enough. Larger app? Add a router. That…
> The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.
Which command would that be? Sure it's one command if you use one of a billion template projects, but just picking one of those is a chore and I'd never call that situation "amazing".
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#97It is not harder at all as long as you do not commit to those giant frameworks and accompanying toolsets. I wrote decent size SPA using couple of libs and plain JS. Was fairly easy.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#98Have any of you tried .NET?
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#99Am I the only one who simply looks at the business requirements when considering an SPA? Ive built music players, games, real-time chat apps, etc that would be very difficult or impossible with a server side rendering app.
There are definitely apps that are only possible using SPAs. Using a front-end framework should be based on business need, not personal preference, but unfortunately, boot camps and the like are churning out developers who are being taught that every problem is a nail.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#100Perhaps I missed it, but the single biggest reason that I moved away from SPAs (such as React) and back to server-side rendering of templates is avoiding having to model my data twice. That’s a lot of overhead. Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing application…