120 JavaScript Today and Tomorrow — From Browser Script to Universal Language

The Technologies That Built the Web

JavaScript began in 1995 as a small scripting language intended to make web pages interactive.

Today it can power sophisticated browser applications, web servers, development tools, desktop applications, mobile applications, real-time communication systems, and much more.

But JavaScript's success created a new problem.

The modern JavaScript world can look bewilderingly complicated.

JavaScript.

ECMAScript.

Node.js.

npm.

React.

Vue.

Angular.

TypeScript.

Webpack.

Vite.

Frameworks.

Libraries.

Packages.

APIs.

Do we really need all of this just to make a website?

The answer is no.

But each of these technologies developed to solve particular problems, and understanding those problems makes the modern JavaScript world much easier to understand.

JavaScript Is Still Built Into the Browser

The most important thing to remember is remarkably simple.

Modern web browsers understand JavaScript directly.

You do not need React.

You do not need jQuery.

You do not need Node.js.

You do not need TypeScript.

You do not need a framework.

A browser can execute ordinary JavaScript by itself.

Everything else is an additional tool or layer created to solve particular development problems.

Vanilla JavaScript

Developers sometimes jokingly call ordinary JavaScript Vanilla JavaScript.

There is no special Vanilla JavaScript product.

It simply means JavaScript without an additional framework or library.

For many websites, ordinary JavaScript can be an excellent solution.

A navigation menu, form enhancement, image gallery, interactive calculator, or small user-interface feature may require relatively little code.

Adding an enormous framework to solve a small problem can create more complexity than value.

Modern JavaScript Is Much Better Than Early JavaScript

The JavaScript available today is dramatically more capable than the language web developers encountered during the 1990s.

The ECMAScript standard has continued evolving.

Modern JavaScript includes modules, classes, improved variable declarations, promises, asynchronous programming features, template literals, destructuring, iterators, generators, and many other improvements.

Browser compatibility has also improved enormously.

Standards are far stronger than they were during the browser wars.

This has reduced the need for some of the compatibility layers developers once depended upon.

Do We Still Need jQuery?

jQuery was enormously important to the development of the modern web.

It simplified JavaScript and hid many differences between browsers.

For years, including jQuery on a website was almost automatic.

But browsers evolved.

Many tasks that once required jQuery can now be performed easily with standard JavaScript and modern browser APIs.

That does not mean jQuery suddenly became bad software.

Millions of existing websites still use it successfully.

Existing software does not need to be rewritten merely because a newer approach exists.

But when developing something new, it is worth asking:

What problem would jQuery solve for this project?

If the answer is “none,” it may not be necessary.

Libraries Versus Frameworks

Two words appear constantly in modern JavaScript development: library and framework.

The boundary between them is not always perfect, but there is a useful conceptual distinction.

A library provides tools that your code can call when needed.

A framework provides a larger structure within which your application is built.

With a library, you often decide the overall architecture and call the library.

With a framework, the framework may define more of the architecture and call your code at appropriate times.

Both approaches can be useful.

React

React was developed at Facebook and released as open-source software in 2013.

It focuses primarily on building user interfaces from reusable components.

A component might represent a button, navigation area, product listing, search result, form, or an entire section of an application.

Instead of manually changing individual pieces of a page whenever data changes, developers can describe what the interface should look like for a particular application state.

React then helps manage the necessary updates.

This approach became enormously influential.

Vue

Vue was created by Evan You and publicly released in 2014.

It also provides a component-based approach to building interactive interfaces.

Vue became popular partly because developers could adopt it gradually.

It could enhance a portion of an existing page or become the foundation of a much larger application.

This flexibility made it appealing to developers who wanted modern application capabilities without necessarily committing immediately to an enormous architecture.

Angular

Angular represents another major approach.

Google originally developed AngularJS, which became influential in the early era of large JavaScript applications.

A substantially redesigned framework later emerged as Angular.

Angular provides a broad collection of tools for building large applications, including components, routing, forms, dependency management, and other application infrastructure.

It can be powerful, but that power comes with additional concepts and complexity.

Which Framework Is Best?

This is often the wrong first question.

A better question is:

What problem are we trying to solve?

A large application with many interactive states may benefit enormously from a framework.

A mostly informational website with a few interactive features may not.

Choosing technology should begin with the problem rather than the popularity of the tool.

The Framework Cycle

JavaScript development has become famous for rapid changes in tools and frameworks.

A new library appears.

Developers become excited.

It becomes popular.

New problems appear.

Another tool attempts to solve those problems.

Eventually developers sometimes rediscover that the browser itself has gained capabilities that eliminate the need for part of the toolchain.

This cycle can make JavaScript development seem more unstable than the underlying language really is.

JavaScript is more stable than the ecosystem surrounding JavaScript sometimes appears.

Node.js Changed Where JavaScript Could Run

One of the largest changes in JavaScript's history was Node.js.

Node.js allows JavaScript to execute outside the web browser.

That means JavaScript can run on a server.

A traditional PHP architecture might look like:

Browser → Apache/nginx → PHP → MySQL

A Node.js application might instead look conceptually like:

Browser → nginx → Node.js → Database

JavaScript can therefore operate on both sides of the connection.

Does Node.js Replace PHP?

It can perform many of the same server-side jobs, but that does not mean PHP automatically needs to be replaced.

PHP and Node.js are different tools with different ecosystems and development models.

Millions of excellent applications run on PHP.

Millions of excellent applications use Node.js.

The existence of a newer alternative does not make a proven technology useless.

The better question remains:

Which technology fits the application, the developers, the infrastructure, and the maintenance requirements?

JavaScript Became a Development Tool Too

Once JavaScript could run outside the browser, developers began using it for much more than server applications.

JavaScript could automate development tasks.

It could process files.

It could build and optimize website resources.

It could run tests.

It could start local development servers.

It could transform newer JavaScript syntax into versions compatible with older browsers.

The language used by the website could now also help build the website.

npm

Node.js helped produce another enormously important part of the JavaScript ecosystem: npm.

Npm provides access to a massive ecosystem of reusable JavaScript packages.

Instead of writing every capability from scratch, developers can install packages created by other developers.

A package might provide date handling, testing, database access, image processing, user-interface components, build tools, or thousands of other capabilities.

This greatly accelerates development.

But Dependencies Have a Cost

Reusable packages are powerful, but every dependency introduces another piece of software into the project.

That software may itself depend on other packages.

Those packages may depend on still more packages.

A project can accumulate hundreds or thousands of dependencies surprisingly quickly.

Each dependency represents code that may need updates, may contain bugs, may introduce security vulnerabilities, or may eventually stop being maintained.

Convenience and complexity often arrive together.

The Supply Chain Became Part of Security

Modern application security therefore extends beyond the code a developer personally writes.

If an application depends upon third-party packages, those packages become part of its software supply chain.

A vulnerability or malicious change in a widely used dependency can potentially affect many applications.

Developers increasingly need to know not only:

“Is my code secure?”

but also:

“What code have I invited into my application?”

TypeScript

As JavaScript applications became larger, developers encountered another challenge.

JavaScript is dynamically typed, which provides flexibility but can allow certain mistakes to remain unnoticed until code executes.

Microsoft introduced TypeScript in 2012.

TypeScript extends JavaScript with a system for describing types and other development-time information.

TypeScript code is then transformed into JavaScript that browsers or JavaScript runtimes can execute.

This means browsers generally do not need to understand TypeScript directly.

The final language reaching the browser is still JavaScript.

Why Use TypeScript?

On a small script, additional type information may provide limited benefit.

On a large application maintained by many developers, it can become extremely valuable.

Types can help editors understand the code.

They can identify certain mistakes before the program runs.

They can document how pieces of the application are expected to interact.

Once again, the value depends upon the problem being solved.

Build Tools

Modern JavaScript development introduced another category of technology: build tools.

Tools can combine files, optimize resources, transform syntax, process modules, remove unused code, and prepare an application for production.

Webpack became one influential example.

More recent tools such as Vite have attempted to make modern development faster and simpler.

These tools can be extremely useful for complicated applications.

They can also make a simple website unnecessarily complicated if introduced without a reason.

The Browser Has Become Much More Powerful

While frameworks and tools were evolving, browsers themselves continued improving.

Modern JavaScript can use standardized browser APIs to perform tasks that once required plugins, browser-specific code, or external libraries.

JavaScript can communicate with servers using technologies such as Fetch.

It can store information locally.

It can manipulate graphics.

It can work with audio and video.

It can create real-time network connections.

With appropriate permissions, it can interact with capabilities such as cameras, microphones, notifications, and other device features.

The browser has become a sophisticated application platform.

Fetch and the Modern AJAX Idea

The term AJAX is heard less frequently today, but its central idea is everywhere.

JavaScript routinely communicates with servers in the background.

Modern code often uses the Fetch API rather than the older XMLHttpRequest interface.

The pattern remains familiar:

JavaScript → Request → Server → Data → JavaScript Updates Interface

What once seemed revolutionary became ordinary web development.

JSON Replaced XML in Many Applications

The “X” in AJAX originally referred to XML.

But modern applications frequently exchange information using JSON—JavaScript Object Notation.

JSON provides a relatively simple textual format for structured information.

It works naturally with JavaScript and is also widely supported by other programming languages.

APIs throughout the web commonly exchange JSON.

APIs Connect the Modern Web

JavaScript applications increasingly communicate with APIs.

An API allows one piece of software to request information or services from another.

A webpage might use an API to retrieve products, weather information, search results, account information, maps, payment information, or countless other forms of data.

The page does not need to know how the remote system internally performs its work.

It needs to understand the agreed method of communication.

This is another form of abstraction.

The Front End and Back End Became More Separate

Traditional server-generated websites often produce most of their HTML on the server.

PHP retrieves information and constructs the page.

The browser receives that finished HTML and displays it.

Many modern applications separate the front end and back end more strongly.

The server may primarily provide data through an API.

JavaScript in the browser may then construct much of the visible interface.

Neither model is universally superior.

They are different architectures suited to different needs.

Server Rendering Returns

Interestingly, JavaScript development has also rediscovered the value of generating HTML on the server.

Pure client-side applications can sometimes create problems involving initial loading speed, search engines, accessibility, and complexity.

Modern JavaScript frameworks increasingly support server-side rendering or combinations of server and browser rendering.

The industry sometimes moves forward by rediscovering useful ideas from the past and combining them with newer technology.

JavaScript and Performance

JavaScript can create extraordinary experiences.

It also has a cost.

The browser must download JavaScript.

It must parse it.

It must compile or interpret it.

It must execute it.

That consumes processor time, memory, network bandwidth, and battery power.

On a powerful desktop computer with a fast connection, excessive JavaScript may go unnoticed.

On a slower phone or connection, the difference can be significant.

The Fastest JavaScript Is Sometimes No JavaScript

This leads to an important development principle.

If HTML can perform the job, use HTML.

If CSS can perform the job, use CSS.

If JavaScript genuinely adds useful behavior, use JavaScript.

Each technology has strengths.

Using the simplest appropriate layer can improve performance, reliability, accessibility, and maintainability.

JavaScript and Accessibility

Modern JavaScript applications can be highly accessible.

But developers must preserve the semantics and interaction patterns people depend upon.

A custom clickable object may visually resemble a button while failing to behave like one for a keyboard user or screen reader.

JavaScript should enhance the underlying web rather than casually discard the accessibility features browsers already provide.

Good HTML remains the foundation.

Progressive Enhancement Still Makes Sense

Progressive enhancement remains a valuable philosophy.

Start with meaningful HTML.

Use CSS for presentation.

Add JavaScript where it improves the experience.

This does not mean every application must work perfectly with JavaScript disabled.

Some applications fundamentally depend upon JavaScript.

It means we should understand which layer is responsible for which job.

JavaScript and Privacy

JavaScript can also participate in analytics, advertising, tracking, fingerprinting, and other techniques that raise privacy concerns.

Third-party scripts embedded in websites may communicate with outside services.

This creates another reason to think carefully about which scripts a website loads.

A third-party JavaScript file is not merely an image or piece of text.

It is software being allowed to execute within the context provided by the browser.

That deserves consideration.

JavaScript and Security

The browser places significant restrictions around JavaScript, but application security remains critical.

Cross-Site Scripting remains an important concern.

Third-party dependencies can introduce vulnerabilities.

Compromised external scripts can create risks.

Applications must carefully handle untrusted information.

Security headers and browser policies can provide additional layers of protection.

As with every other part of our technology stack:

Security is a system of layers.

WebAssembly

JavaScript is no longer the only way to execute sophisticated application code inside modern browsers.

WebAssembly, commonly abbreviated Wasm, provides a compact execution format designed to run efficiently in web environments.

Programs written in languages such as C, C++, Rust, and others can be compiled into WebAssembly.

This can make demanding applications practical inside browsers.

WebAssembly does not necessarily replace JavaScript.

The two can work together.

Once again, a new technology often joins an existing one rather than simply eliminating it.

JavaScript Beyond the Browser

JavaScript now appears in places Brendan Eich could hardly have anticipated in 1995.

It can power servers through Node.js.

It can participate in desktop applications.

It can help create mobile applications.

It can run development tools.

It can automate tasks.

It can interact with hardware and embedded environments.

A language designed for web-page scripting became a broadly useful computing language.

Then Artificial Intelligence Arrived

JavaScript may be one of the languages most affected by AI-assisted programming simply because so much JavaScript code exists and so many developers use it.

AI systems can already generate JavaScript functions.

They can explain unfamiliar code.

They can convert jQuery into modern JavaScript.

They can identify bugs.

They can suggest accessibility improvements.

They can generate API requests.

They can help modernize older applications.

They can explain complicated frameworks.

For someone maintaining websites built across many generations of web technology, that can be enormously useful.

AI Can Reduce the Knowledge Barrier

Modern development sometimes requires remembering an overwhelming amount of syntax, commands, APIs, configuration formats, and framework conventions.

AI can act as an interactive reference.

Instead of memorizing every option, a developer can increasingly describe the desired result and ask for help constructing it.

This may make sophisticated programming accessible to more people.

But it also changes which skills matter most.

Understanding May Matter More Than Memorizing

If AI can remember syntax, developers may spend less time memorizing exact commands.

But they still need to understand concepts.

Is this code running in the browser or on the server?

Where does the data come from?

What happens if the network request fails?

Is the information trusted?

Could this create a security problem?

Is this accessible?

Do we need this dependency?

Could HTML or CSS solve the problem more simply?

Those questions require understanding, not merely code generation.

AI Can Also Generate Bad JavaScript Very Quickly

AI-generated code is still code.

It can contain bugs.

It can use outdated APIs.

It can introduce security vulnerabilities.

It can add unnecessary dependencies.

It can produce code that appears convincing while solving the wrong problem.

The ability to generate code faster increases the importance of being able to evaluate it.

Will We Still Write JavaScript?

Probably, but the way we write it may change substantially.

A developer might increasingly describe desired behavior in ordinary language.

AI may generate the first implementation.

The developer may then test it, inspect it, refine it, and integrate it into the larger system.

Over time, humans may interact less frequently with some of the underlying code.

But the browser will still need executable instructions.

The language can become less visible to the human without becoming less important to the machine.

The Technology Can Become Invisible Without Becoming Unimportant

Our recurring theme appears again.

A future developer may tell an AI system:

“When the visitor selects this option, retrieve the updated information and display it without reloading the page.”

The AI might generate JavaScript.

The developer might never manually write the Fetch request or event handler.

But JavaScript may still be what the browser ultimately executes.

The human interface changes.

The underlying technology remains.

JavaScript Tomorrow

JavaScript's future will probably involve both expansion and simplification.

Browsers will continue gaining capabilities.

The ECMAScript standard will continue evolving.

Frameworks will come and go.

Development tools will become faster.

WebAssembly will complement JavaScript for certain workloads.

AI will increasingly generate, explain, test, and optimize code.

And developers may gradually move from manually writing every instruction toward describing what they want software to accomplish.

But JavaScript has one enormous advantage that is difficult to displace:

It is already built into the web browser.

The Language That Refused to Stay Small

JavaScript began as a ten-day project intended to add simple scripting to Netscape Navigator.

It survived browser wars.

It became standardized.

It helped create AJAX.

It powered the rise of web applications.

It escaped the browser through Node.js.

It created an enormous package ecosystem.

It became the foundation for major application frameworks.

And now it is entering an era in which artificial intelligence may increasingly help write it.

JavaScript repeatedly grew beyond the role imagined for it.

There is little reason to assume that growth is finished.

Use the Simplest Tool That Solves the Problem

Perhaps the most useful lesson from modern JavaScript is not about a particular framework.

It is about choosing technology deliberately.

Use HTML when HTML solves the problem.

Use CSS when CSS solves the problem.

Use JavaScript when behavior requires JavaScript.

Use a library when the library saves meaningful work.

Use a framework when the application's complexity justifies a framework.

Use Node.js when it fits the server-side problem.

Use TypeScript when its additional structure provides real value.

Technology should serve the project.

The project should not exist to serve the technology.

Next: The History of CSS

JavaScript gives the web behavior.

But before we continue exploring what a webpage can do, we should examine another technology that transformed what a webpage could look like.

Early HTML mixed document structure and presentation together.

Developers used tags, tables, transparent images, and increasingly elaborate tricks to control page appearance.

The web needed a better way to separate content from presentation.

That solution became:

Cascading Style Sheets — CSS.

Next in The Technologies That Built the Web, we will explore how CSS emerged from the chaotic design experiments of the early web, why the word “cascading” matters, how browser wars made CSS development difficult, and how a technology once used mainly for fonts and colors eventually learned to create responsive layouts, grids, animations, and sophisticated modern interfaces.