4 ms·
I think Framework-itis is a result of front-end developers—who are often junior developers who may not even have CS degrees—inculcating the false message that t
by moron4hire 9y ago
I think Framework-itis is a result of front-end developers—who are often junior developers who may not even have CS degrees—inculcating the false message that they are not "real" developers. As an industry, we have treated front-end development work as entry-level, occasionally even frivolous work, as it grew organically out of the left-over work that systems developers gave to the designers.
Developing a framework doesn't look very much like doing front-end work; frameworks are generic, planned, and built from scratch, whereas the typical front-end developer is used to making highly-specific, ad-hoc changes to existing code (either because they've come in on a project started as a proof-of-concept by more senior developers, or they've used a boilerplate generating tool). Being more like so-called "real" software development, only "real" developers should be allowed to work on something ostensibly so important and complex as a "framework".
The front-end developer has been indoctrinated into believing she (and it's very often a she, 'cuz design work is women's work, amiright?) has no business writing code, and that the code she does write is woefully "WRONG, WRONG, you're doing it wrong! What are you even trying to do?" by the karma-craving, bottom-feeders of StackOverflow. To avoid further public shaming—lest there be some hidden defects their inexperienced eyes cannot detect, no matter how trivial the bit of code may be—they avoid the actual act of writing code as much as possible and spend an inordinate amount of time searching for packages that may be imported from the gods. Thus left-pad, and the ensuing post-hoc rationalization in that debacle's aftermath that such trivial micro-packages are somehow a good development practice.
I don't think there are a uniquely numerous quantity of framework projects in front-end land. Systems developers make custom tools all the time. But systems developers don't have a general fear, uncertainty, and doubt about their own work sewn into them, so it's more common for systems developers to jump into writing their own code than looking for pre-existing tools in whatever they might deem as trivial. Instead, I think a plethora of front-end tools reach a unique tipping-point level of popularity giving the perception of many more tools total, because of a general fear of falling behind. The front-end developer sees themselves as having no business criticizing their "betters" and must therefor accept what is handed down to them without question. If the front-end developer cannot prove they are a good little worker bee by keeping pace with any and all frameworks their benevolent employer or more-senior, more-"real" coworkers may spring on them, they risk having to go back to working as a barista.
Something to think about while replying to a seemingly "simple" questions.
- atoko 9y agoYou're drawing from quite a lot of assumptions. Consider that until recently, "front-end" work was done mostly on the server.
- moron4hire 9y agoI think I know what the history of web dev for the last 20 years has been, considering I've lived and worked through it. Your comment doesn't change anything. There has always been a client-side component of web apps. While in modern times it has become more richly interactive and complex, it's pretty clear the people who work on it have not received a similar upgrade in respect.