12 ms·

This is the consequence of writing code against ANY framework. I don't care if it's Symfony, Zend, etc. in PHP, Rails in Ruby, or Spring, Struts, etc. in Java.

This is the consequence of writing code against ANY framework. I don't care if it's Symfony, Zend, etc. in PHP, Rails in Ruby, or Spring, Struts, etc. in Java. The more you lean on a framework, the more you are tied to it and the harder it is to move. Just look at all the pain Ruby devs have felt moving from various rails versions. https://railslts.com https://railslts.com shouldn't have to exist if we were doing our job as software developers. Using a framework is a HUGE tradeoff. You are trading ease of development for a kind of vendor lock-in where the cost to move goes up with every line of code you write. Using an architecture that lets you write framework-independant code is a huge win and would keep you out of this kind of trouble. I wrote Obvious Architecture http://obvious.retromocha.com http://obvious.retromocha.com for this reason, but there are plenty of clean architecture examples here: http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch...

mattgreenrocks 13y ago
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.
porker 13y ago
Completely agree. I wrote against Symfony 1.0 and the upgrade to 1.4 needed a partial rewrite (look, new form library!). I wrote against Symfony 1.4 and the upgrade to 2.X ..well hasn't happened, a recession got in the way and clients want to spend money on something that'll have results. I don't mind legacy code - heck I make a good living from it. But I wish framework developers (and everyone online) would agree that slower, more evolutionary progress is OK. -- A cynical developer, who's seen fads come and go too many times
- MAGZine 13y ago
  thankfully symfony 2.3 is LTS now. the thing about frameworks is that you don't get the goodies unless if you upgrade, but you wouldn't get the goodies anyhow unless if you wrote it yourself. It's a tradeoff, but usually a worthy one.
- aryastark 13y ago
  frameworks and everything, say, post-2003 has been a tragic joke on our profession. We deserve better, but everything JWZ says here is the norm: http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html. Even the majors, like Google, are doing this today. Quality down, fads up.
- petervandijck 13y ago
  Then just don't upgrade. It's not obligatory :)
bowlofpetunias 13y ago
So you write all that functionality that comes with the framework yourself, and then what? It doesn't need improvement? It doesn't need updating to remain compatible with the ever changing technology around it? As far as I'm concerned, you're digging a hole either way, it's just the shape of the hole that changes. The bottom line is that there is too much code to maintain (or migrate, or rewrite, depending on the shape of your hole) and never enough resources/people/budget/time to do it. Everything is a huge tradeoff.
- mattgreenrocks 13y ago
  > The bottom line is that there is too much code to maintain (or migrate, or rewrite, depending on the shape of your hole) and never enough resources/people/budget/time to do it. Everyone says this, but then finds time for FB/Twitter/HN during the day. Something doesn't line up. This is a question of priorities, and people not feeling the effects of hard coupling to a framework.
  - deleted 13y ago
    [deleted]
  - x0x0 13y ago
    do you really believe that 20 minutes of time wasting on hn per day somehow translates into a significant amount of dev work that I could have done but didn't?
    - mattgreenrocks 13y ago
      20 * 5 = 100 minutes So, yes. It's OK if you don't, but I think it's worthwhile foregoing social media sometimes to work on studying and upping your game. Besides, you don't always have to be in "OMG not enough time to do this nicely!" mode. Such a mindset is reactionary and generally not conducive to writing robust code. I'd rather go a little slower and not have to return to parts of the codebase later.
      - 13y ago
yajoe 13y ago
With respect, the OP's experience matches anytime that you have dealt with legacy code. Heck, e-ink Kindle devices use Java 1.4. No generics, weird interop with JNI, and so many fewer plugins (think robust encryption, XSS checkers, etc) as a consequence. The experience has nothing to do with the framework, only that the code is legacy and it's too much hassle to migrate forward. Probably a better way to put it: developing legacy code is like living in the past with the benefit of knowing the future. You miss all of the modern tech and constantly remind yourself how much easier it would be if only you had XYZ. But it's unfair to criticize those past decisions with the benefit of hindsight. When writing my expressive scala code, I sure wish the computer would just know what I mean and auto-complete my code... it would be obvious to one ten years from now :) Using fear to choose the 'Obvious' framework over choosing Rails or rolling your own seems silly to me given you can find tons more people who know Rails (your boutique shop hopes to grow, right?) and tons more products designed to work with Rails. That ecosystem bonus seems to more than offset any tie-down to an open source framework. Will there ever be Obvious LTS? You're right that there is a tradeoff in picking a framework, but I think we disagree on the costs behind that tradeoff.
- programminggeek 13y ago
  I am not opposed to picking a framework, I'm opposed to make your app a "framework" app just because that's the default state of things. You can certainly pull things into smaller chunks that are loosely coupled, so maybe you use something like Rails for the view, your app is plain old ruby, and you use MongoMapper or Sequel for the DB, but the communication between those layers is done by sending messages, not by hard linking, so that the front or back end can be removed. Rails all of a sudden is terrible? Switch the routing/views/controllers to Sinatra. Want to move over to something Java based, you can still use a bunch of your core app code via JRuby and maybe slice out bits into Java/Scala over time. Want to switch from Mongo to Postgres, swap out the database module. My point is, the switching cost doesn't have to be an entire codebase rewrite to move from one thing to another. It only exists that way because the default framework path is tightly coupled by default. As to if people should use Obvious? Well it's just a pattern of how you put code together. It's not a framework and it's not the only way for people to get the same benefits. I don't care if people use it or not. Use Hexagonal Architecture or Onion Architecture or DCI or whatever the flavor of the week is. It doesn't matter. The point is, your code doesn't have to be tightly coupled to any framework. There are good options and patterns out there and just defaulting to any particular framework's defaults will lead you down the same path as the OP.
antihero 13y ago
To be honest, having used Django since 1.3, there are things needed to be done to port to 1.4, 1.5 etc, but they aren't hugely serious.
- Daishiman 13y ago
  That's because Django is one of the most sensible frameworks around, with the developers being fully aware of the costs of upgrading, making massive efforts to minimize it and not break backward compatibility unless absolutely necessary.
  - antihero 13y ago
    I think that's one of my favourite things about Django - even though it might not be the literally best thing out there, it's pretty damn good, and the developers understand the concept of maturity. Shame about WSGI (despite it's benfits) being so inflexible though. It'd be good if there was some sort of "socket gateway interface" for pythonn spec that allowed Python apps to do stuff like websockets. IIRC WSGI cannot do that as it's all about single request/responses. Might look into what can be done with async stuff (gevent) and uWSGI 1.9.

mattgreenrocks 13y ago

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.

porker 13y ago

Completely agree. I wrote against Symfony 1.0 and the upgrade to 1.4 needed a partial rewrite (look, new form library!). I wrote against Symfony 1.4 and the upgrade to 2.X ..well hasn't happened, a recession got in the way and clients want to spend money on something that'll have results. I don't mind legacy code - heck I make a good living from it. But I wish framework developers (and everyone online) would agree that slower, more evolutionary progress is OK. -- A cynical developer, who's seen fads come and go too many times

MAGZine 13y ago
thankfully symfony 2.3 is LTS now. the thing about frameworks is that you don't get the goodies unless if you upgrade, but you wouldn't get the goodies anyhow unless if you wrote it yourself. It's a tradeoff, but usually a worthy one.
aryastark 13y ago
frameworks and everything, say, post-2003 has been a tragic joke on our profession. We deserve better, but everything JWZ says here is the norm: http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html. Even the majors, like Google, are doing this today. Quality down, fads up.
petervandijck 13y ago
Then just don't upgrade. It's not obligatory :)

bowlofpetunias 13y ago

So you write all that functionality that comes with the framework yourself, and then what? It doesn't need improvement? It doesn't need updating to remain compatible with the ever changing technology around it? As far as I'm concerned, you're digging a hole either way, it's just the shape of the hole that changes. The bottom line is that there is too much code to maintain (or migrate, or rewrite, depending on the shape of your hole) and never enough resources/people/budget/time to do it. Everything is a huge tradeoff.

mattgreenrocks 13y ago
> The bottom line is that there is too much code to maintain (or migrate, or rewrite, depending on the shape of your hole) and never enough resources/people/budget/time to do it. Everyone says this, but then finds time for FB/Twitter/HN during the day. Something doesn't line up. This is a question of priorities, and people not feeling the effects of hard coupling to a framework.
- deleted 13y ago
  [deleted]
- x0x0 13y ago
  do you really believe that 20 minutes of time wasting on hn per day somehow translates into a significant amount of dev work that I could have done but didn't?
  - mattgreenrocks 13y ago
    20 * 5 = 100 minutes So, yes. It's OK if you don't, but I think it's worthwhile foregoing social media sometimes to work on studying and upping your game. Besides, you don't always have to be in "OMG not enough time to do this nicely!" mode. Such a mindset is reactionary and generally not conducive to writing robust code. I'd rather go a little slower and not have to return to parts of the codebase later.
    - 13y ago

yajoe 13y ago

With respect, the OP's experience matches anytime that you have dealt with legacy code. Heck, e-ink Kindle devices use Java 1.4. No generics, weird interop with JNI, and so many fewer plugins (think robust encryption, XSS checkers, etc) as a consequence. The experience has nothing to do with the framework, only that the code is legacy and it's too much hassle to migrate forward. Probably a better way to put it: developing legacy code is like living in the past with the benefit of knowing the future. You miss all of the modern tech and constantly remind yourself how much easier it would be if only you had XYZ. But it's unfair to criticize those past decisions with the benefit of hindsight. When writing my expressive scala code, I sure wish the computer would just know what I mean and auto-complete my code... it would be obvious to one ten years from now :) Using fear to choose the 'Obvious' framework over choosing Rails or rolling your own seems silly to me given you can find tons more people who know Rails (your boutique shop hopes to grow, right?) and tons more products designed to work with Rails. That ecosystem bonus seems to more than offset any tie-down to an open source framework. Will there ever be Obvious LTS? You're right that there is a tradeoff in picking a framework, but I think we disagree on the costs behind that tradeoff.

programminggeek 13y ago
I am not opposed to picking a framework, I'm opposed to make your app a "framework" app just because that's the default state of things. You can certainly pull things into smaller chunks that are loosely coupled, so maybe you use something like Rails for the view, your app is plain old ruby, and you use MongoMapper or Sequel for the DB, but the communication between those layers is done by sending messages, not by hard linking, so that the front or back end can be removed. Rails all of a sudden is terrible? Switch the routing/views/controllers to Sinatra. Want to move over to something Java based, you can still use a bunch of your core app code via JRuby and maybe slice out bits into Java/Scala over time. Want to switch from Mongo to Postgres, swap out the database module. My point is, the switching cost doesn't have to be an entire codebase rewrite to move from one thing to another. It only exists that way because the default framework path is tightly coupled by default. As to if people should use Obvious? Well it's just a pattern of how you put code together. It's not a framework and it's not the only way for people to get the same benefits. I don't care if people use it or not. Use Hexagonal Architecture or Onion Architecture or DCI or whatever the flavor of the week is. It doesn't matter. The point is, your code doesn't have to be tightly coupled to any framework. There are good options and patterns out there and just defaulting to any particular framework's defaults will lead you down the same path as the OP.

antihero 13y ago

To be honest, having used Django since 1.3, there are things needed to be done to port to 1.4, 1.5 etc, but they aren't hugely serious.

Daishiman 13y ago
That's because Django is one of the most sensible frameworks around, with the developers being fully aware of the costs of upgrading, making massive efforts to minimize it and not break backward compatibility unless absolutely necessary.
- antihero 13y ago
  I think that's one of my favourite things about Django - even though it might not be the literally best thing out there, it's pretty damn good, and the developers understand the concept of maturity. Shame about WSGI (despite it's benfits) being so inflexible though. It'd be good if there was some sort of "socket gateway interface" for pythonn spec that allowed Python apps to do stuff like websockets. IIRC WSGI cannot do that as it's all about single request/responses. Might look into what can be done with async stuff (gevent) and uWSGI 1.9.