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

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

#331

Post by akarlsten » Fri, Feb 04, 2022, 7:01 PM UTC

prescriptivist wrote: post #232

Rails and Ruby bake in a lot of really nice, ergonomic features for every day programming, not just larger architectural decisions. For instance I am working on a React Native app in my spare time and so much of Javascript seems tedious. Example is dealing with date ranges. Contrived example: import { isWithinInterval, subDays, addDays } from 'date-fns'; const today = new Date(); let range = { start: subDays(today, 1…

In my opinion having to be explicit about what imports are used where makes the code more readable. There's never any "mystery" methods suddenly being called in the middle of a complex function (sometimes without a namespace so you're not even sure which library it's from), and I suppose it makes stuff like tree-shaking easier as well.

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

#332

Post by sytse » Fri, Feb 04, 2022, 7:05 PM UTC

crftr wrote: post #169

sytse wrote: post #70

Earlier quoted context omitted.

Yes, RedwoodJS seems like Rails for JavaScript. Recently I’ve also been impressed with Remix that was mentioned in the article. It seems to have solved the client server code duplication problem while still offering the benefits of both.

Without knowing if it's possible, I really want to see a RedwoodJS w/ Remix proof-of-concept.

That would be awesome.

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

#333

Post by jconley » Fri, Feb 04, 2022, 7:06 PM UTC

If anybody wants to help solve this problem, hit me up. :) Working on it...

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

#334

Post by rmbyrro » Fri, Feb 04, 2022, 7:07 PM UTC

MakerSam wrote: post #192

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…

Never thought from this angle and it does make sense. Probably doesn't explain all the difference, but a considerable part of it is not unreasonable to assume.

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

#335

Post by rmbyrro » Fri, Feb 04, 2022, 7:09 PM UTC

jmondi wrote: post #228

MakerSam wrote: post #192

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…

Shouldn't we read the docs for everything we use?

I'm appalled everything I realize most developers don't actually read docs... It's unbelievable. Do we expect things to work the way each of us imagine? Or what do one expect when starts using something without reading the documentation?

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

#336

Post by weatherlite » Fri, Feb 04, 2022, 7:10 PM UTC

wonnage wrote: post #326

weatherlite wrote: post #272

Earlier quoted context omitted.

Saying that mixins and callbacks are always incomprehensible is silly. They're just a way to pack up code and they can work beautifully. If you don't wanna use them you're gonna have to write the logic in some alternative way, so a bunch of service objects I guess? Does that automatically make code comprehensible - the fact it's using many small classes? I'm sure people can and are writing shitty services as well.

There’s nothing more frustrating than debugging some ruby module with 10 different mixins defining functions with generic ungreppable names like “user”. Then it turns out the mixins have mixins. The common refrain is well, don’t write shitty code then, but all code starts off looking good to the person who wrote it. I guarantee if you have 400 engineers working on a Rails app it will end up in this state because it (…

Rubymine's autocomplete got to a state where I barely ever have to grep anything.

Look what you're describing can happen, it's just not that often or is the norm. It's usually some crappy legacy project no one wants to upgrade or touch that reaches such a state, there's absolutely no reason why what you described can't be refactored. The fact it isn't being refactored tells you more about the company/teams working on it than about the framework.

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

#337

Post by bdcravens » Fri, Feb 04, 2022, 7:10 PM UTC

jack_riminton wrote: post #294

bdcravens wrote: post #122

If you can easily switch to a framework like Rails from a SPA, it's probably a sign your app shouldn't have been a SPA. There's too much "defaultism" in our industry.

Agree, unless your UI is very interactive and complex e.g. a photography editing app then you can likely go without an SPA Your designer might be pissed, but your customers probably don't care all that much and your CEO is going to be pleased at the speed, stability and simplicity of what you've created.

I've run into plenty of apps that don't really look that great yet are SPAs. Like basic form post kind of sites. As I mentioned elsewhere, I got blocked paying a student loan due to one, and had to jump into Devtools to get a broken CVS app to submit a prescription request.

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

#338

Post by purplerabbit » Fri, Feb 04, 2022, 7:13 PM UTC

TheRealDunkirk wrote: post #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 th…

I dislike it because I prefer code over configuration OR convention.

Please give me code I can understand-by-reading and not code I have to understand-by-synthesizing-with-a-non-collocated-knowledge-set.

This is why the “worse” of golang is better than the “better” of rails

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

#339

Post by weatherlite » Fri, Feb 04, 2022, 7:17 PM UTC

stereocodes wrote: post #254

regularfry wrote: post #42

Earlier quoted context omitted.

Yes, but the problem is that there's still nothing in the node ecosystem that's as complete as Rails. Fine, express.js isn't going to do the job. Neither is anything else.

As the other commentator pointed out there are a few options that do have a complete setup. NextJS, SailsJS, and Gatsby to name a few.

Yes Next, Nest, Sails, Gatsby, Blitz, Redwood - none of them became a leading framework like Django or Rails or Laravel has, which means being a Node developer and moving between companies or projects you'll probably relearn everything in a different framework. For me this is just to chaotic and unstable.

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

#340

Post by weatherlite » Fri, Feb 04, 2022, 7:20 PM UTC

endisneigh wrote: post #80

regularfry wrote: post #42

Earlier quoted context omitted.

Yes, but the problem is that there's still nothing in the node ecosystem that's as complete as Rails. Fine, express.js isn't going to do the job. Neither is anything else.

This isn’t really true though, NestJS for example is very opinionated and similar. The issue is more that Node and JavaScript in general is too popular and there are way more options whereas ruby is rarely used for non rails work.

Python is plenty popular and so is C#, and when you're looking at a batteries included full stack framework you have ONE popular choices - Django or .NET. For PHP it's Laravel (sure, you have other options like Symfony but they are niche), for Elixir its Phoenix. How is it a good thing for Node to have 5-10 competing frameworks that have similar adoption?