|
1) this line of argumentation seems like selective reasoning. For example, one could say, ok I need ajax. Let's use a `fetch` polyfill. Wait, you can't abort the request with it? Fine, XMLHttpRequest then. How do I take my object and serialize it to a querystring again? Oh, I need to change a HTTP header to make my server accept the request body as JSON? Should I just use jQuery? It's too overkill. What about Reqwest? Does it do what I need? Is it maintained? etc etc etc. Point is: you don't know what kind of costs you're going to incur, regardless of whether you're using a framework or not. 2) going off 1), one could come to the (obviously ridiculous) idea that AJAX is really hard. Or that frontend build systems are not worth the trouble (I actually see this "myth" in the wild, and people wasting time due to it). 60fps on mobile is really not a "competitive advantage", even if you're going into the hyper-saturated gaming market (and in that case, you really ought to be writing ObjC/Java if you care about speed at all). Competitive advantage is about creativity and relentlessly exploiting opportunities, it's rarely ever the case where an obscure piece of software trivia will make a huge difference. 3) frameworks exist on a spectrum: if your argument was true, one could just pick an obscure framework. But honestly, It strikes me as wishful thinking to suggest that framework choice is the primary driving factor for a product (that's why the role of product managers exist) 4) there's a very real and recognized constraint that affects all low level systems compared to higher-level abstractions: complexity. jQuery is a DSL for avoiding 10000+ LOC DOM API code. Virtual DOM (or any "retained mode" templating system) help avoid 10000+ LOC jQuery spaghetti. Component systems let you create more DSLs, etc, etc. 5) it is easier to add code than to remove it, and that's precisely why most systems in the wild have technical debt: organic growth. When you start from scratch, in my experience (especially w/ a team over a period of time), it can get pretty hard to untangle the various subsystem out of an organically grown codebase. We had this issue in my previous company: there was a monolythic architecture for a mission critical system, and the 10 year old Session class was essentially impossible to replace without breaking everything. Speaking from experience, frameworks actually make it easier to bail out because there are only so many idioms you need to expect, and code is more-or-less organized even if it is a shitstorm by any other metric. With non-framework code, you get to spend a lot of time evaluating for the umpteenth time why exactly foo is seemingly replaceable, but actually not without breaking bar, baz and quux. |