Hacker News Reader

Comment by programminggeek | Hacker News Reader

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 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 for this reason, but there are plenty of clean architecture examples here: http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch...

View on HN

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.

> 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.

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?

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.

Not all minutes are created equally. Spending 100 minutes in a row on code is usually pretty useful; coming back to it for 20 minutes a day is not, especially if we're talking about upgrading to a major upgrade of a framework, which we are.

I would have to second this. When I have a meeting that ends 15 minutes before lunch it is hard to want to work on a task when I know I wont be able to get into the flow.

> Everyone says this, but then finds time for FB/Twitter/HN during the day.

Not to mention extravagant lunch breaks spent chewing food instead of inhaling Soylent, trips to the bathroom and time wasted milling around the proverbial water cooler.

More to the point, the technical debt being discussed here isn't solved by increasing office productivity by 5%.

This is why we don't do away with the 40 hour work week. Some people will always think that working more will solve all of our problems.

Haha, not at all. I'm all for 20 hour weeks.

I do believe that thinking more and working less on work will solve more problems though.

You don't write all the functionality that the framework gives you. You create boundaries between the framework and your code, so that if the framework changes, your app code doesn't have to. It doesn't matter if it's a front end framework, a database ORM, a queue, or a web api. External changes don't need to break your core app.

What you propose may sound great and easy in theory, but in practice it's usually a huge disaster.

The truly useful code of the application will quickly become overwhelmed by the code that tries to abstract away the high-level abstractions offered by the frameworks being used. The boundary or interfacing code you mention ends up becoming a custom framework in and of itself, but usually far more limited than the underlying frameworks.

It's pointless to use a framework in the first place in order to reduce the time and effort needed to build a software system, only to immediately try to abstract it away with a bunch of custom code.

As an industry, we've seen these kinds of systems in the Java world for many years now, and they never turn out well. The performance is awful due to the layers upon layers of abstraction. It becomes extremely difficult to partially, never mind fully, comprehend such a system. This in turn makes even simple changes risky and awkward. And in virtually all cases, the abstractions end up being useless, because the underlying framework is never actually changed at any time. And in the rare cases that it is, a huge amount of work is needed anyway because the code abstracting away the framework never does this perfectly.

The cost of implementing and maintaining the type of abstraction that you propose can easily exceed the cost of rebuilding from scratch software systems that are highly tied to one or more frameworks.

Exactly. Abstraction upon abstraction upon abstraction. I still write to just write plain SQL. (They call it "raw" and it comes with warnings!). That's enough abstraction for me :)

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

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.

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. Even the majors, like Google, are doing this today. Quality down, fads up.

Then just don't upgrade. It's not obligatory :)

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.

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

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.

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.

> "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?

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).

> 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.

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.

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.

I 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."

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.

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.

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.

Reply on news.ycombinator.com