Have you also noticed how job listings for web developers these days include an often lengthy list of code libraries that you are required to have experience with? It's as if knowing the specific library code exempts programmers from needing to make good design decisions, makes it unnecessary for them to know how to program in the underlying language(s), and eliminates the need for them to become familiar with the unique code used in an existing site.
Just as asking prospective employees useless questions won't find good candidates, blindly using these libraries is at odds with the goal of making sites more responsive. Site-specific code that has dependencies on libraries with large "core" files, can't run in the browser until the libraries have loaded, so it takes more time for sites to become responsive to users, which may result in site abandonment before any content is even read.
Here, I'll present ways of achieving the same results as are obtained with libraries that require hundreds of thousands of bytes of core code files, but with only a few hundred, or a few thousand, bytes of code, total. For example, angular.min.js is about 110 Kb, and jquery-1.7.min.js is about 94 Kb, with both files minimized, and that amount of code has to be included into your application to use these libraries, before any actual site code can been written.
And the decades-old MVC model has now been superceded by the modern "Web 2.0" Single Page Application ( SPA ) model. This enables highly interactive, responsive, and adaptive site designs and code to be implemented, with no need for libraries.
The Web 2.0 SPA Model
With the Web 2.0 SPA Model, functions that need to access server-side resources are run on servers, such as database SQL queries, and everything else is run in client browsers. In the client "index.html" page, the HTML code forms a skeleton that content is slotted into, with the content for commonly viewed items pre-loaded in the main page, and other less frequently viewed content sections are loaded with AJAX, on demand as users navigate around the site. These load operations take place in the background, asynchronously, so that users can continue using the site as loading takes place.
Now try selecting a database from the drop down on the left side of the page. Then, additional fields are shown that allow SQL queries to be built and run in the browser on the selected database and table, along with the result set from a default SQL query on the selected database and table.
Selecting the "MySQL world" database shows the first 1,000 rows of results from a default query on a 4,000 row database table, also displayed in a scrollable HTML table with fixed headers. Another example that shows the first 1,000 rows of data from a database table with over 164,000 rows of data, can be seen when the "MySQL genome" database is selected along with the "geolpNode" table. These default queries are limited to 1,000 rows of data being returned at once to reduce the load time for data, but a 10,000 row query can be handled on the "geolpNode" table, with a regular broadband Internet connection, before the timeout cuts in. Enter 10000 in the "End record" field, select "*" from the "Select Field" drop down, click the "Run Query" button, and wait about 75 seconds ...
Whatever the content is, the site skeleton must be written in a cross-browser compatible manner, so that it runs and looks the same in all the common browsers currently used on the Internet, Microsoft Edge and IE ( including legacy versions ), Chrome, Firefox, Opera, and Safari. And the simplest way to accomplish this is to use nested <div> page elements to contain everything on web pages - no so-called cross-browser compatible libraries required.
Also, don't use "eye candy" functions that, for example, cause text to slide or jump around the page after it's loaded and displayed. This just forces users to try and find the text that they were reading before it moved, and the distraction may result in them abandoning offending sites. These types of functions just delay users from interacting with pages, and have a heavy penalty in library code size and increased page-load times, without providing any useful functionality. It's even worse if the sliding / jumping text covers up information and / or fields on the page, or reduces the viewport size to letterbox dimensions - and yes, as I write this I'm looking at a commercial web page that does all of these awful things, and it's virtually unusable!
Try loading the "BootstrapDemo" and "Adaptive" pages into a smart phone, as well as viewing them in a desktop browser and scrolling the browser window width narrower and wider, and the adaptivity can also be seen here in the <iFrame> below. Scroll up and down the <iFrame> with its vertical scrollbar to see format changes at different browser window widths, and note that on smart phones, the "viewport" metatag, "<meta name='viewport' content='width=device-width'>", enables displaying the full size page view in its collapsed, vertically-oriented page mode, rather than displaying a tiny view of the whole page in its horizontally-oriented mode, zoomed-out to fit the small ( mobile ) screen width.
If the sections have been pre-loaded, the display will be immediate. And if they need to be background loaded asynchronously with AJAX, the delay should be minimal and acceptable, as only small partial pages need to be loaded from the server.
Of course, site elements that are initially loaded should be made as small as possible and kept to a minimum number, especially graphic images which can be large, and should be displayed using the most compact format possible. For example, .jpg screen shots can be perhaps 1/3 of the size of the same images saved in .png format, with the same readability when displayed on-screen, as shown in the following screen shots ( in order to read the text you may need to maximize the browser window to view the screen shots at full screen width ).
The point of code libraries should be to provide small, reusable, pre-written chunks of code that require a minimum of time and effort to incorporate in sites, so that usability is not reduced by loading large core library code files when users access production sites. And the code size issue is accentuated if multiple libraries have to be used to incorporate all the required functionality in sites, such as with Bootstrap's dependency on JQuery ( see screen shot above ), not to mention if sites are accessed via mobile devices with less than optimum wireless connections.
And when a company hires a new programmer, they must expect and welcome a learning curve so that (s)he can get to know the unique code in the site being worked on. The learning period enables programmers to get familiar with the structure, design, and coding of any site that they haven't worked on before, including the way that library code is used, whether that includes in-house or third-party libraries. It completely defeats the reason for using code libraries if you're expected to "know the library code", and if you have to become an enabler for other people's Code Library Obsessive Compulsive Disorder, you've been CLOCD!