3 ms·

> Rails is great when you stick with the defaults and a land of pain as soon as you leave them. You just described every framework. Frameworks are great if you

> Rails is great when you stick with the defaults and a land of pain as soon as you leave them. You just described every framework. Frameworks are great if your application is fairly simple and aligns with its way of doing things. Libraries are where to look if you need a more complex, flexible setup.

jshen 3y ago
I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked homegrown framework that no one understands.
- bambax 3y ago
  It seems that, at least in the enterprise world, eventually every software project evolves into a hairy monster "that no one understands", choke-full of traps and side-effects that turn around to bite you at the worst and least-predictable moment. As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon. Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and - explains what each part does - is able to spot potential side effects for each new addition - suggests simpler ways of doing things / nice refactoring There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.
  - jshen 3y ago
    That's a really interesting observation. Having been in enterprise for a long time I think there are 3 things that I've seen make a big improvement on the health of a system after a decade or more. 1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems 2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction. 3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.
- eikenberry 3y ago
  This is almost 100% due to developer churn. Every mid-level developer introduced to the project will think they have the new abstraction that will fix everything. Eventually you end up with a monstrosity partially implementing half a dozen different abstractions with no overall architecture. I've seen it many times. The fix for this is pretty easy though. Keep employees and avoid the churn.
  - jshen 3y ago
    Yes! See my reply to the commenter above you.
TJSomething 3y ago
I don't know. I've always found that Symfony in PHP is pretty flexible with its setup. I feel the complexity to be proportional to how far off the beaten path I'm going. I've heard that Spring is also like this.
lolinder 3y ago
This distinction is frequently emphasized in online discourse, but I've never found it to be super useful. Pretty much everyone can agree that Ruby on Rails is a framework, while underscore.js is a library, but things get really fuzzy in the middle. The usual explanation is inversion of control—you call into a library, but a framework calls you. But now that pretty much every language has closures, it's a lot harder to use that as a distinction: is React a library since it all starts with createRoot/render (you called it), or is it a framework because from that point on it's calling you? There are tons of people who are highly opinionated in both directions, which suggests that this dichotomy is artificial and doesn't reflect a deeper reality.
- eikenberry 3y ago
  It's generally considered a heuristic or rule of thumb. It is not meant to contain any hidden truth and if you've moved past the need of this level of basic heuristic it wouldn't be useful anymore.
pdntspa 3y ago
Rails is really flexible, though.
silversmith 3y ago
There's something I never see mentioned in this discussion: you can be flexible with what libraries/frameworks you pick, but you can also be flexible with what you build with those. If doing things exactly the way you envision involves building the world from scratch, it's often better business to go with a "less elegant" solution that can be rapidly pieced together from mainly ready-made components. I've often earned long-lasting trust and cooperation of clients by asking whether they would like to adjust (or forego entirely) that one feature, if the project ended up being 20 or more % cheaper/faster to deliver. And given that choice, it's surprising how flexible businesses can be.

jshen 3y ago

I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked homegrown framework that no one understands.

bambax 3y ago
It seems that, at least in the enterprise world, eventually every software project evolves into a hairy monster "that no one understands", choke-full of traps and side-effects that turn around to bite you at the worst and least-predictable moment. As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon. Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and - explains what each part does - is able to spot potential side effects for each new addition - suggests simpler ways of doing things / nice refactoring There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.
- jshen 3y ago
  That's a really interesting observation. Having been in enterprise for a long time I think there are 3 things that I've seen make a big improvement on the health of a system after a decade or more. 1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems 2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction. 3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.
eikenberry 3y ago
This is almost 100% due to developer churn. Every mid-level developer introduced to the project will think they have the new abstraction that will fix everything. Eventually you end up with a monstrosity partially implementing half a dozen different abstractions with no overall architecture. I've seen it many times. The fix for this is pretty easy though. Keep employees and avoid the churn.
- jshen 3y ago
  Yes! See my reply to the commenter above you.

TJSomething 3y ago

I don't know. I've always found that Symfony in PHP is pretty flexible with its setup. I feel the complexity to be proportional to how far off the beaten path I'm going. I've heard that Spring is also like this.

lolinder 3y ago

This distinction is frequently emphasized in online discourse, but I've never found it to be super useful. Pretty much everyone can agree that Ruby on Rails is a framework, while underscore.js is a library, but things get really fuzzy in the middle. The usual explanation is inversion of control—you call into a library, but a framework calls you. But now that pretty much every language has closures, it's a lot harder to use that as a distinction: is React a library since it all starts with createRoot/render (you called it), or is it a framework because from that point on it's calling you? There are tons of people who are highly opinionated in both directions, which suggests that this dichotomy is artificial and doesn't reflect a deeper reality.

eikenberry 3y ago
It's generally considered a heuristic or rule of thumb. It is not meant to contain any hidden truth and if you've moved past the need of this level of basic heuristic it wouldn't be useful anymore.

pdntspa 3y ago

Rails is really flexible, though.

silversmith 3y ago

There's something I never see mentioned in this discussion: you can be flexible with what libraries/frameworks you pick, but you can also be flexible with what you build with those. If doing things exactly the way you envision involves building the world from scratch, it's often better business to go with a "less elegant" solution that can be rapidly pieced together from mainly ready-made components. I've often earned long-lasting trust and cooperation of clients by asking whether they would like to adjust (or forego entirely) that one feature, if the project ended up being 20 or more % cheaper/faster to deliver. And given that choice, it's surprising how flexible businesses can be.