If you like ruby, please give https://matestack.io/ a try
Don't make me think, or why I switched to Rails from JavaScript SPAs
11–20 of 490 posts
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#12I look at it the other way around, to someone coming from Ruby/Rails, there are far too many choices to make and it can seem very overwhelming. But on the flip side you get very granular control over your projects structure. Like when the author mentioned the framework options:
> Next.js, Remix, Gatsby, Vite, Create React App, Koa or Express?
- NextJS, Gatsby - Best for building "websites" that are optimized for SEO
- Vite, CRA, Remix - Best for building SPA's
- Koa, Express - Backend frameworks.
On the one hand it's very overwhelming, but on the other hand, each framework accomplishes something very specific. Even the differences between NextJS and Gatsby, Gatsby uses a different model for how you would fetch data, with Next you write regular Node code, with Gatsby you do everything through GraphQL.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#13I 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
#14I mostly work in Rails, but when I have to hop into a node project, it feels like I'm stepping back into PHP in terms of sheer madness. Barely any convention, lots of repetition and configuration - all things Rails specifically set out to solve.
PHP hasn't been madness for a long time. One could argue Laravel (a RoR inspired framework) has become better than RoR.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#15It is apples and oranges, but I think that's kind of the point.
Unlike Rails or even PHP, the JavaScript ecosystem is all over the place. If you choose the most popular tools available, there are many decisions to make. Not everyone wants to do devops.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#16I 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…
I can't help but think it is a reflection of the JS ecosystem that I assumed you had misspelled Next.js
I guess Nest.js is actually right: https://nestjs.com/
A TypeScript framework like Rails is a framework for Ruby.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#17I think the author is trying to compare what it takes to create an MVP web-app with all modern features versus creating it in the JS ecosystem. Also, Rails is well known to have Convention over Configuration. That helps to set up and maintain a project since everybody has to follow the same pattern. The cons is that you lose flexibility from the architecture perspective. But in Rails, you have ways to overcome that e…
Couldn't have said it better myself!
A lot of JS tooling that popped up in the last 10 years is amazing. The React way of building a UI makes a lot of sense to me and I like it way more than HTML + JS combo from the old days. Also, using JS for both frontend and backend is convenient and great for hiring teams.
But, after years of making SPAs, it gets tiring to assemble all of the pieces from scratch every time. I don't want to configure things, I want to build my ideas.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#18I 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…
I should've been more clearer. This post isn't comparing Rails to any framework out there. What I was trying to say is that Rails got a lot of things right and it's making me productive, because I don't have to make the same decisions over and over again when making a JS app. Rails made those decisions for me and the only thing left for me is to build my app. I myself like Next.js and Remix a lot, but they still leav…
> I'd love to see more conventions and less configuration in the JS land.
Which is what the parent post is saying NestJS offers. I'm not familiar with it, so can't comment on the veracity of that claim, but I think you might have missed their point, perhaps because they confusingly called it "Nest.js" which could be mistaken for "Next.js".
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#19Choosing something and making a decision is not as difficult as it seems. You don't have to when someone comes along and tells you "we should use pnpm because it's much faster". Before using any tool, you take a brief look at how it works and what it does, and decide accordingly. I don't understand why you see having more than one option as a problem.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#20SPA and Rails are not mutually exclusive.
For a simple MVP, Rails is enough. As features grow and frontend becomes more complicated, you can then evaluate again if you want to move the rendering part into a separate SPA while retaining Rails as API server.
This was the path that my previous company took.