Accessing CDN Library Classes in JavaScript- Tutorial
What CDN Library Classes Actually Are
When you load a library via CDN, you're pulling pre-built JavaScript code from an external server. That code lives in a global namespace — usually window in browser environments. The classes you access aren't magically available just because you added a script tag.
You need to know where the library attaches itself. That's the whole game here.
How CDN Script Tags Work
When a browser loads a CDN script, it executes that JavaScript. The library then attaches its functionality to a specific object. This is either:
- The window object (global scope)
- A named namespace on window
- Nothing — it just extends existing prototypes
Most modern libraries use named namespaces. Older ones pollute the global scope.
Common CDN Library Patterns
React and ReactDOM
React attaches to window.React and window.ReactDOM:
<script src="https://unpkg.com/react@18/umd/react.development.js"></script>
<script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
<script>
const element = React.createElement('h1', null, 'Hello');
ReactDOM.createRoot(document.getElementById('root')).render(element);
</script>
After these load, React and ReactDOM exist as global variables.
Vue 3
Vue 3 uses the Vue global:
<script src="https://unpkg.com/vue@3/dist/vue.global.js"></script>
<script>
const { createApp } = Vue;
createApp({
data() { return { message: 'Hello' } }
}).mount('#app');
</script>
Vue exposes its entire API on the Vue object. You destructure what you need.
jQuery
jQuery is the classic global scope example:
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>
<script>
$(document).ready(function() {
$('#myElement').hide();
});
</script>
jQuery attaches $ and jQuery directly to window. No namespace separation.
Lodash
Lodash loads as window._:
<script src="https://cdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js"></script>
<script>
const sorted = _.sortBy(users, ['name']);
const chunked = _.chunk(array, 4);
</script>
Class vs Function Syntax in CDN Libraries
Modern libraries use ES6 classes. Older ones use constructor functions. The access pattern is identical — you call them as constructors with new.
<!-- ES6 class library -->
<script src="https://cdn.example.com/library.min.js"></script>
<script>
const instance = new LibraryName.ClassName(options);
</script>
<!-- Constructor function library -->
<script src="https://cdn.example.com/old-library.min.js"></script>
<script>
const instance = new OldLibrary.ClassName(options);
</script>
Accessing Named Exports from ES Modules
ES module CDNs work differently. They don't attach to window. You import them instead:
<script type="module">
import { h, render } from 'https://esm.sh/preact';
import { useState } from 'https://esm.sh/preact/hooks';
render(h('div', null, 'Hello'), document.getElementById('app'));
</script>
ES module CDNs require type="module" on the script tag. The imports work like any other module system.
Module CDN Options Compared
| CDN | URL Pattern | Module Format | Best For |
|---|---|---|---|
| esm.sh | esm.sh/[package] | ESM | Modern projects, tree-shaking |
| unpkg | unpkg.com/[package] | UMD (global) | Quick prototypes, legacy support |
| jsDelivr | cdn.jsdelivr.net/[package] | UMD/ESM | Production, version pinning |
| cdnjs | cdnjs.cloudflare.com/[package] | UMD | Large library catalog |
Handling Namespace Conflicts
Sometimes two libraries use the same global name. This breaks everything. Solutions:
- Use ES modules instead of globals
- Rename one library by wrapping it in an IIFE
- Load libraries in order so the last one wins (not recommended)
// Wrapping to avoid conflicts
const myLib = (function() {
const original = window.LibraryName;
const instance = new LibraryName.Config();
window.LibraryName = original; // restore
return instance;
})();
Getting Started: Practical How-To
Step 1: Find the correct CDN URL
Check the library's documentation. Most list official CDN links. For jsDelivr, the format is:
https://cdn.jsdelivr.net/npm/[package-name]@[version]/[file]
Step 2: Identify the global namespace
Open browser devtools after loading the script. Type the likely namespace in console:
console.log(window.LibraryName);
console.log(window.$);
console.log(window.Vue);
If it returns a function or object, that's your entry point.
Step 3: Check the API structure
// List all exports
console.log(Object.keys(window.LibraryName));
// Check if it's a class
console.log(window.LibraryName instanceof Function);
Step 4: Use the class
<script src="[CDN_URL]"></script>
<script>
const myInstance = new WindowNamespace.ClassName({
// options
});
myInstance.method();
</script>
Common Mistakes That Break Everything
- Loading order — Dependencies must load first. React needs ReactDOM.
- Version mismatches** — React 18 classes don't exist in React 15.
- Minified vs development** — Development builds include more readable errors.
- Missing type="module"** — ES module CDNs fail silently without it.
- CORS blocking** — Some CDNs block cross-origin requests. Use a reliable one.
Production Considerations
CDNs work for development and small projects. For production:
- Pin to specific versions (not
@latest) - Consider self-hosting for reliability
- Use SRI (Subresource Integrity) hashes to verify the file hasn't been tampered with
<script src="https://cdn.jsdelivr.net/npm/react@18.2.0/umd/react.production.min.js"
integrity="sha384-..."
crossorigin="anonymous"></script>
When to Use CDNs vs npm
Use CDNs when:
- Building simple demos or prototypes
- Adding a library to a plain HTML page
- You don't have a build step
Use npm when:
- You have a bundler (Webpack, Vite, Rollup)
- You need tree-shaking
- You're building a real application
CDNs are a shortcut, not a replacement for proper dependency management.