ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
86% Positive
Analyzed from 927 words in the discussion.
Trending Topics
#rails#framework#used#business#apps#same#app#lot#logic#developers
Discussion (11 Comments)Read Original on HackerNews
But in every framework I've used, the suggested way isn't how a technology is used in reality, in production. The tutorials are almost like a different framework entirely. Years ago as an Android dev the difference was shocking between what tutorials taught you and what was done in practice.
This doesn't technically detract from the author's point but it makes it moot - you just build in the current best practice way or the way that suits your needs, and that's how it often is with languages and frameworks.
Maybe that mismatch between how people are taught initially, or how the framework is intended to be used, is an inefficiency, in which case those who design frameworks should take note.
In the case of Rails I think "the rails way" is appropriate for certain style of apps, and not so much for Shopify etc scale apps.
The benefits are so obvious that they preclude any supporting evidence or research. They are more or less axiomatic/dogma.
Wild take - maybe the pace of introducing new changes has not increased _because_ the "benefits" are not so obvious after all.
We had the internet for decades, with the sum of human knowledge largely available, no one used it.
Now those same uninspired masses are going to use to use the magic knowledge box to produce what they could never bring themselves to learn or research? No.
Just because the LLM can spit out code that looks good to you when you know what to ask for, does not mean that it is doing the same for everyone else.
Can you explain what you mean?
Rails arrived around that time, and it influenced many other popular frameworks. From what I remember of how things were back then, a lot of developers' eyes were opened by seeing a cleanly organized Rails project. I'm sure Basecamp has had to do a lot of custom refactoring beyond whatever is covered in the Rails Way. Any app that has grown as much would have to start customizing outside of the initial framework.
Today, a lot of solutions I've worked on wouldn't have even seen the light of day if they hadn't been built with Rails. I often ship complete SaaS platforms on Rails at a fraction of the cost and time of the competition because Rails makes business experiments easier and cheaper to try. Are models sometimes heavy? Yes. As heavy as that old-school AirbillBean? Not usually. But the fact is, anyone who is tasked with maintaining that would be wise to start refactoring a lot of that into other classes once complexity is increasing. But you might never have gotten to the point where you were dealing with increased complexity if you didn't start out iterating quickly with the Rails Way or something comparable. :)
Hard problems are where the money is made, as they say.
And this is accelerated by design patterns that blow up the amount of components used. Then there's the problematic gems such as Trailblazer that cause more problems than they solve, while being difficult for both humans and AIs alike.
Reminds me of the quote from Fred Brooks: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious".
Service Objects et al are flowcharts. Rails-way is tables.
https://shopify.engineering/shopify-monolith http://sporto.github.com/blog/2012/11/15/a-pattern-for-servi...
In any case, I would not advise anyone to take any advice in web-development from someone who does this.
P.S. My browser is quite fine, release age wise, not that it should matter.