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

381–390 of 490 posts

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

#381

Post by radus »

khalilravanna wrote: post #317
continuational wrote: post #298

Earlier quoted context omitted.

There are a lot of solutions out there where you can share your datatypes between the client and server now though, and it's great!

This comment would be more helpful with some examples. I’m personally very curious what the leading solutions are. I’ve worked with one involving GraphQL but that’s about it.

Maybe this isn't what the GP comment meant, but I think codegen can serve this function pretty well nowadays. I'm currently working on two separate projects, the first is a Django project with DRF and I codegen with drf-spectacular [1] and openapi-typescript-codegen [2]. The other project also uses Django, with the API through Hasura and codegen with graphql-codegen [3]. In both of these cases I've been able to largely avoid duplicating my models clientside, or at least it isn't manual.

1: https://github.com/ferdikoomen/openapi-typescript-codegen

2: https://drf-spectacular.readthedocs.io/en/latest/

3: https://github.com/dotansimha/graphql-code-generator

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

#382

Post by midrus »

wefarrell wrote: post #158
PragmaticPulp wrote: post #128

Earlier quoted context omitted.

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…

"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." You could replace SPAs with almost any technology (Queues, Kubernetes, an RDMS as opposed to BaaS, Servers as opposed to lambdas) and it would be correct depending on your own background and personal bias.

Can confirm. I once had as a team me a weirdo that would refuse to run ANYTHING on his computer outside of docker. From git, to his browser, to the mail client, to the editor...everything had to be in a container. His Thinkpad had more containers that our entire production cluster. What a waste of energy and time.

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

#383

Post by mmanulis »

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…

Been working with Rails close to a decade now. I've built several, non-trivial products using Rails for the API, by myself. What I and my coworkers dislike about Rails is the sheer amount of magic. Oh and concerns, let's not forget that pattern.

Rails is amazing at standing up a CRUD app (really API) in a matter of minutes. I can have a basic CRUD app with authentication, authorization, API, caching, background jobs, local development (docker compose), production in any cloud / k8s and CI/CD done within a day. Adding business logic that's well tested is simple.

Once the app starts to get serious usage, needs to integrate with complex enterprise systems, handle huge loads of data, etc. it becomes necessary to step away from Rails-way of doing things. All of a sudden you can't push more into Sidekiq cause of how much it impacts the DB via ORM loading. Now you're writing custom SQL. It's not all that hard to do in Rails, but at that point, you're writing Ruby and not using Rails magic any more.

Your dismissive comment does not address the realities of building a solution that goes beyond CRUD. It ignores the many levels of experience present on a team or the amount of technical debt one accrues while building a non-trivial production system.

While it doesn't take much experience to get started with Rails or to get a good amount of progress on a product, it takes skill to keep the technical debt under control. Or to make good decisions about architecture. Or to understand which parts of the system to optimize. It requires actual experience building web solutions without the crutch of a framework to know when to ignore Rails and when to double-down on it.

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

#384

Post by multiplegeorges »

Unbeliever69 wrote: post #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 a…

> This has almost inspired me to build my passion side-project in Rails to get my mojo back. Thank you.

Try it out. Rails 7 has a really interesting view on frontend dev with importmaps and Hotwire.

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

#385

Post by pavelevst »

If stay away from serverless, cloud databases and “doing everything on frontend”, then it solves most of problems mentioned in article

But rails and ruby still has many good parts. For example global classes and ruby threads to save per request context.

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

#386

Post by phtrivier »

Rails after more than a decade of development has a head start over react with about half a decade.

Also, it's comparing spas and server side, which, suprise, is not the same thing.

'rails new' should be compared to 'create-react-app' - it's just not official _yet_

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

#387

Post by jacquesm »

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…

Or maybe the documentation for the one is better than the other.

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

#388

Post by boredtofears »

chowells wrote: post #358
sodapopcan wrote: post #268

Earlier quoted context omitted.

I was going to say the same thing and figured someone else already had. People would often ask how I knew so much about rails and, ya, the answer is that I read the guides. They are extremely readable and it doesn't take that long. Like a couple of days. You might be surprised how much is retained by just reading through them, even without actually trying things out as you go. I would like to stress: read the guides,…

I've skimmed the guides. They never contain anything useful. They're just a bunch of recipes. They don't actually document a darned thing. Programming is not regurgitating recipes without understanding. Copilot can do that. Programming is actually understanding both the problem domain and the solution space, and knowing how to find some permutation of elements in the solution space to address anything in the problem…

Err, wouldn't you look at the source for most of these things? What framework do you use where that isn't true?

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

#389

Post by ryukoposting »

matt_mb wrote: post #248
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…

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

It's the single most irritating interaction I have had with a coworker, and I have had it at least once at every job I've ever had.

"Hey, thing xyz is super confusing, can you (help me use it|explain how it works|rewrite it so I understand it)?"

"Did you read the document I sent? The document (has sample code that does the thing you're trying to do|explains how it works|explains why the simpler approach doesn't actually work in practice)"

"...No."

It's incredible how some devs can learn 15-20 different programming languages, and completely forget English in the process.

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

#390

Post by DanHulton »

I mean, this is why I wrote Nodewood: https://nodewood.com/

I strongly prefer the explicit nature of JS programming, where you don't have to know a bunch of Rails-y magic to know where a certain symbol is coming from, it's just defined in the file you're working in (to pick one example). But I completely agree that the time from Start to CRUD in Rails is a killer app.

I keep kicking up new projects in my spare time, and for every one of them, I'd have to set up the application scaffolding, linting, set up a layout and basic design rules, figure out user management, and if I was getting serious, set up subscription management, team management, etc. Rather than rewrite it every time, I figured I could make an actual library out of it so I have a decent base to work from, and then turn it into a product, because I can't be the only one who has these similar issues.

Also, Nodewood isn't alone out there - there are all kinds of Rails-ey bootstraps or starter kits out there for all kinds of languages. Now, the fact that everyone thinks "Ruby" and immediately thinks "Rails", but they don't think "Node" and immediately think "and a starter kit" means Rails has performed some amazing marketing mojo, but that doesn't make it fair to compare JavaScript to Rails, the author should be comparing JavaScript to Ruby, or Rails to a Rails-ey bootstrap.

Post reply on HN