211–220 of 248 posts
Earlier quoted context omitted.
MVC was already used in frameworks like WebObjects for example (and maybe others) quite a while before Ruby on Rails was born.
Sure but I think the point is Rails popularized it.
Earlier quoted context omitted.
Despite what others will say here, it actually is Next.js. People don't agree with parts of the stack (just as C#/Java people didn't agree with what Rails was doing in 2005), or point out projects with the equivalent mindshare of Sinatra/Flask like Nuxt and Svelte, but when you look at what company-level projects are majority building with in 2023, it's Next.js. https://insights.stackoverflow.com/trends?tags=next.js%…
How do we know it's not Django/React?(not sarcasm; trying to learn) Adding those two to your link shows them on similar "these increase as rails decreases" correlations, with more area under curve: https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
Next.js is using React, it's a piece of the fullstack framework, like Rails and erb. React is the primary fullstack JS templating system, that's even more featureful as it's a better client side JS interop story than html templates.
By the stackoverflow graph, it's clear that most complex projects have moved onto frontend frameworks like React, instead of templated html, which standard Django is using. Django used in conjunction with a frontend framework, is most often through Django Rest Framework, which fares much less popular on stackoverflow trends:
https://insights.stackoverflow.com/trends?tags=next.js%2Crub...
Earlier quoted context omitted.
MVC was already used in frameworks like WebObjects for example (and maybe others) quite a while before Ruby on Rails was born.
Sure but I think the point is Rails popularized it.
Dupe: https://news.ycombinator.com/item?id=38222535
Earlier quoted context omitted.
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.
The culture encourages a lack of discipline; indeed, high framework coupling is seen as the Rails way.
Also why would you be afraid of coupling to the framework? It's not like you're going to be able to change the framework after the project grows, anyway.
Earlier quoted context omitted.
Ryan Bates is a legend
Indeed. Also, kudos to Chris Oliver for taking up the mantle. https://github.com/excid3
The Ruby on Rails community struck me as different back in the day in how fun it was.
It's hard to explain but coming from a Java background the community seemed to be full of interesting and engaging characters. Some people don't really appreciate that and prefer things to be very dry but I loved it.
I'd like to shout out to Ryan Bates, Geoffrey Grosenbach, Zed Shaw, _why, Jason Seifer, Gregg Pollack, Sandi Metz, Ezra Zygmuntowicz, Yehuda Katz, Dr Nic, Tenderlove and a whole heap more.
Thanks everyone, you've made it a very entertaining journey.
Earlier quoted context omitted.
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
Wouldn't python's _the framework_ be Django?
Django is to Rails as Flask is to Sinatra, imo.
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…
it looks basically the same in structure whether it is the biggest Rails app there is or a new one Totally agree! Developers tend to really undervalue this aspect of RoR. In addition to easier onboarding, it greatly reduces bikeshedding. MVC maybe isn't the best paradigm for everything, but it's good enough for most things.
I agree! I think maybe because the consistency only shows its value:
* over years
* in its absence (on other projects which aren't using rails)
Which means it is easy to miss.
I see the same thing with spring. Having constraints helps free you up to solve different kinds of problems. I lived through the "let's define everything from the ground up, picking all our libraries, etc" phase of Java (in the early 2000s; I remember Tapestry and Wicket and Struts and Expresso and XMLC). Would prefer to not do that again.
But coalescing on a particular framework is something that a community has to arrive at together. While I think that JavaScript, for example, would benefit from this, I don't know how to encourage it (other than by leaving comments on HN, maybe :) ).
And don't think that coalescing means there are no other frameworks. Java has a number, and Ruby does too (trailblazer is a rails++ , Hanami is a rethinking of MVC, Sinatra is like flask). But having one big player makes it easier to focus on higher order solutions.
Earlier quoted context omitted.
help I’ve just witnessed a murder
on the off chance someone doesn't understand the subtext here. BaseCamp is DHH's company's product. DHH is the creator of Ruby on Rails. He literally create RoR to build BaseCamp, which is exactly the type of software the other poster is claiming is problematic for RoR. DHH is on record as having said RoR was evolved organically from the early code of BaseCamp.
I wasn't. I specifically did not mention any concrete examples. I presume parent misread it as "for project management rails is unsuited" which, indeed it's not: specifically because PM is very much CRUD and has relatively little and/or relatively simple business logic (It's not for nothing that the hello-world of nearly all frameworks around CRUD are "TODO lists", the simplest form of PM).
What I tried to say, is that your domain, your team, your timing, your specific planning and your kind of project and any combination thereof has different needs. A setup, architecture, framework, fits one or a few of these perfect. But never all of the combinations of them. Nor over time (today you are a one-man-shop, tomorrow a team of 6. Today you build a full-stack web, tomorrow you need APIs for integration. Today you build a CRUD app for some medication journal, tomorrow it pivots into a complex tool for medical research.)