[lhorie]

If you're going to rewrite it anyways, then why not just pick a random framework? "No framework" is still a set of trade-offs, and for better or for worse, most teams aren't made of super star devs. A lot of them appreciate the hand-holding through the where-to-put-what drudge at the beginning of a project and the presence of a community to ask questions.

[nostrademons]

For a few reasons:

1.) Just by choosing to use a framework, you incur costs: download time, initialization time, complexity & bug surface area, etc. You should make sure that you gain benefits commensurate with those costs. If you start by picking a random framework, then a.) how can you measure what the costs were? and b.) how do you know what sort of benefits would be most useful to you?

2.) Relatedly, starting from a baseline random framework can teach you lessons that are not true, and then you base your product decisions on that. For example, there's a common meme that you cannot have smooth 60fps animations on mobile websites. This is not true; however, getting smooth 60fps animations on the mobile web requires careful attention to which elements will render on the GPU and which won't, and no framework currently in existence will help you with that. Back in 2008 when I did my first startup, it was generally believed that Javascript was too slow for games; not true, JQuery was too slow for games. Doing things that others believe to be impossible is the essence of competitive advantage.

3.) Frameworks make certain tasks easy at the expense of making other tasks hard. If you start with a random framework, you will be incentivized to do things in the same way that everyone else who uses that framework is. That's why almost every web 2.0 startup started from around 2007-2010 looks like a frontend over a database. Looking like everyone else is a recipe for failure in business.

4.) The framework authors are all subject to the constraints of the browser; however, browser vendors (and people who program directly to web APIs) are not subject to the constraints of the framework. The set of programs that you can write efficiently without a framework is a strict superset of the set that you can write efficiently with one.

5.) It's easier to add code than to remove it. If you start with no framework and then decide that you need one, you've written only the code that you actually did need for your problem. If you start with a random framework and then decide it's not appropriate, you need to backtrack and identify what you were actually trying to accomplish before you shoehorned it into the framework.

[lhorie]

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.