You're viewing a comment by Sean M and its responses.

Sean M Permalink
March 05, 2018, 17:34

Reading through most of the 2+ years of comments here, I'm struck with how the pro-framework people don't address the points made in the article. Rather, they bring up two basic points: 1) Initial software creation is faster with a framework, and 2) Tested code is better than untested code.

I think everyone would agree. However, that's not the point.

Example: I currently work for a group who started using Ruby on Rails in 2009. It was great. The developers here spun up 38 web applications in about two years. Those applications solved a lot of people's problems. The programmers had to hack ActiveResource and Rails core because back then SOA was one of those weird edgy things that Rails didn't support. But the hacking didn't take much time, and development was very quick. So far, so good.

Fast forward nine years. The development staff has rotated out twice. Rails has moved from version 2 to version 5, shedding its preferred JS framework (Prototype) along with making numerous large changes. Our development staffing levels are set in stone by budgetary constraints, and as those 38 initial apps were joined by eleven more, the time to maintain and support those applications has drowned out our groups ability to keep up with Rails core changes --- not due to negligence, laziness or stupidity, but rather due to the simple element of time.

Yes, frameworks save time up front. Yes, using code reviewed by hundreds of developers and tens of thousands of websites is safer than hand-coded. And then comes the part that is utterly miserable: maintaining it.

You may say: you'd have the same problem with handwritten code.

I answer: no, you wouldn't. Here's why: programmers who know the technologies they're using will create a system that solves the need of their users (and not fourty-thousand other users). They do this with a programming language. While that language will move underneath them at times, their code will not change without their consent. IF (and that's a big if) the programmer knows what they're doing, using targeted libraries where it makes sense, and using what every programmer should have a solid grounding in (security, design patterns, coding for future maintenance), then their code is orders of magnitude less complex, more secure due to lower security target area, and needs very light maintenance.

In short, using a framework is fine for freelancers who can walk away from a finished product, or for corporations who can hire n newly-minted CS grads to keep up with framework updates.

But for those of us who have to live for years with what we create, or have to assume the responsibilities of others who walked away, a framework is a sanity death sentence.

Comment Responses

Jared T Permalink
August 21, 2018, 23:28

Would your company be better off if instead of 49 apps to maintain, you had far fewer, built with no framework? Would you have ended up building an internal company framework instead? Would each of the apps create their own app frameworks that had a different flavor, requiring devs who hop from one project to the next to learn the unique framework for each project? How much of a nightmare would that be?

How many fewer projects would you have? 39? 29? 9? Instead of having maintenance headaches, would you be unemployed?

Can you give an example of time consuming / sanity stealing maintenance headaches?

The author also mentioned that needlessly upgrading something that already works is another anti-pattern -- what if you used old Ruby on Rails and didn't upgrade? Or forked open source to apply what few security/browser compatibility things came up that you may have needed to do on your own in-house project?

Basically, I see a lot of people in agony over hard to maintain frameworks, but I am not convinced that the alternative is better, or even what the alternative is. Can someone point to a list of open source projects that don't use frameworks and are successful?

Anyway, I'm convinced that you and the article author stumbled into some sort of maintenance hell -- okay, bad luck dudes, but I am not in the slightest convinced that framework avoidance is a virtue, moreso than avoidance of adopting any sort of risky thing (dependencies, webs of complexity) that are beyond one's control. Avoid bad frameworks, avoid taking on unnecessary complexity -- sure, but if frameworks can reduce complexity and are not bad (like I think Angular 1 was*, though I give it credit for being a thought experiment), then this doesn't have to do with frameworks -- it has to do with bad dependencies and bad architecture.

(* I thought Angular 1 was ridiculous, with its huge learning curve with boilerplate scattered everywhere, and love Vue's learning curve by comparison, though am still concerned how maintainable the npm and build and transpiling ecosystem will be over the next few years. (Aurelia may be a lower-risk and unobtrustive and long-term maintainable option) Though I think Vuex is ridiculous and half done, without vuex-pathify and even then still a mess -- but at least it is promoting healthy state management.) Also, maybe this discussion is web-centric? I'm relatively new to the web landscape and it is so convoluted it is easily shown to be hilarious by the tech comedians out there. I don't really know the bias here on web versus other: How many "frameworks" end up becoming universally used libraries, or core platform or operating system or cloud platform features that are used by everybody on that platform? If people avoided publishing frameworks, because "we have to avoid frameworks at all costs!", how many of those wouldn't exist?

Define framework. (Do frameworks own the application lifecycle, for example? Do they have black boxes of application logic flow?) Maybe a clearer definition would get at the real issues.

Reply To This Comment

(why do I need your e-mail?)

(Your twitter handle, if you have one.)

Type the word "0day_508": (just to make sure you're a human)

Please preview the comment before submitting to make sure it's OK.