For a few reasons:<p>1.) Just by choosing to use a framework, you incur costs: download time, initialization time, complexity &amp; 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?<p>2.) Relatedly, starting from a baseline random framework can teach you lessons that are <i>not true</i>, and then you base your product decisions on that.  For example, there&#x27;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&#x27;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, <i>JQuery</i> was too slow for games.  Doing things that others believe to be impossible is the essence of competitive advantage.<p>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&#x27;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.<p>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.<p>5.) It&#x27;s easier to add code than to remove it.  If you start with no framework and then decide that you need one, you&#x27;ve written only the code that you actually <i>did</i> need for your problem.  If you start with a random framework and then decide it&#x27;s not appropriate, you need to backtrack and identify what you were actually trying to accomplish before you shoehorned it into the framework.