Live data from Hacker News

Don't make me think, or why I switched to Rails from JavaScript SPAs

reviewbunny.app

281–290 of 490 posts

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#281

Earlier quoted context omitted.

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.

> There is no such thing as "the node way". And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals. If it turns out your goals are a very simple crud app for a team of under 5 - Rails is probably a great choice. For most everything else, you should probably understand why Rails made the choi…

> Rails is still good, but I find it has a distinct "ASP.net classic" feel to it now - Too many versions, too much change,

Well Rails is gonna celebrate 20 in 2 years, so yes there's quite a lot of versions and changes over the years, that's inevitable for every long running project I think.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#282
This article really resonates with me but not because I've been down the same path. Back in 2011 I learned Ruby as a hobby language and from the beginning I fell in love. Probably because of my OOP background as a programming hobbyist since the 80s. A few years later I did a career pivot away from Ux into programming and after a brief stint in Java, my research just naturally funneled me to the Javascript ecosystem and full-stack development. Thanks Ryan Dahl!

But I wasn't happy in Javascript. It wasn't because I was stuck in my OOP brain. I didn't fight it. It just took a long time to embrace declarative programming. In 2018 I attended a bootcamp (Dev Mountain) and learned a single stack that, while opinionated, didn't bring me any fulfillment as a programmer. Mainly for the reasons you described. Too many choices. Not enough opinion. Too much flavor (fatigue) of the month. But mainly, I don't have a lot of joy like I felt when I was doing Ruby.

Fast forward to 2022. My company (a small 3 man development team) has been working on a greenfield project for three years. A massively complex project for such a small team, but finally we are done. Yay. But boy has the journey been wild in terms of our stack evolution. The thought of building a side project in the JS stack I am comfortable with just doesn't sound fun. I long for the warm fuzzies of Ruby. This has almost inspired me to build my passion side-project in Rails to get my mojo back. Thank you.

For anyone that is interested, my current stack is React (Tailwind CSS)/GraphQL (Apollo and Postgraphile)/Express/PostgreSQL with docker CI/CD and AWS lambdas.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#283

Am 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.

I've interviewed a lot of web devs over the years. The distribution on this question is surprisingly bimodal. One group of web devs is great at picking the right tool for the job. Simple web applications get simple solutions. The complex SPA solutions only get brought out for applications that require it. The other group of web devs has learned one very specific tool and they want to build their career around that to…

A friend inside my company was telling me that they can't have an app written for them in C# because it's NOT JAVA. That .NET stuff is too new and trendy! And probably insecure!

I swear, my Fortune 150 company is going to continue to do waterfall development in Java by outsourced teams until our products are no longer relevant, and we're bought for spare parts.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#284
post #266

Earlier quoted context omitted.

Yep, it builds HTML on the server side and sends it to the browser through normal get requests. Instead of constructing HTML in a mix of JS + HTML (JSX) you typically write a mix of Ruby + HTML called ERB.

Doesn't Ruby also have an HTML-over-websocket library that Basecamp built for Hey and released open source? (at least a year or two ago they said they would release it) This would be similar to Elixir's LiveView I think.

Yep, hotwire. It's still running everything on the server in that case though where ruby templates are generating HTML.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#285
post #228

Earlier quoted context omitted.

As someone who came from other MVC frameworks outside of Ruby, learning Rails has been a cluster-f of searching through documentation circa 2013. The whole rails “convention over configuration makes it easier” is a load of bologna, because the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts. The best way to work on rails is t…

I couldn't have had a more opposite experience. My last job was as a solo dev on a legacy Rails 3.2 project. I didn't even know Ruby when I took the job, but have a lot of experience with other MVC frameworks. Learning Rails has mostly been a breeze with a lot of "I wish framework did it this way, this makes a lot more sense" type of moments. Rails docs are among the best I've ever used for a framework personally. Th…

Agree. Perhaps the original poster was struggling to get to grips with the MVC setup because beyond that Rails is pretty easy to understand

Sure there are bits of 'magic' but you could build an entire AirBnB clone before you'd need to dive into them

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#286
What I've gathered, over the years, is that the people who dislike Rails because it makes a lot of decisions for them think they're just too cool for that. It insults their programming ability. OK, I can see that. So, go ahead; have it your way. But while you're still writing thousands of lines of boilerplate in both the front and back ends, and getting your types sorted out, I'm done with my app, and moving on to the next one.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#287
post #228

Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to…

As someone who came from other MVC frameworks outside of Ruby, learning Rails has been a cluster-f of searching through documentation circa 2013. The whole rails “convention over configuration makes it easier” is a load of bologna, because the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts. The best way to work on rails is t…

the same BS happens with django

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#288
post #59

Earlier quoted context omitted.

I think you don't want to support the article's claims, but you kind of support it by mentionning the choice that you need to make between NestJS and Adonis or any other frameworks. With the ruby ecosystem, there is almost always a clear convention on what to do (example: the conventional choice is to use rails, which leads to a bunch of pre-made choices)

Conventional choice at a framework level isn't really necessary though, is it? I mean, you can read and choose what you like whether it's Nest/Adonis/Blitz or anything else. Once that choice is made everything that follows is opinionated.

Part of the problem I think is that none of the JS frameworks became a clear winner in the full stack batteries included framework niche. For Ruby the clear winner is Rails. For Python it's Django. For C# it's .NET. What is it for Node then - I keep getting many names - Nest/Next/Adonis/Blitz/Sails? And lately Redwood? And probably more I'm missing out? It would have been better for Node if there were 1-2 frameworks with huge momentum behind them then 6-8 frameworks that none of them caught a lot of mindshare.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#289
post #4

I 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.

Is there a such thing as "the ruby way"?

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#290

Have any of you tried .NET?

ASP.NET is great but it definitely comes under the same banner of 'too many choices needed' compared to Rails. e.g. Framework - Which .NET framework do you use (Core/LTS)? Do you use MVC, Razor Pages, Web API and Blazor (Server or WebAssembly) or Web API and an alternative JavaScript/TypeScript based frmaework?. Do you use JSON/XML/SOAP or gRPC? How do you serialize your JSON (NewtonSoft.JSON or System.Text.JSON)? Da…

This comment is ridiculous. You've shifted this from "too many options for everything" to "any options at all". Also, how are these things framework specific? The API vs templates argument also applies for Rails. Choosing an authentication method also applies to Rails. Choosing rendered emails via SMTP vs Sendgrid - also applies to Rails. And so on. You can't mix business requirements with "tooling choices".
Post reply on HN