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.
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.
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.
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.
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.
#ActuallyAutistic web dev. Does front of the front-end. Loves perf and minimalism. Prefers HTML, CSS, Web Standards over JS, UX over DX. Hates div disease.
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).
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!
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
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.
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:
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).
I think Microsoft finally ending the browser wars started a new era that made compatibility-centered frameworks like jQuery mostly obsolete, new MVC-pattern frameworks took over in the front-end.
At the same time, transpilation really took off, hastening the adoption and development of new language features in JavaScript/ECMAscript and Web APIs. The overall tooling improved beyond recognition.
This powered moving logic from the back-end into the front, blurring the lines between web sites and applications. Static apps, powered by minimal back-ends, became the new norm.
Interestingly, the revolution keeps turning. With JavaScript running in the back-end, we're going full circle with remix or astro and having the same logic that we previously moved to the front-end inside the server to increase rendering speed.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
In 2012, the jokes about JS being a ridiculous way to program were still fairly real. But if you hung on to that attitude, you probably got left behind.
"Ridiculous" meaning using the inconsistent language for anything other that jQuery-driven UI updates.
But since then the language has improved, the ecosystem has plowed along at breakneck pace, and TypeScript is pervasive.
It definitely could be that way still but the critical thing promises added over callbacks was an immediate return (of a promise), where as callbacks didn't immediately return.
This lent itself more to a chainable .then style that could be structured into a relatively flat format. async/await just took that one step further by enforcing the linear progression. Interestingly, I see people awaiting every possible async call now even when it's not necessary.
2009, Node.js was released and gained in popularity quickly, which helped many JS developers to implement software that doesn't run in the browser. While this was before the last decade, I think the move of JS developers out of the browser took a few yerars.
JS engines were added to iOS and Android, so JS developers also gained access to the mobile space.
Function as a service offerings all included JS right from the start, so JS was a main participant in the serverless movement.
Web3 is basically Web2 frontends with decentralized backends, so JS plays that game too.
In terms of technical changes, the ES2015 changes gave JS quite a facelift. Promises, async/await, arrow functions, classes and a native module system made JS a more "mature" programming language.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Encourages microservices in cloud platforms where they complicate architecture way more than help
Not sure how math being slower relates to complexity but okay nobody claims that node is the fastest, it's not supposed to be fast is not the only metric I suppose.
The question Ben asked was what has changed and JavaScript moving to the backend was absolutely one of them.
I can see you have some issue with JavaScript people getting involved in a really complected world of backend and screwing it all up which is really short sighted, you can know a lot of typed languages and still write JavaScript
Your tech stack matters a lot more than just whether you like a language or not.
That is completely fictional, your tech stack matters to it's particular application, high per for high perf requirements.
Choosing a language for light speed when your making a to-do list is not a good idea contrary what some might tell you.
Being able to maintain a stack is, look at dev.to it's ruby, is ruby known to be fast? No, is it beloved, I hear it is
Yes but you write your code in ASP, you can write application and don't touch JS at all. The same Google GWT and R Shiny are not JavaScript. We talk about Pure JavaScript, not some Hybrid. ASP.Net is C# framework not JavaScript framework.
Check Wikipedia there is only one mention of JavaScript in this article. I think that you're confusing web app development with JavaScript development.
Back in 2000 I used to build website for IE 5.5 and Netscape Navigator using HTML, CSS and vanilla JavaScript. There were WYSIWYG editors for HTML like Microsoft Frontpage and Dreamweaver.
Today to publish front-end code the developer has to use several tools and technologies like IDE, Browser Support, Responsiveness, React/Angular/Vue/preact/next/gatasby etc., LESS/SCSS/Styled Component ,TypeScript, Unit Testing, linting, Github/BitBucket, NPM, Webpack, Node.js, DevOps and the list goes on...
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Also I think that you don't understand the purpose of this post and my comment. This is my personal milestones in JavaScript development. You can't say that I'm wrong if I write my own experience with JavaScript development. Your experience may be different why don't you write your own milestones instead of jumping on me.
A couple of decades here.
My hopes for the future
One of the best overviews I've seen here :)
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.
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.
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.
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.
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.
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).
It's become ridiculously overcomplicated and over-engineered
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!
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.
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:
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
@type)Simply focusing on promoting
@typeusage 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).
The proposed 'types in comments' stuff belongs in a browser extension for TS developers. It has absolutely no place in the JS engine
I think Microsoft finally ending the browser wars started a new era that made compatibility-centered frameworks like jQuery mostly obsolete, new MVC-pattern frameworks took over in the front-end.
At the same time, transpilation really took off, hastening the adoption and development of new language features in JavaScript/ECMAscript and Web APIs. The overall tooling improved beyond recognition.
This powered moving logic from the back-end into the front, blurring the lines between web sites and applications. Static apps, powered by minimal back-ends, became the new norm.
Interestingly, the revolution keeps turning. With JavaScript running in the back-end, we're going full circle with remix or astro and having the same logic that we previously moved to the front-end inside the server to increase rendering speed.
Node.js changed the game and it's easy to think it's always been here but it hasn't
In 2012, the jokes about JS being a ridiculous way to program were still fairly real. But if you hung on to that attitude, you probably got left behind.
"Ridiculous" meaning using the inconsistent language for anything other that jQuery-driven UI updates.
But since then the language has improved, the ecosystem has plowed along at breakneck pace, and TypeScript is pervasive.
It's a really different landscape now.
It definitely could be that way still but the critical thing promises added over callbacks was an immediate return (of a promise), where as callbacks didn't immediately return.
This lent itself more to a chainable
.thenstyle that could be structured into a relatively flat format. async/await just took that one step further by enforcing the linear progression. Interestingly, I see people awaiting every possible async call now even when it's not necessary.10 years ago we didn't even have Promises natively. Async was handled by callbacks making for these terrible horizontal prymids of code.
2009, Node.js was released and gained in popularity quickly, which helped many JS developers to implement software that doesn't run in the browser. While this was before the last decade, I think the move of JS developers out of the browser took a few yerars.
JS engines were added to iOS and Android, so JS developers also gained access to the mobile space.
Function as a service offerings all included JS right from the start, so JS was a main participant in the serverless movement.
Web3 is basically Web2 frontends with decentralized backends, so JS plays that game too.
In terms of technical changes, the ES2015 changes gave JS quite a facelift. Promises, async/await, arrow functions, classes and a native module system made JS a more "mature" programming language.
Not having strict types is one of JavaScript's best features
Not sure how math being slower relates to complexity but okay nobody claims that node is the fastest, it's not supposed to be fast is not the only metric I suppose.
The question Ben asked was what has changed and JavaScript moving to the backend was absolutely one of them.
I can see you have some issue with JavaScript people getting involved in a really complected world of backend and screwing it all up which is really short sighted, you can know a lot of typed languages and still write JavaScript
That is completely fictional, your tech stack matters to it's particular application, high per for high perf requirements.
Choosing a language for light speed when your making a to-do list is not a good idea contrary what some might tell you.
Being able to maintain a stack is, look at dev.to it's ruby, is ruby known to be fast? No, is it beloved, I hear it is
Yes but you write your code in ASP, you can write application and don't touch JS at all. The same Google GWT and R Shiny are not JavaScript. We talk about Pure JavaScript, not some Hybrid. ASP.Net is C# framework not JavaScript framework.
Check Wikipedia there is only one mention of JavaScript in this article. I think that you're confusing web app development with JavaScript development.
Back in 2000 I used to build website for IE 5.5 and Netscape Navigator using HTML, CSS and vanilla JavaScript. There were WYSIWYG editors for HTML like Microsoft Frontpage and Dreamweaver.
Today to publish front-end code the developer has to use several tools and technologies like IDE, Browser Support, Responsiveness, React/Angular/Vue/preact/next/gatasby etc., LESS/SCSS/Styled Component ,TypeScript, Unit Testing, linting, Github/BitBucket, NPM, Webpack, Node.js, DevOps and the list goes on...
Frankly speaking I just miss those days!!
ouch
I no interest in furthering this narrow discussion on node for the server when a large proportion of my node apps are tools, good day.
Lots!
I'll leave it to others to expand on the details. But believe me, it's lots! ;-)
JavaScript Web Almanac 2021 covers exactly that!
Nice video that show the JavaScript development progress:
The Story of Next.js
Evidence to support these claims?
ASP.Net is not JavaScript if you're not aware. There was also GWT but we don't talk about other langauges.
I am tempted to say it's no longer called JavaScript but rather TypeScript ... ;)
You can say whatevery you want, but I don't think you're right. Of course you don't need to agree with me. You have your own option I have mine.
Also I think that you don't understand the purpose of this post and my comment. This is my personal milestones in JavaScript development. You can't say that I'm wrong if I write my own experience with JavaScript development. Your experience may be different why don't you write your own milestones instead of jumping on me.
Also I've written:
It was first framework that added reactive way of writing SPA with double data binding, with declarative way of writing components.