You're viewing a comment by Jared T and its 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 "halflife3_508": (just to make sure you're a human)

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