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…
Maybe RoR is easier. React also seems to change daily, hence a need to keep searching for today's solution. To yesterday's problem...
Yeah. I've done the server-side thing quite a lot. I don't like it. You always end up with "little bits" of javascript code strewn about in your DOM doing adhoc manipulations based on user events, server data arriving etc., and so the actual behaviour of your app is more difficult to reason about. Also, I want my users to have a nice experience and enjoy using the app, even if I don't have a KPI to represent that ben…
I don't follow this logic. Why do you end up with JS strewn everywhere? Sounds like poor organization practices. 1. User arrives at a page where a real-time widget may exist. widgets/mywidget.js on that page. 2. User triggers mywidget.js by pressing a button or just existing. It dynamically creates the widget elements, requests a secure websocket, then sets up input/output handlers. 3. Done. mywidget.js could be big…
What happens when your backend and your frontend both need to generate markup? How do you keep both in sync? Do you need to make changes twice?
I surprised how few people have mentioned Remix. It's very Rails like (don't make me think). Albeit, Rails makes you have to think even less, Remix is headed in the right direction.
"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.
Call me crazy, I’d just rather read the relevant section of code I am working on and be able to understand it from there, rather than first having to understand the entire universe.
When working with a framework, it helps to understand the framework. Then, all the individual pieces make better sense. The advantage is that you only have to gain this understanding once.
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".
Rails has a templating system for generating emails (standard HTML/ERB files). If you're running an ASP.NET Web API (not MVC) the best way of doing that I've found is via RazorLight which you have to set up manually - https://github.com/toddams/RazorLight
For authentication, with Rails the standard is pretty much Devise or Omniauth (or both) - does everything for you. I've never found anything for ASP like Devise which gives you an entire registration/login system with all the required views/models/migrations in a couple commands.
The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core. * React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web f…
Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally): * should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know? * should I introduce Typescript to be able to handle complexity better? * which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?! * whi…
Why wouldn't you just use a JS framework that takes care of all of those questions for you?
Perhaps I missed it, but the single biggest reason that I moved away from SPAs (such as React) and back to server-side rendering of templates is avoiding having to model my data twice. That’s a lot of overhead. Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing application…
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.
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…
I have the exact opposite experience. I have done a lot of Java - Spring, Node + Angular / React development. And having just started a job with Ruby on Rails, I have never found a new language + framework + ecosystem to be so easy to jump in on and learn and understand. The convention over configuration works really really well.
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.
The problem with Rails is not a lack of blog posts or docs, it's that there's often no way to find what doc you need to read without already understanding the framework. Reading the entire docs and then trying to remember and understand it is a style under which some people learn well and I think it is important for mastery, but the ability to trace back and understand a small piece of a framework is valuable too especially when you're first starting out. Certainly when I try to understand something with node or js libraries I don't jump to blog posts, but I am usually able to find what I need to google to to get the docs I want. That wasn't the case with rails when I was first starting
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…
I’m not sure if this is still a thing but I remember the Rails community being obsessed with aliasing methods and other ways of dynamically defining code at runtime. Coupled with the fact that Ruby is already hard to statically analyze and ‘grep’ is your only hope… good luck following the alias_method_chain rabbit hole…