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

Ruby on Rails: The Documentary [video]

youtube.com

Post reply on HN
Print view View original

181–190 of 248 posts

Re: Ruby on Rails: The Documentary [video]

#181

Post by jasonwatkinspdx »

stevoski wrote: post #107
adrianlmm wrote: post #24

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.

MVC dates all the way back to Smalltalk in the early 80s.

Re: Ruby on Rails: The Documentary [video]

#182

Post by dividedbyzero »

vario wrote: post #71
lagniappe wrote: post #32

sad to see _why the lucky stiff left out, but I suppose it is what he'd have wanted.

his 'artsyness' was the main reason I avoided learning Ruby for years-- wrongly thinking people who code in Ruby speak like him. I know this is a possibly unpopular opinion but I don't think one should glorify a sophomoric book as a key Ruby book-- there are others that deserve that title, PickAxe is close, but I'd have liked a book like Whittaker's "C#, Player Guide" for Ruby.

I absolutely loved _why's guide, not the least because it made certain very serious, over the top professional people very uncomfortable. Bullshit in the guise of Very Serious Business Software Engineering is still bullshit, but if you present something like it's a big joke to you, and it still shines, there probably is something to it. I feel a lot of present-day IT wouldn't pass that test.

Re: Ruby on Rails: The Documentary [video]

#183

Post by adriand »

Towaway69 wrote: post #114
pier25 wrote: 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…

I totally agree (also originally a Rails dev). And with Typescript and Remix I get type safety and auto complete from the database layer (Prisma) all the way to the React UI. It’s amazing.

Re: Ruby on Rails: The Documentary [video]

#184

Post by cloverich »

Towaway69 wrote: post #12
brap wrote: post #9

Earlier quoted context omitted.

>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've never worked with Rails, but this sounds amazing. One of the things I really hate about the Node.js ecosystem is that there are no clear conventions, the structure is always different even when the same framework is used. It's a mess. The exception is probably Next.js but it's…

True, nodejs really doesn't have _the_ framework. Python had flask, php is WordPress and RoR. Why is that? Especially since most of the new frameworks copy the ideas of existing frameworks. P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s

IME many of the earlier new frameworks were somewhat poor attempts at replicating established players from other languages. That resulted in a lot of cargo culting of bad code, then inevitably churn. I think that's one (of several) reason(s) why Express became more ubiquitous early on. Then from there, since Express became the most popular, and it was more of a micro framework, it allowed multiple competing sub frameworks to emerge. I really tried to use some of the other JS frameworks at the time, and having migrated from Python / PHP always felt they were not very usable by comparison.

Moreover, JS really encouraged the use of API driven development + React, at a time when that trend was in general growing. I bet this impacted the ORM development space, as I suspect FE style devs were perhaps more demanding of an ORM while more backend oriented devs were perhaps fine writing SQL. With other frameworks I find the coupling of ORM and template views to be slightly more natural. Maybe this is just me inventing story lines but its how it feels. I think the lack of a quality ORM _really_ hurt the most.

Lastly there was a growing trend towards micro dependencies and assembling from parts, and I think it promised more than it could deliver. I think if Node had shipped a higher quality standard lib, perhaps akin to Go or (maybe) how Deno is trying to do, the story might have looked much different.

This is my take as a consumer, rather than creator / maintainer of these frameworks, so not sure how accurate this is. Just my viewpoint with my dev career growing alongside the early emergence of Node.

Re: Ruby on Rails: The Documentary [video]

#185

Post by jupp0r »

ericb wrote: post #178
jupp0r wrote: post #91

Earlier quoted context omitted.

I never said that some other stack wouldn't have problems. My point was that Rails is great at some problems and awful at others. No idea how this can be controversial at all. My impression seems to be that there is a group of fanboys that are not able to have any intelligent conversation on what their favorite tool is good for and what it's not good for. In my day job I use mostly Rails. My team is starting to rewri…

> My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. What sort of web app do you have that is CPU bound?

It's an API gateway converting single digit MB-sized blobs of JSON into similarly sized blobs of JSON with a different structure.

Re: Ruby on Rails: The Documentary [video]

#186

Post by jupp0r »

DoesntMatter22 wrote: post #147
jupp0r wrote: post #44

Earlier quoted context omitted.

Rails does everything. You can build a stateless API gateway with it. Is it great for that particular use case? No. Your question about frameworks with similar capabilities is pointless because my point was that there are use cases where the capabilities of Rails are not a good fit.

You said it's objectively very slow. My question is relevant because your point begs the question: Slow compared to what? If you want to give an honest apples to apples comparison then, okay fine, what framework that does everything that rails does is considerably faster? Is a Ferarri faster than a dump truck? Sure, but they have different uses. Try hauling gravel with a Ferrari. For the class that Rails is in, there…

Ruby/Rails is not great for efficiently transforming megabyte sized blocks of JSON into differently structured megabyte sized blocks of JSON, just to give you one example. Golang/Rust/Java is better suited to that. Other use cases are for example any ML-Workloads where Python's ecosystem is much superior to Ruby's.

That being said, you missed my original point, which is that there are problems where you don't really want Rails implemented in a different language because Rails is not a good tool to solve that problem. Think hammer vs saw. You are asking for a different brand of hammer that can cut wood better. Wrong question.

Re: Ruby on Rails: The Documentary [video]

#187

Post by brigandish »

yawboakye wrote: post #28
berkes wrote: 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…

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…

Sounds interesting! You might start with a blog post…?

Re: Ruby on Rails: The Documentary [video]

#188

Post by ericb »

jupp0r wrote: post #20
berkes wrote: 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…

I couldn't agree more. There is also a technology aspect to it. Rails is objectively veeeeeery slow. Concurrency support is nonexistent. This is not a good fit for all problems. It also to some degree prevents you from breaking out the parts that would benefit from a different language into their own services (Rails needs to call them, but it's really not good at IO).

What in the world are you talking about?

This reads like someone who doesn't understand how to use a tool so they think it is broken. I've worked on Rails apps that outperformed Spring/Java apps routinely and node apps routinely at very large scale. You're very rarely bottlenecked on CPU in a modern CRUD app, much more often, it is the database.

It sounds naive to call the framework that runs github, that almost everyone in the world pushes their code to "veeeeery slow" and I don't know what you mean by "bad at io" in any context where that is a problem for Rails.

Re: Ruby on Rails: The Documentary [video]

#189

Post by conductr »

sigzero wrote: post #99

They was a really good watch. The gentlemen in the video were and are very passionate about Rails.

Early on, these guys had blogs and it was some of the only content you could find on Rails. The documentation was pretty much nonexistent and not very easy to grasp for newcomers. This was before railscasts even hit the scene but these guys, and a very few others, were like disciples spreading the word.

I even remember at around that time there was a fundraiser specifically to hire someone to write better docs. I think it was some third party response to all the forums where people had been lamenting the desire for better docs. This was before go fund me and kickstarter so itself was a little unusual at the time.

Re: Ruby on Rails: The Documentary [video]

#190

Post by ericb »

jupp0r wrote: post #185
ericb wrote: post #178

Earlier quoted context omitted.

> My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. What sort of web app do you have that is CPU bound?

It's an API gateway converting single digit MB-sized blobs of JSON into similarly sized blobs of JSON with a different structure.

The Rails app I scaled posted half a meg of JSON on every save-request every 10-15 seconds. In Rails, we parsed it, converted some parts into HTML nodes in Nokogiri, sanitized it, and saved it to both mysql and cassandra.

It wasn't a problem other than that a better initial design (nothing to do with rails) could have made passing all that data not needed, which was better for mobile. We had about 600,000 customers.

Post reply on HN