3 ms·
Well, I think the “line of thinking” against frameworks and framework-y libraries is presented fairly well in the article: bloat, performance issues, debugging
by mypastself 5y ago
Well, I think the “line of thinking” against frameworks and framework-y libraries is presented fairly well in the article: bloat, performance issues, debugging difficulties, steep learning curve, niche use, deprecation, and maintainability. You may disagree with one or more of those points, but I don’t think you’ve offered a strong rebuttal.
- nsonha 5y agoMy question is rhetorical, and I did not bother to read the article, for that I am a javascript developer myself, and too familiar with these arguments. The only real valid point is bloat, simply because the web is the only platform that still has a code size requirement of applications from the 80s. It's not that there is no solution for it. Take for example island architecture, there is no such thing in "the platform". So if you do care about bloat and want to load only part of the app that's used, you would use a library, or framework, whatever you call it to help implement that. "write more compact code" or "avoid writing code" sounds like giving up to arbitrary restrictions to me. Performance isssues are mostly caused by incompetece, using frameworks or otherwise. The rest of the issues can be attributed to anything, and is subjected to improvements, rather than to be seen as reasons to dismiss the whole idea of frameworks. I'd like to point out another thing, all the tiny, low quality, "unixy" garbage on npm actually exists because of the dogmatic avoidance of frameworks.