Live data from Hacker News

Ruby on Rails: The Documentary [video]

youtube.com

131–140 of 248 posts

Re: Ruby on Rails: The Documentary [video]

#131

Earlier quoted context omitted.

I'm going to have go push back on this. I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspective. I only occasionally pick up RoR work because of how off-putting my first experience was. But what makes it worse is that every project I've been on (including one I just started on a few weeks ago) has just been a cluster. What you're saying here is true i…

.NET's LTS releases are supported for 3 years and STS are supported for 18 months. I wish LTS support was 5 years, it seems like ecosystem has matured enough post-going-OSS-wild-ride starting with .NET 6 release and is ready for such a support timeframe. Or at least they could have every other LTS be ELTS? Also, I do wonder if RoRs perceived productivity is by inertia? I have a hard time believing you can top the pro…

you're right, looking closer I got my wires crossed.

non-LTS is 2 years, LTS is 3 years

https://dotnet.microsoft.com/en-us/platform/support/policy/d...

imo, short term RoR will beat the pants off asp.net core in terms of developer productivity. mid to long term asp.net core wins hands down in terms of developer productivity.

I don't think the RoR productivity story is fake, but I do think it's not worth the long term maintenance costs.

Re: Ruby on Rails: The Documentary [video]

#132
post #108

Earlier quoted context omitted.

i’m preparing a talk for either railsconf or railsworld that puts this question/concern to the community. two times i have deviated from the standard apps/{models,controllers,views} layout and i have profited massively, especially in terms of conceptual integrity and abstraction. all my code lives in app/lib under domain-specific directories. this includes the models. the only part worth separating is the web router…

IMHO if you're splitting an app into domains you might as well go all the way and split it into an engine or gem.

i doubt. the further down the wedge drives the harder it gets to make the components communicate, and i think when communication gets hard we’ve probably gone too far. that’s not even taking into consideration the mechanisms of managing engines/gems.

Re: Ruby on Rails: The Documentary [video]

#133

I had a lot of fun watching this documentary. The one person framework really comes out in the personal story of Toby from Shopify. "From Hello World to IPO". What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. Sure that can be true for many apps, but in a world of, for example, APIs and f…

I'm going to have go push back on this. I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspective. I only occasionally pick up RoR work because of how off-putting my first experience was. But what makes it worse is that every project I've been on (including one I just started on a few weeks ago) has just been a cluster. What you're saying here is true i…

I think you have encountered some projects built by undisciplined teams. That is not a reflection on the framework, rather a reflection on the people improperly using it.

Re: Ruby on Rails: The Documentary [video]

#134
post #17

> if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years. Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. An…

The key is to build a Ruby app and then provide HTTP access and persistence using Rails. You can find a lot of articles about this by searching for Rails and hexagonal architecture.

My biggest issue with trying to do this is ActiveRecord. I'd much prefer the repository pattern.

Re: Ruby on Rails: The Documentary [video]

#135
post #78

Earlier quoted context omitted.

I've wondered about this for years. Express was the default with Node for some years but it was mostly used for APIs to feed front ends. These days lots of people have switched to Fastify but again mostly for APIs. There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django. Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components…

> There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django. I would like to introduce you to Adonis. https://adonisjs.com

It's cool. Another similar option is Platformatic by the creator of Fastify.

https://platformatic.dev/

But still... There are no queues or jobs. No HTML over the wire. No colocation of presentation logic. Etc.

Re: Ruby on Rails: The Documentary [video]

#136

I tried to like ruby and rails, but when I tried to grok the language, I found it more difficult to follow than python + js (my daily drivers). Did anyone else feel the same way? I kind of want to give it another chance bc I have some side projects that I want to try out, but I find django/python and next/react easier to grok. Maybe I should try harder? FWIW, I also want to pick up good practices when it comes to eng…

Look at https://dry-rb.org/, some of the patterns there may seem more familiar.

Re: Ruby on Rails: The Documentary [video]

#137

I remember fondly when RoR was the hottest thing, so elegant and easy to understand, but I haven't touched it in ages. Is it still good compared to the more up-to-date stuff? Is it still relevant?

Absolutely! I switched from PHP to Rails in 2008 and I've been able to upgrade all of the relevant projects to modern 7.1. Lots of changes/maturation along the way, but all in the right direction. Still best web framework for fast prototyping in 2023. I use Rails every day. Not the best for high concurrency or system tasks, but great for expressing maintainable business logic and working on web apps in teams.

Re: Ruby on Rails: The Documentary [video]

#138
post #78

Earlier quoted context omitted.

I've wondered about this for years. Express was the default with Node for some years but it was mostly used for APIs to feed front ends. These days lots of people have switched to Fastify but again mostly for APIs. There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django. Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components…

> to kludge front end components into the server which IMO is I think you make a good point here, JS is uniquely able to be executed both frontend and backend, hence things such as underscore templates. Other languages don't have that ability. Therefore I would agree that there is no point in making a 1to1 copy of existing MVC ideas. Being an ex-rubyist and now doing a lot of NodeJS, I really enjoy moving server code…

Sharing code is cool but OTOH the back and front end are two completely different beasts.

Trying to use client patterns to solve the server has been mostly a mistake. OTOH separating server and client and using an API to glue has produced a lot of issues too (SPAs, etc).

I think the future is a hybrid model where 80-90% of the front end is orchestrated from the server (LiveWire, Hotwire, LiveViews, etc) and 10-20% is a pure client side solution.

Re: Ruby on Rails: The Documentary [video]

#140

I saw it and I don't think it make it any justice, Ruby on Rails changed the paradigm of creating web applications with routes instead of files (like PHP, JSP and Webforms did) with the MVC pattern that now is present in every respectable web framework and the documentary doesn't tell that. It was enjoyable though.

Struts was a popular Java MVC framework in the early 2000’s and was pre-Rails. I kind of feel bad mentioning Struts and Rails in the same sentence, though, as Rails did much more than Struts.

I do seem to remember DHH complaining about "XML pushups" when Rails was released, and knowing what he meant from Struts.
Post reply on HN