3 ms·
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 wi
by 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 agoI 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.
- yajoe 13y agoI get the sense we're talking past each other. I don't disagree with a single thing you said; I just don't think that rolling your own adapter so you can swap out concrete frameworks is a silver bullet that fixes the coupling problem. I interpreted the original comment to claim 'Obvious' as such a silver bullet. My professional career has worked with codebases that have a median age of 5 years and millions of lines of code. Most projects have 50 or so developers across timezones. Say we wanted to switch out rails for sinatra, it simply would never have been possible, even if we perfectly isolated rails from our business logic using an adapter like Obvious. The concrete details most often leak through the adapters -- remember, people are sometimes hurried or sleep deprived or forgetful. We would have had to stage the work, do it in phases just to test properly, and most likely leave the legacy stuff alone -- "If it aint broken, don't fix it."