How has JavaScript development changed over the last decade?

... And what new things changed it the most?

Comments

[Kasey Speakman]

A couple of decades here.

• V8
  • Demonstrated JS could be fast enough to run a full client-side app
• Standards bodies cleaning up and expanding features
  • Making it possible to build web apps that previously required plugins (Flash)
• Browsers aligning to standards and fixing their JS bugs
  • Made cross-browser apps less of a hacky mess
• Newer JS standards
  • Avoiding many JS footguns, adding QoL features
• Declarative HTML
  • Coding the HTML you want to see (React and others)
  • Instead of the instructions to get there (jQuery)
• Death of IE
  • No more hacks or fallbacks for out-of-date standards
  • I've fought with IE most of my 2 decades as a developer
  • Effectively dead today with Microsoft's own products not supporting it
  • Official EOL tied with Windows 10, currently Oct 2025

My hopes for the future

• Non-horrible build processes
• WebAssembly complete independence from JS

[leob]

One of the best overviews I've seen here :)

[Karan Gandhi]

We used to make sites with Internet Explorer in mind. (40-50% market penetration, Moz was around 30, Chrome around 10-15%). MS dictated the web in some way or other.

Now we make websites with Chrome in mind(90% is either Chrome or Webkit based, Moz is at 4% ). Google dictates the web.

[Diner Das]

• React introduced a way to handle complexity in UI that informed everything since.
• TypeScript normalized a new way of writing JavaScript
• The Node ecosystem matured with several really great options for getting started.
• VSCode really leveled up the tooling in this ecosystem.

[Jakub T. Jankiewicz]

I remeber when DHTML was a thing, it was when I've started learning JavaScript. And my dream was to create Modal Dialog that you can drag & drop. But the tutorials I've seen was way to complex for me, and I was never be able to do that back then.

So I think that biggest change for me was appearning of frameworks and libraries that was making things like this easy. First DojoToolkit, Prototype.js, Script.aculo.us and later jQuery was first game changer for me.

Also before the frameworks there was AJAX revolution that was big thing, that give birth to JavaScript applications.

Second big thing was AngularJS that was probably the first ever full framework where you could create your own SPA in better way. AngularJS was pioneer after it came the Trinity: Angular, React, and Vue. Each of them can be its own milestone in JavaScript development.

I think that major thing was also NodeJS and appearing of NPM (anyone remembers Bower?). And of course Babel (with other tooling like Grunt/Gulp/Webpack) that allowed to use Latest ECMAScript right now.

[Daniel Schulz]

Framworkization, mostly.
In 2012, jQuery was a good gateway drug to JS. You didn't necessarily have to get it's syntax details, async weirdnesses or compatibility issues, but you'd still have to understand how JS worked.
Now most people learn JS through React, Vue and Angular. Those bring a very nice DX and speed with them, but devs who have no experience outside their framework are on the dry.

The same goes for HTML and CSS, by the way.

[Ben Halpern]

The same goes for HTML and CSS, by the way.

Utility-first CSS (i.e. Tailwind) was a major step in this direction — In a good way for the sake of productivity within that environment. But possibly in a not-so-good way for dependency dependence and learning.

A decade ago I found the CSS libraries available were generally worse than just writing plain old CSS with some sort of self-imposed structure. These days I think some of the new stuff is truly really awesome to use, but it's not necessarily a good thing if it reduces peoples' capacity to interact with CSS proper or write websites that don't require the build step.

[James Thomson]

A decade ago I found the CSS libraries available were generally worse than just writing plain old CSS with some sort of self-imposed structure.

This is so true... the days of adding Bootstrap (or some terrible WP theme) to your project and then having to go through sooooo many classes to overwrite them shudder. I'm so glad those days are gone.

[Vesa Piittinen]

From front-end dev perspective...

In 2013 we could have maybe 10 mostly small scripts on a major site that did all the necessary UI things, loaded when needed per page basis, controlled manually. Most of the time went into ensuring cross-browser compatibility. Fancier ultra interactive and complex UIs were kinda hard to maintain. It was the end of an era just before React become a thing. We lost Opera Presto, we were freed of IE8.

In 2017 sites were written in full JS with massive bundles which resulted to time spent into researching optimization. Code splitting, tree shaking etc. were becoming a thing. Most of your time went into dealing with all the code now in front-end that you never before had to care about as a front-end dev. But hey, you could make maintainable fancy ultra interactive complex UIs. For mobile phones, with responsive design! And curse that you still had to maintain IE11 compatibility.

In 2021 we got started getting solutions that allow getting the performance of 2013 and small bundles, but now with new modules and tooling. But really there are two major changes: you no longer spend much time at all dealing with cross-browser compatibility, and you are not controlling script loading manually as that can be automated by tooling. Every few months a new great HTML/CSS feature lands that allows you to throw away tons of JS.

Overall, from pure front-end developer perspective, there was a lot of innovation and organic progress, but most of it wasn't really focused into solving things that mattered the most. It was a noisy road. But it is now in the past. I think 2022 is probably the most friendly times ever to become a front-end developer for the web. We have moved away from slowly evolving stagnated browser space to true evergreen browser era, and we have tons of JS solutions to pick the best one for each job (or pick the wrong one and figure it out too late).

[Jon Randy 🎖️]

It's become ridiculously overcomplicated and over-engineered

[Isaac Lyman]

I made my first public website in 2011. Back then, the files I wrote were the website. If you used View Source or Inspect Element, you saw the code exactly how I'd written it. No transpilers, minifiers, bundlers, linkers, anything. Cross-browser compatibility was a huge issue; I had to test everything by hand in Chrome, Firefox, and IE. But still, it was a great time to get into the web. All you had to learn was HTML, CSS and JavaScript. Maybe a bit of jQuery.

Today, very little translates literally from the development environment to the public webpage. My code is compiled from TypeScript to JavaScript, from Angular templates to HTML, from scoped SASS to CSS. Every function sits under ten layers of framework code. It's much, much harder to learn anything about a website by opening the dev tools in your browser.

I enjoy using these tools. A lot of them save me time and energy. Smaller teams can take on more ambitious and complex projects. The web can do more than ever before. It's becoming the default platform for small-to-medium-budget software. But I feel a lot of trepidation on behalf of new developers. Just to keep up with modern web development they have to learn HTML, CSS, JavaScript (which is more complex than it used to be), a JS framework or two, a JS testing framework, a JS utility library, a state management library, TypeScript, Webpack, a CSS preprocessor, a CSS framework or component library, NPM, bash/shell, Git, and a handful of third-party packages. And that's just the front-end. A lot of companies want full-stack devs.

Yes, you can still build websites the old way. Yes, each of the technologies I've listed provides unique value. And sure, not all of them are necessary in every project. But still, if you're a new dev trying to land a job in a market that overwhelmingly caters to mid-level and senior devs, you'll likely be expected to interact with all of these. It's overwhelming. I'm lucky I was already in the field when they were being invented and popularized. If they'd all been sprung on me at once it might have scared me off.

Anyway, my hat goes off to anyone who's gotten into web development within the last few years. It's a lot. And if you've been in the field longer than that...well, give an encouraging high-five to the nearest junior dev. They probably need it!

[Jan Küster]

Thanks to babel, typescript and standardization the language became not only powerful but also reliable, compared to 10 years ago.

On the framework and library side we see a huge fragmentation and as an engineer I wonder how many hours/days other people invest into choosing the right tech stack for a certain project. To me it starts to become highly unproductive unless I either stick with big names or with what I am familiar with.

[peerreynders]

With the proposed types there will be no excuse to use TypeScript in the near future and it will die hopefully

The noise around the Types as Comments proposal seems to confirm that there is a lot of wishful thinking in the industry.

For an example of how the TC39 committee operates look at the ECMAScript Observable proposal from 2015 with the last review in 2017:

"Why does this need to be in the standard library?"

Or in terms of the "Types as Comments" proposal: "How does this need to be part of ECMAScript?".

Clearly it benefits TypeScript but it also delegates the implementation effort to the JavaScript engine teams which cannot derive any benefits as "types are comments".

In conclusion I would be extremely surprised if the "Types as Comments" proposal gets anywhere near Stage 4.

Given the tooling involved from the ECMAScript perspective this is much less invasive:

/*+ (string, string?, string?, string) => string */
function stringsStringStrings(p1, p2, p3, p4 = "test") {
  // TODO
}

largely inspired by the Hindley–Milner notation used in Haskell - which also happens to cleanly separate TypeScript's type space from ECMAScript's value space.

Basically this approach puts all the effort on the TypeScript team

• to define a more streamlined version of "types inside comments" as a terser, alternate version to JSDoc (and @type)
• implement this alongside the existing JSDoc functionality and support it in VS Code
• go against the historical "types don't belong inside comments" movement
• convince the existing userbase that interlacing types with names isn't the only way to statically type code.

Simply focusing on promoting @type usage and improving ease of use of all TypeScript features within ECMAScript would be helpful; i.e. streamline today's JSDoc TS features to make TypeScript much more JS friendly.

But even that would be likely ignored by the existing TypeScript userbase because of the familiarity trap even in the face of endorsement by leading personalities.

So it's unlikely that much is going to change in the "typed ECMAScript" landscape (short of V8 just implementing it anyway - but their incentive is pretty low).

[Jon Randy 🎖️]

The proposed 'types in comments' stuff belongs in a browser extension for TS developers. It has absolutely no place in the JS engine