I think today the Javascript ecosystem looks much better than 3 years ago, at the peak of Javascript fatigue.
What we had actually was tooling fatigue, and not language features fatigue. Today, with CLI tools like the Angular CLI, we have a ready to use optimized bundle via one out of the box CLI command, so no longer do we have to learn how to configure Gulp or Webpack.
I'm very glad that I decided not to learn Webpack and stick to the CLI, now Webpack is going to be replaced by Bazel transparently, and from a user perspective, nothing changes other than getting an even faster build and a smaller bundle transparently, without having to be a build tools expert.
I can now focus on developing the application and not the tooling, which is awesome for me. There are only so many hours in the day and I like to focus my learning budget on what moves the needle most.
Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse.
You just mentioned webpack is going to be replaced?? That's unfortunately very typical for the JS eco system. 7 years ago we had Grunt, then about two years later Gulp, then about a year later Webpack, now apparently Bazel? Interesting, never heard of it, but I still feel fatigue. I spent quite some time to master Webpack, and again I'll have to start all over for the 4th time now learning the next bundler..
I just started with React Hooks some months ago. First we had mixins(about 5 years ago), that was replaced with Higher Order Components, then we had to start writing React in the brand new ES6 classes, then we saw the Render Props, the Pure Functions, etc.. and now ES6 classes and all the rest are deprecated, because Dan Abramov had another idea for again a new design principle that's just less than a year old: Hooks.. Oh, and we don't do that in JS, that is not sane anymore, every job I get nowadays is Typescript.
I mean, think twice before you say the Javascript fatigue is past it's peak.
> I think today the Javascript ecosystem looks much better than 3 years ago
That’s certainly up for debate. Today you have NPM being treated as an Advertisement delivery tool. See the latest version of StandardJS and a new package called Funding. IMO it’s a pretty massive setback for the ecosystem.
I am hoping to write a second part to this post eventually. It was honestly sitting in my drafts folder for a solid 6-8 months, and then I finally cleaned it up and published it two weeks ago. But I still have more thoughts!
Not sure how Webpack is being attributed as being a part of Javascript here. It's a bundler, with Javascript support being one small piece in a much larger puzzle. It's not even the only bundler out there, JSPM is currently in beta which goes in a different direction than Webpack, then you have Parcel and other options as well.
>Understanding babel, and why it’s important
Eh. I haven't used Babel in years since switching to TypeScript.
This doesn't seem very focused on Javascript, seems like a lot of emphasis being placed on tooling more than the language itself.
I agree with your assessment, but the “major” web framework ecosystem (React, Angular, Vue) all use webpack as a de facto part of their toolchain. And webpack, in turn, relies on babel. Other bundlers are commonly used as part of plugin system.
Regardless of transpiler tooling, the tooling is how most people are confident in using the most modern variants of JavaScript code. So it’s an important part of the modern js story.
>Whereas Java and C users may still have debates about where, exactly, open source projects should publish their releases, that issue is settled in the JavaScript community
I thought Maven Central was pretty much the canonical answer in Java land. Nobody cares what tool you actually use to pull these down (SBT, Gradle, Maven..).
>What this means, however, is that to do JavaScript development “The Modern Way”, while adopting its new features, you simply must use a local transpiler toolchain
Surely this depends on the browsers your application is targeting? And presumably, the sort of feature you're using (can it be polyfilled or is it a syntax feature?).
>In 2018-2019, several things have changed about the JavaScript community. Development tools are no longer fledgling, but are, instead, mature. There are built-in development tools in all of Safari, Firefox, and Chrome browsers
I agree they're decent, but there are still cases where they struggle - particularly after code has been transpiled. I still run into issues these days where the browser is trying to show a source-mapped JS file instead of the actual bundle code which masks a real issue.
If you don't care about IE11 (or you polyfill), it's hardly your only choice. wasm is still far from perfect but there's no question you can start writing some logic in languages other than JavaScript, and interoperate.
>If you’re the kind of programmer who thinks, “I code in Python/Java/Ruby/C/whatever, and thus I have no use for JavaScript and don’t need to know anything about it”, you’re wrong, and I’ll describe why. Incidentally, you were right in 1998, you could get by without it in 2008, and you are dead wrong in 2018.
>To be a serious programmer, you’ll have to know JavaScript’s Modern and Good Parts — as well as some other server-side language, like Python, Ruby, Go, Elixir, Clojure, Java, and so on
This reads to me as downright patronising to e.g. embedded software engineers who might be writing hardware drivers in C/C++ day to day.
Perhaps this should read "to be a serious web developer with front-end responsibilities" (JavaScript is sufficient, not necessary on the back-end and - of course, subjectively - there are much better choices to use).
Thanks for bringing attention to WebAssembly, far from perfect but with time it could rise to become the default for front ends. Javascript's popularity was purely accidental and doesn't have to be the only option for in-built browser applications.
i agree with the sentiment. i was just thinking about it yesterday. what if there was a pure javascript based system programming language? with none of the event loop thingies?
i mean can we have a normal javascript that compiles to a x64 binary and calls the OS?
It looks like an interesting light summary of the state of things. The technical articles might be more useful, for me.
As a primarily Python/C++ developer who dabbled with JS in the early and late 2000s, can anyone recommend an efficient way to get started with modern JS development for hints like interactive frontends with a different-language. I’m comfortable with large language ecosystems, but there seems to be an intimidating number of incompatible paradigms - and there’s both the technology and toolings.
Easiest to start with one track e.g. react/tutorials and branch from there? Good books that approach the problem efficiently and for a decent existing programmer/scientist?
A good high level overview of the moving parts involved in front end dev is https://roadmap.sh/frontend. Not all of it is used all the time, but if you can talk intelligently about many of the parts you are doing fine.
My recommendation to people learning specific frameworks such as react is to start with vanilla react (their doc's are quite good). Then, after building a small app that solves a problem for yourself, you'll start realising when you have bugs and other maintainability issues related to state management. At that point, it is worthwhile looking into redux (or another state management library). Otherwise if you go straight to react + redux it can just feel like a lot of boilerplate for no reason.
Same with TypeScript. I think type safety offers a huge reduction in the number of bugs in large systems. But it isn't required when first learning react.
Javascript is not the only answer to frontends ever since WebAssembly arrived. Microsoft is releasing Blazor for C# in a month (server-side first then client-side) [1] and there are similar projects being worked on for Rust, Java, etc.
I have some ES6 compliant JavaScript to run on the browser. Now I would like to compile it into web-assembly and serve that from a server to the browser, to make it faster to run and download.
Is that possible with the modern JavaScript tools?
Web assembly isn't inherently faster than well-optimized Javascript. You save the parsing and compilation overhead of JS, but right now the focus with web assembly isn't on speed yet.
You also can't just compile any Javascript to WASM, the closest thing to this is AssemblyScript:
This compiles a subset of Typescript to web assembly. And you have to take "subset" seriously here, web assembly is very limited in how memory is managed, you can't just drop your Javascript in there and get web assembly out.
Depends on the specifics of your needs. Web-assembly is still slower than the V8 JIT compiler for use cases where you want to interact with the DOM. Interaction with the DOM, of course, is one of the main reasons to deliver code to a browser. But if you need to, say, create a cryptominer in the browser, then a TypeScript variant of JavaScript can target WebAssembly. You are trading out a superb JIT compiler with look-ahead and runtime optimizations for a relatively immature compiler, however.
If you want your process to run on the server, and merely pass the result to the client, you can compile JavaScript to C, and then to a binary, with QuickJs. Most folks will just use Nodejs, however (which also uses V8)
It is, if you include a JS interpreter in your wasm bundle.
But it isn't a good idea. JS is a language that needs a runtime, the browser _has_ a JS engine, and not using that would just be counterproductive and wasteful.
From what I've heard WASM isn't a viable alternative in the first place. It's good for compute-heavy tasks, but the overhead involved in going from browser to native to browser is too much to make WASM an alternative to what JavaScript is usually used for -- rendering interfaces and making pages interactive.
I was talking about Parse.ly's analytics engine, where most of the data we provide to our customers on first-party analytics around their audience stems from some lightweight JavaScript code they embed in their websites. It's now installed on thousands of high-traffic sites[1] and provides analytics on over a billion web/mobile browsers per month (as described in this Strata talk[2], for example).
It was a fascinating piece of code to work on because not only did it have to be lightweight and fast across all browsers, but it also had to be tiny to embed, and it needed to be x-browser tested all the way back to IE6 and strange mobile browsers. Plus, at the time it was originally written (2010-2012), there were hardly any good JS build tools outside of early versions of uglifyjs.
Over the years, other engineers have improved the performance even further, while retaining the kernel of the code. We even did a change last year which improved client-side performance through a number of clever build/CDN tricks. We've also had to hold our ground firmly on privacy, which it turns out is one of the key areas third-party JavaScript started to take a turn in the wrong direction, especially in the adtech universe. (We are a content analytics company, with a similar SaaS business model to MixPanel for product analytics and NewRelic for performance analytics. So, for us, privacy is paramount.) I wrote about this here: https://blog.parse.ly/post/3394/analytics-privacy-without-co...
I'm the original author. This is just an oversight -- the original draft I wrote here was at a time when ES2019 wasn't yet published. Agree that you can safely use any ratified (recent) standard with Babel.
Given how fashion-driven the web industry seems to be, my guess is that some new hotness will steal the stage from it in the next few years. I seem to recall seeing tons of posts about CoffeeScript maybe around 6~7 years ago, but it doesn't seem to be very popular any more...
Maybe TypeScript will turn out to have more staying power, but my current guess is that something will happen that makes another technology -- probably WebAssembly -- very popular in the next few years and that will kill off a lot of the hype around TypeScript. Then that will itself mostly get killed off by some other technology about 3~5 years after it hits peak popularity, and so on...
I could be completely wrong though, of course! Predicting the future is hard. This is just my guess based on handwavey recollection of the last decade and a half of web trends.
I'm the original author of this post. I'd say that it's very unlikely that TypeScript will supplant JavaScript. To quote Crockford in 2008:
"Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important. It is better to be lucky than smart."
TypeScript is a very smart language, but then, so are Dart, CoffeeScript, ClojureScript. I suspect that if code durability is what matters to you, JS (and the ES evolutions thereof) will have the real staying power. Plus, not everyone is sold on the value of static types, but everyone is sold on the value of JavaScript.
TypeScript adoption has been swift and decisive. In 2019, the majority of js developers that take surveys use TypeScript.
Edit: Mea culpa. I got my numbers mixed up, or whatever source I thought I remembered just doesn’t exist. 46% in 2018 (state of js) says nothing about 2019, and is not a majority. That 46% is also backed up by a similar survey that npm ran. It’s worth adding though, I think, that js devs benefit from ts type inferencing and IDE support even if they aren’t using it directly
not sure Anders/microsoft wanted to replace javascript with typescript. the problem is this imo.
to use javascript -- or say python -- in an corporate/enterprise environment, you need to analyze your code base. static analysis is what worked well and still does but you need types. ofc having types has other major benefits but this is the big one for me at least.
No you dont need a transpiler. The new language features are exiting, but its really just old concepts from other languages. And IMHO these old conceps are not better and some of them are worse. JavaScript was lucky and got some things right, like first class functions, prototype instead of classes, function scope, no need for getter/setters. Node.js also got lucky with its module system. JavaScript was lucky because it was async. Javascript got adopted in more then just browsers because it was lightweight. Etc.
[+] [-] vfc1|6 years ago|reply
What we had actually was tooling fatigue, and not language features fatigue. Today, with CLI tools like the Angular CLI, we have a ready to use optimized bundle via one out of the box CLI command, so no longer do we have to learn how to configure Gulp or Webpack.
I'm very glad that I decided not to learn Webpack and stick to the CLI, now Webpack is going to be replaced by Bazel transparently, and from a user perspective, nothing changes other than getting an even faster build and a smaller bundle transparently, without having to be a build tools expert.
I can now focus on developing the application and not the tooling, which is awesome for me. There are only so many hours in the day and I like to focus my learning budget on what moves the needle most.
[+] [-] siempreb|6 years ago|reply
Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse.
You just mentioned webpack is going to be replaced?? That's unfortunately very typical for the JS eco system. 7 years ago we had Grunt, then about two years later Gulp, then about a year later Webpack, now apparently Bazel? Interesting, never heard of it, but I still feel fatigue. I spent quite some time to master Webpack, and again I'll have to start all over for the 4th time now learning the next bundler..
I just started with React Hooks some months ago. First we had mixins(about 5 years ago), that was replaced with Higher Order Components, then we had to start writing React in the brand new ES6 classes, then we saw the Render Props, the Pure Functions, etc.. and now ES6 classes and all the rest are deprecated, because Dan Abramov had another idea for again a new design principle that's just less than a year old: Hooks.. Oh, and we don't do that in JS, that is not sane anymore, every job I get nowadays is Typescript.
I mean, think twice before you say the Javascript fatigue is past it's peak.
[+] [-] move-on-by|6 years ago|reply
That’s certainly up for debate. Today you have NPM being treated as an Advertisement delivery tool. See the latest version of StandardJS and a new package called Funding. IMO it’s a pretty massive setback for the ecosystem.
1: https://github.com/standard/standard/issues/1381
2: https://github.com/feross/funding
[+] [-] pixelmonkey|6 years ago|reply
Glad to answer any questions about the post here.
I am hoping to write a second part to this post eventually. It was honestly sitting in my drafts folder for a solid 6-8 months, and then I finally cleaned it up and published it two weeks ago. But I still have more thoughts!
[+] [-] CraigJPerry|6 years ago|reply
[+] [-] DigitalSea|6 years ago|reply
Not sure how Webpack is being attributed as being a part of Javascript here. It's a bundler, with Javascript support being one small piece in a much larger puzzle. It's not even the only bundler out there, JSPM is currently in beta which goes in a different direction than Webpack, then you have Parcel and other options as well.
>Understanding babel, and why it’s important
Eh. I haven't used Babel in years since switching to TypeScript.
This doesn't seem very focused on Javascript, seems like a lot of emphasis being placed on tooling more than the language itself.
[+] [-] IggleSniggle|6 years ago|reply
Regardless of transpiler tooling, the tooling is how most people are confident in using the most modern variants of JavaScript code. So it’s an important part of the modern js story.
[+] [-] lol768|6 years ago|reply
I thought Maven Central was pretty much the canonical answer in Java land. Nobody cares what tool you actually use to pull these down (SBT, Gradle, Maven..).
>What this means, however, is that to do JavaScript development “The Modern Way”, while adopting its new features, you simply must use a local transpiler toolchain
Surely this depends on the browsers your application is targeting? And presumably, the sort of feature you're using (can it be polyfilled or is it a syntax feature?).
>In 2018-2019, several things have changed about the JavaScript community. Development tools are no longer fledgling, but are, instead, mature. There are built-in development tools in all of Safari, Firefox, and Chrome browsers
I agree they're decent, but there are still cases where they struggle - particularly after code has been transpiled. I still run into issues these days where the browser is trying to show a source-mapped JS file instead of the actual bundle code which masks a real issue.
>And, for web frontends, it’s your only choice
https://caniuse.com/#search=webassembly
If you don't care about IE11 (or you polyfill), it's hardly your only choice. wasm is still far from perfect but there's no question you can start writing some logic in languages other than JavaScript, and interoperate.
>If you’re the kind of programmer who thinks, “I code in Python/Java/Ruby/C/whatever, and thus I have no use for JavaScript and don’t need to know anything about it”, you’re wrong, and I’ll describe why. Incidentally, you were right in 1998, you could get by without it in 2008, and you are dead wrong in 2018.
>To be a serious programmer, you’ll have to know JavaScript’s Modern and Good Parts — as well as some other server-side language, like Python, Ruby, Go, Elixir, Clojure, Java, and so on
This reads to me as downright patronising to e.g. embedded software engineers who might be writing hardware drivers in C/C++ day to day.
Perhaps this should read "to be a serious web developer with front-end responsibilities" (JavaScript is sufficient, not necessary on the back-end and - of course, subjectively - there are much better choices to use).
[+] [-] richardwhiuk|6 years ago|reply
It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
[+] [-] WilliamEdward|6 years ago|reply
[+] [-] EdwardDiego|6 years ago|reply
Considering how often Node projects break our build, I respectfully beg to differ.
[+] [-] ggregoire|6 years ago|reply
[+] [-] blondin|6 years ago|reply
i mean can we have a normal javascript that compiles to a x64 binary and calls the OS?
[+] [-] shusson|6 years ago|reply
[+] [-] draw_down|6 years ago|reply
[deleted]
[+] [-] misnome|6 years ago|reply
As a primarily Python/C++ developer who dabbled with JS in the early and late 2000s, can anyone recommend an efficient way to get started with modern JS development for hints like interactive frontends with a different-language. I’m comfortable with large language ecosystems, but there seems to be an intimidating number of incompatible paradigms - and there’s both the technology and toolings.
Easiest to start with one track e.g. react/tutorials and branch from there? Good books that approach the problem efficiently and for a decent existing programmer/scientist?
[+] [-] pixelmonkey|6 years ago|reply
1. Solid recorded talk (on YouTube) on using npm run-script to automate local builds: https://www.youtube.com/watch?v=0RYETb9YVrk
2. Modern JavaScript Explained for Dinosaurs: https://medium.com/the-node-js-collection/modern-javascript-... -- this is a long post that goes into technical depth on the stuff that I covered at a high level in my post
3. Webpack -- The Confusing Parts: https://medium.com/@rajaraodv/webpack-the-confusing-parts-58... -- long post that goes into depth on Webpack, in particular.
Aside from all of these, the book I have found the most helpful if you want to zoom straight ahead to React is "Road to React": https://leanpub.com/the-road-to-learn-react
It's 200 pages, oriented around real code, and straightforward.
[+] [-] pserwylo|6 years ago|reply
My recommendation to people learning specific frameworks such as react is to start with vanilla react (their doc's are quite good). Then, after building a small app that solves a problem for yourself, you'll start realising when you have bugs and other maintainability issues related to state management. At that point, it is worthwhile looking into redux (or another state management library). Otherwise if you go straight to react + redux it can just feel like a lot of boilerplate for no reason.
Same with TypeScript. I think type safety offers a huge reduction in the number of bugs in large systems. But it isn't required when first learning react.
[+] [-] kontorlaore|6 years ago|reply
I also highly recommend "Modern JavaScript Explained for Dinosaurs" for a high level overview of why the JS tooling is like it is.
This is also a good overview of the whole ecosystem, together with suggested learning paths:
https://frontendmasters.com/books/front-end-handbook/2019/
[+] [-] manigandham|6 years ago|reply
1. http://blazor.net
[+] [-] truth_seeker|6 years ago|reply
https://medium.com/@madasamy/javascript-brief-history-and-ec...
[+] [-] galaxyLogic|6 years ago|reply
Is that possible with the modern JavaScript tools?
[+] [-] fabian2k|6 years ago|reply
You also can't just compile any Javascript to WASM, the closest thing to this is AssemblyScript:
https://github.com/AssemblyScript/assemblyscript
This compiles a subset of Typescript to web assembly. And you have to take "subset" seriously here, web assembly is very limited in how memory is managed, you can't just drop your Javascript in there and get web assembly out.
[+] [-] IggleSniggle|6 years ago|reply
If you want your process to run on the server, and merely pass the result to the client, you can compile JavaScript to C, and then to a binary, with QuickJs. Most folks will just use Nodejs, however (which also uses V8)
[+] [-] marijn|6 years ago|reply
But it isn't a good idea. JS is a language that needs a runtime, the browser _has_ a JS engine, and not using that would just be counterproductive and wasteful.
[+] [-] shepherdjerred|6 years ago|reply
[+] [-] ben-schaaf|6 years ago|reply
[+] [-] obituary_latte|6 years ago|reply
Anyone know what he is talking about here? I searched google but couldn’t find what he was talking about.
[+] [-] pixelmonkey|6 years ago|reply
I was talking about Parse.ly's analytics engine, where most of the data we provide to our customers on first-party analytics around their audience stems from some lightweight JavaScript code they embed in their websites. It's now installed on thousands of high-traffic sites[1] and provides analytics on over a billion web/mobile browsers per month (as described in this Strata talk[2], for example).
I wrote a little bit about my experience writing that code in this HN comment: https://news.ycombinator.com/item?id=10206956#10207998
It was a fascinating piece of code to work on because not only did it have to be lightweight and fast across all browsers, but it also had to be tiny to embed, and it needed to be x-browser tested all the way back to IE6 and strange mobile browsers. Plus, at the time it was originally written (2010-2012), there were hardly any good JS build tools outside of early versions of uglifyjs.
Over the years, other engineers have improved the performance even further, while retaining the kernel of the code. We even did a change last year which improved client-side performance through a number of clever build/CDN tricks. We've also had to hold our ground firmly on privacy, which it turns out is one of the key areas third-party JavaScript started to take a turn in the wrong direction, especially in the adtech universe. (We are a content analytics company, with a similar SaaS business model to MixPanel for product analytics and NewRelic for performance analytics. So, for us, privacy is paramount.) I wrote about this here: https://blog.parse.ly/post/3394/analytics-privacy-without-co...
[1]: https://trends.builtwith.com/analytics/Parse.ly
[2]: https://conferences.oreilly.com/strata/strata-ny-2018/public...
[+] [-] randallsquared|6 years ago|reply
[+] [-] pixelmonkey|6 years ago|reply
[+] [-] Koshkin|6 years ago|reply
[+] [-] tus88|6 years ago|reply
[+] [-] Figs|6 years ago|reply
Maybe TypeScript will turn out to have more staying power, but my current guess is that something will happen that makes another technology -- probably WebAssembly -- very popular in the next few years and that will kill off a lot of the hype around TypeScript. Then that will itself mostly get killed off by some other technology about 3~5 years after it hits peak popularity, and so on...
I could be completely wrong though, of course! Predicting the future is hard. This is just my guess based on handwavey recollection of the last decade and a half of web trends.
[+] [-] pixelmonkey|6 years ago|reply
"Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important. It is better to be lucky than smart."
TypeScript is a very smart language, but then, so are Dart, CoffeeScript, ClojureScript. I suspect that if code durability is what matters to you, JS (and the ES evolutions thereof) will have the real staying power. Plus, not everyone is sold on the value of static types, but everyone is sold on the value of JavaScript.
[+] [-] IggleSniggle|6 years ago|reply
Edit: Mea culpa. I got my numbers mixed up, or whatever source I thought I remembered just doesn’t exist. 46% in 2018 (state of js) says nothing about 2019, and is not a majority. That 46% is also backed up by a similar survey that npm ran. It’s worth adding though, I think, that js devs benefit from ts type inferencing and IDE support even if they aren’t using it directly
[+] [-] blondin|6 years ago|reply
to use javascript -- or say python -- in an corporate/enterprise environment, you need to analyze your code base. static analysis is what worked well and still does but you need types. ofc having types has other major benefits but this is the big one for me at least.
[+] [-] phragg|6 years ago|reply
[deleted]
[+] [-] nullandvoid|6 years ago|reply
[+] [-] z3t4|6 years ago|reply
[+] [-] otabdeveloper2|6 years ago|reply
Gimme back my plain old browser Javascript. It was primitive, but at least it wasn't actively harmful.
[+] [-] debaserab2|6 years ago|reply
"Modern" javascript runs just fine in your plain old browser.