251–260 of 490 posts
The article makes a comparison to react, but that’s a front end library. Does rails also do front end?!
Yes, Rails has a view layer (frontend).
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…
Not copying and pasting that code chunk and wrapping it into a utility function :red-flag: :red-flag: :red-flag:
Obviously you can wrap them in a your own interval function which does the same thing. So like:
function myOwnIntervalBetweenFunction(date, offsetBefore, offsetAfter)
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…
Rails draws the attention, but there's plenty other uses.
Earlier quoted context omitted.
As the commenters pointed out, Express.js doesn't try to solve the same problems as Rails. Trying to use one for the other's use case doesn't make any sense.
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.
I don’t fully understand the issues people have with JavaScript and especially React. Maybe it’s because we invested some time in setting up a baseline project with ESLint, prettier and a TSConfig that makes for an entirely fascist way of doing TypeScript that just happens to always work. Maybe it’s because we don’t NPM install a lot of things, but instead take what we need and build our own packages (riding free on…
React is great until you have non-trivial state management then life starts to suck again. The # of react apps I've seen where every key press entered into a form takes 200-500ms is super high. Heck the first version of Work At A Startup here on HN had input box latency problems that looked a lot like what I see in React all the time. It is funny because Redux's religious adherence to a const store makes no sense. Su…
I agree. This is a bit where the lack of frontend seniority tend to show it's colors in my opinion. People try to fit every use case onto e.g. Redux (or the even less competent useState) and then try to throw middleware at it to solve all of the complexity they're drowning in.
Frontend really should utilize more powerful state management tools (when necessary of course), e.g. Observables or Finite State Machines. We're using hammers to solve problems that require screwdrivers.
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…
For me, learning how to learn a new thing at times seems like the hardest part for me. For Rails, the best I've found is the Michael Hartl tutorial [1]. He walks you through setting up a blog with Rails - first the quick way and then the hard way, so you walk away with a nice understanding. He keeps the tutorial up to date and he's been available for questions when I've emailed him. It costs a few bucks ($39) but well worth it IMHO. I spent a few weeks going through that book, did a few apps on my own, and then was able to create new apps fairly quickly.
The official Rails Guides are a great resource too and kept up to date too [2].
Configuring your local rails development environment is pretty easy with the thoughtbot laptop script [3], otherwise it can be kind of a pain to do it from scratch.
[1] https://www.learnenough.com/ruby-on-rails-6th-edition-tutori... [2] https://guides.rubyonrails.org/ [3] https://thoughtbot.com/blog/laptop-setup-for-an-awesome-deve...
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…
Rails docs are among the best I've ever used for a framework personally. They blow most things in the JS ecosystem out of the water.
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…
There is no "Core" anymore: LTS is now .NET 6. If you are building webpages, the "Legacy" .NET Framework 4.x is no longer relevant in any way (unless you are unlucky enough to have legacy apps with no drive/budget for cleaning up tech debt, and I'm sorry on your behalf). The last LTS "Core" version (.NET Core 3.1) is out of support in December and the upgrade path is simply .NET 6. There's only one choice right now and it is .NET 6. (It'll complicate a bit with .NET 7 in a few months, but only in the alternating LTS/"current" versions way of things like NodeJS, nothing like the Core/Framework confusion of the past few years.)
> MVC, Razor Pages, Web API and Blazor
MVC and Web API merged many moons ago, it's not really a choice between them, they use the same APIs and are built the same way way today.
(Editorializing: Razor Pages is making many of the same mistakes of ASP Classic or PHP/ColdFusion over again, and I don't see it as a great choice personally. Blazor is making similar mistakes to both Razor Pages and Silverlight, and really feels like ASP Classic 2.0. I understand its appeal to some development teams, but wow does it seem like a clunker from my vantage point.)
The article makes a comparison to react, but that’s a front end library. Does rails also do front end?!
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.