Frameworks in general made sense to me, the biggest hurdle was trying to wrap my mind around Redux (or Vuex), or whatever data store and reducers to handle data immutability and… eh? But then, as I got deeper and deeper into
reduce(), and looking more at functional programming, it kind of clicked.
I don’t feel that the framework paradigm fits every case. And when a project or idea is starting out, it often makes sense to keep the conversation framework-free. But often, there comes a time where, in order to support the productivity of the entire team, a skeleton makes sense.
Its like that cartoon about “I don’t like frameworks, too much enforcing of this artificial construct or that language addon… I know, let’s make a framework that simplifies all that, and lets you just get on with the coding!” And thus, another framework is born. And it evolves and becomes complex.
I remember being a part of the conversations when jQuery wasn’t a thing, when it was in pre-alpha and alpha testing. There were a few other libraries out there doing much the same thing: YUI and Mootools spring to mind. And the big conversation was, “while this library might help, what are the ramifications of everyone using it?” Aspiring devs learned to write truly ugly code, because the utility libraries were very forgiving. Spaghetti code and mickey-mouse patches were everywhere. Following back how an event was handled was like looking for an aux cable in that huge box of cables in the bottom of the closet.
Frameworks are the same. Someone new to coding hears about this amazing way of developing complex SPAs or whatever, and they jump into writing React without knowing how to elegantly, cleanly, properly structure code. While React may enforce a certain level of organization, without the coding discipline that POJ provides, it is easy to make an AWFUL mess.