4 ms·

I hope this point gets more discussion. It's entirely possible to decouple yourself from a framework and move quickly. It's just that most devs are incredibly

I hope this point gets more discussion. It's entirely possible to decouple yourself from a framework and move quickly. It's just that most devs are incredibly lazy, and most frameworks are specifically engineered to make this difficult.

gpvos 13y ago
It's essentially true for any language (and its standard libraries).
- mattgreenrocks 13y ago
  True, but languages/standard libraries don't break quite like frameworks do. This mostly due to the extreme coupling that a framework induces on client code. Frameworks mean you get to skip the design step, at the risk of having you by the balls later on.
  - fein 13y ago
    There is a point to be made about learning how to use a framework up to the point where you're not relying too heavily on it. I use Yii, for example, and pretty much only utilize permissions filtering, routing, view management, and AR. The form, theme, and other niche tools are all unused. This way, when upgrades come along I only really need to be aware of controller files, model files, and view files (all php template and raw html, no helpers). Models are auto generated off the schema, so those are a one click fix on a new base.
andybak 13y ago
> "most frameworks are specifically engineered to make this difficult." This almost makes it sound like an attempt at intentional lock-in which I find fairly unlikely. Can you elaborate?
- mattgreenrocks 13y ago
  Hard coupling to a framework-specified details is tough to remove after the fact. For example, everyone's OK with ActiveRecord's coupling until their test suites are slow. This decision creeps up on them and they have to expend additional energy dealing with it. It's the tradeoff of simplicity: framework authors want to make things easy (and this is commendable).
aryastark 13y ago
> It's just that most devs are incredibly lazy, and most frameworks are specifically engineered to make this difficult. I think you mean frameworks are specifically engineered to allow devs to be lazy. Doctor, it hurts when I couple my code to a framework in an attempt to save time and effort writing boring things I don't care about. Then stop doing it, silly. Portability requires effort. It pretty much requires you to not use all-encompassing frameworks. But I'd be shocked if the average JS code slinger today has even heard that word before.

gpvos 13y ago

It's essentially true for any language (and its standard libraries).

mattgreenrocks 13y ago
True, but languages/standard libraries don't break quite like frameworks do. This mostly due to the extreme coupling that a framework induces on client code. Frameworks mean you get to skip the design step, at the risk of having you by the balls later on.
- fein 13y ago
  There is a point to be made about learning how to use a framework up to the point where you're not relying too heavily on it. I use Yii, for example, and pretty much only utilize permissions filtering, routing, view management, and AR. The form, theme, and other niche tools are all unused. This way, when upgrades come along I only really need to be aware of controller files, model files, and view files (all php template and raw html, no helpers). Models are auto generated off the schema, so those are a one click fix on a new base.

andybak 13y ago

> "most frameworks are specifically engineered to make this difficult." This almost makes it sound like an attempt at intentional lock-in which I find fairly unlikely. Can you elaborate?

mattgreenrocks 13y ago
Hard coupling to a framework-specified details is tough to remove after the fact. For example, everyone's OK with ActiveRecord's coupling until their test suites are slow. This decision creeps up on them and they have to expend additional energy dealing with it. It's the tradeoff of simplicity: framework authors want to make things easy (and this is commendable).

aryastark 13y ago

> It's just that most devs are incredibly lazy, and most frameworks are specifically engineered to make this difficult. I think you mean frameworks are specifically engineered to allow devs to be lazy. Doctor, it hurts when I couple my code to a framework in an attempt to save time and effort writing boring things I don't care about. Then stop doing it, silly. Portability requires effort. It pretty much requires you to not use all-encompassing frameworks. But I'd be shocked if the average JS code slinger today has even heard that word before.