Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

reviewbunny.app

Post reply on HN
Print view View original

271–280 of 490 posts

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

#271

Post by MakerSam »

andrei_says_ wrote: post #243
jmondi wrote: 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…

What are some specific “magical things” that are not mentioned in the rails guides? There’s always room for improvement and the documentation is an important part of the framework.

I don't think the Rails Guides mention Devise, the authentication gem, which is pretty important if you want create a public facing website with users. The devise documentation is pretty good though. Again, a little bit of a learning curve, but once you learn it you can add user authentication to your site pretty quickly.

https://github.com/heartcombo/devise#getting-started

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

#272

Post by weatherlite »

emodendroket wrote: post #250
jmondi wrote: 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…

If that's not bad enough you're probably working on a legacy app with a whole bunch of mix-ins, proxies, Active Record callbacks, and other nonsense that makes it nigh on impossible to understand what any code does.

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.

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

#273

Post by qbasic_forever »

philip1209 wrote: post #94

I built my last company with Go, Vue.js, gRPC, and Kubernetes. And, wow was it a slog. It was hard for new developers to jump in, we had separate engineers for frontend + backend, and there were things we never even touched - such as real-time/websockets or end-to-end testing. I 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…

I wish the Go community had a popular monolith framework that folks rallied behind using when necessary. Unfortunately it's a wild west of bodging together your own routing, config, auth, etc. and nothing is consistent.

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

#274

Post by TheRealDunkirk »

usrusr wrote: post #66
Cthulhu_ wrote: post #27

Earlier quoted context omitted.

I think the main Thing here is that Rails is the de facto standard, the 'golden hammer' of Ruby based apps, and there is no space - or developers - for alternatives. The JS ecosystem as we know it today started years after Rails (Rails was 2004, Node's oldest version on their releases page is from 2011), and only really took off after NodeJS came to prominence with frameworks like BackboneJS, Angular, then React and…

The dominance of Rails for its use case within the field of Ruby is is only one half of the equation. The other half is that Ruby has mostly collapsed into Rails, there's not much Ruby happening outside of Rails. This could never happen with a js framework of similarly scope, because all the other js use cases won't go away. One example of such a thing that won't go away is doing client-side stuff in the scope of a R…

Ruby is a wonderful language for other things outside of Rails. I'm old. I've done csh, bash, perl, tcl, and python for scripting and miscellaneous programs. Since discovering Rails, I use Ruby for basically everything now. The only miss I've had in recent memory has been needing to do heavy statistical work with R for speed reasons, but, then, you're not going to do that in JS (or anything else) either.

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

#275

Post by jmondi »

mirekrusin wrote: post #260
matt_mb wrote: post #248

Earlier quoted context omitted.

"Reading docs top to bottom" is the answer to this frustration. It's strange that people don't think this is something they should do.

When people ask me how to improve their programming this is my first advice - speed read docs/stdlib top to bottom and keep writing a lot of little things. It’s amazing how many people choose painful path of learning through osmosis.

If you want to make an app from scratch, you must first understand the universe.

This is a ludicrous approach for most. Sure, if you learn from reading and love to read technical manuals, go for it. But to imply this is the best way for most to learn is completely ridiculous.

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

#276

Post by gls2ro »

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 Ruby it also works a simpler version:

   (Date.yesterday .. Date.tomorrow).include?(Date.today)

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

#277

Post by Oddskar »

stereocodes wrote: post #237
Oddskar wrote: post #167

Earlier quoted context omitted.

The answers to this in 2022: 1. Doesn't matter so much as long as you're using newest versions of either one. Newest yarn has plugin support which is neat. Npm has more stable backing and an open roadmap. Could be some considerations regarding monorepo support, but otherwise either is fine. 2. Yes 3. Use ES6 modules 4. Jest + Cypress 5. Vite

I agree with this persons answer, if your goal is to go full custom. If you want all this setup done for you I suggest NextJS. It should be noted that Deno is not a bundler but an entirely different JS Runtime. The question should be do I use Node or Deno.

I think for many people NextJS or Nuxt should really be the first choice rather than going for e.g. Create-React-App or some generic boilerplate.

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

#279

Post by TheRealDunkirk »

horsawlarway wrote: post #54
WolfOliver wrote: post #13

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…

> Too many versions, too much change, too many contradicting "opinions" between major versions

Tell us you haven't used Rails much without telling us you haven't used Rails much. There's been precious little I've needed to change in my approach since the 3.x days. The new TurboJS world they're baking into 7 sounds significant though.

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

#280

Post by atmosx »

boredtofears wrote: post #257
jmondi wrote: 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…

Apparently people prefer blog posts to docs. This is not a problem of course, until you need to either debug (hence understand what you're doing at depth) or build something non-trivial.
Post reply on HN