15 ms·

I wish there was a "learn modern Javascript for people who learned Javascript in 1998" - it seems like the only way to get up to speed is to slog through all th

I wish there was a "learn modern Javascript for people who learned Javascript in 1998" - it seems like the only way to get up to speed is to slog through all the basics (yet again) and keep an eye out for the parts that seem to be unfamiliar/new.

dentemple 8y ago
Search for guides that specifically call out ES6 and above.
ohitsdom 8y ago
I would read through AirBnB's JS style guide. Very well structured, and most rules have reasons specified in the guide. It should cover all the unfamiliar parts for you. After that, the next biggest thing is tooling so it'd be picking a framework and seeing how the development process has changed with npm & webpack. Start with Vue, Angular, or React and go through their hello world examples. Not that you need to be a "framework developer", but they are probably the best spots to see how the development process has changed. https://github.com/airbnb/javascript https://github.com/airbnb/javascript
jsty 8y ago
I was in the same position a while back, and found Eloquent JavaScript [0] to be a really good read. It's quite well structured, which makes diving into the bits that sound unfamiliar a lot easier. [0] https://eloquentjavascript.net/ https://eloquentjavascript.net/
- charliepark 8y ago
  (Wrote practically the same message at the same time, then deleted mine. Agreeing with the parent comment: Eloquent Javascript is really solid.)
- arethuza 8y ago
  I skimmed this (which looks good) and the Airbnb guide recommended (recommended in another comment) and I can't help noticing that one uses double quotes for strings and the other single quotes (Airbnb). Is there actually any sensible argument one way or the other - that isn't just being consistent with your team/project/platform...?
  - deleted 8y ago
    [deleted]
  - Klathmon 8y ago
    Like most lint rules, it's mostly preference. The important part is being consistent within your team/project like you said.
  - __oh_es 8y ago
    The reason I’ve used (and stuck to) single over double is it’s easier to embed JavaScript within html (html convention being double). It can get cluttered when with nested quotes, but most linters will allow you to use the other type to encapsulate. IMO it doesn’t matter, as long as the team agrees and remains consistent throughout the codebase.
    - arethuza 8y ago
      Thanks - that's a decent explanation for favouring one over the other. I rather dislike "best practices" that don't provide any explanation of what they are recommending.
      - jrockway 8y ago
        I mean, it's because it doesn't matter. Picking one is valuable for consistency (no odd diffs when refactoring). Which one you pick doesn't matter.
        chrisweekly 8y ago
        ... Unless you would prefer to skip the extra keypress required for ".
        ficklepickle 8y ago
        The behavior is slightly different. "\n" is a newline, '\n' is a backslash and an n.
deleted 8y ago
[deleted]
Swizec 8y ago
https://es6cheatsheet.com https://es6cheatsheet.com aims to do exactly that. Old code on the left, modern alternative on the right. I didn’t go quite as far back as 1998, but if you kinda know ES5 and older it’s just the right fit.
- chrisweekly 8y ago
  ... or use Babel, learn to write in es6+, and read the es5 output.
  - Swizec 8y ago
    Babel’s output is really really not meant for human consumption.
z3t4 8y ago
I still code JS like it's 1999 :P Most new updates are syntax sugar. ES5 added a ton of stuff that are useful, for example binary buffers which is useful for optimization. When people say "modern" JS though, they mean the syntax sugar from ES6 and ES7. I actually prefer the "old school" style. I hate how the language has become more complex, but I guess it's an evil necessary in order to please everyone. If you for example are into functional programming you will love arrow functions. If you never liked async or functional programming you will like async/await. If you like meta programming you can use new tools like Babel to come up with your own syntax sugar. The tooling and ecosystem for JS has really exploded. If you haven't already, take a look at Node.JS.
- kls 8y ago
  While I agree some of that sugar does a lot to clean up a lot of boilerplate code that we used to have to write, such as arrow functions retaining this in scope without having to do binds or "self = this" stuff we used to have to do. as well as adding let which allows you to properly scope variables. It is sugar and the language was perfectly usable without them but they sure do tidy up the code we write.
- commandlinefan 8y ago
  For me, it's not really so much the JS syntax - I agree it's mostly syntactic sugar and if I really want to use something like, say, "map", I can always do something like: Array.prototype.map = Array.prototype.map || function(f) { var a = []; for (var i = 0; i < this.length; i++) {a[i] = f(this[i]);} return a;} What I'm still trying to get my head around is this whole new ecosystem of bower, webpack, babel, eslint, npm, node, grunt, jQuery, angular, react, vue, yarn, parcel, browserify, gulp, etc... and apparently Javascript has modules now?
  - z3t4 8y ago
    Around year 2000 "AJAX" started to get popular which allows you to make HTTP requests from JavaScript (JS). "AJAX" makes it possible to have upload progress bars, or have "new messages" badges without reloading the page. "AJAX" made it possible to move back-end code into front-end JavaScript. To make the transition easier, front-end JavaScript frameworks was invented. AJAX was initially implemented differently between browsers, and jQuery became popular, as it added abstractions that work on all major browsers. In 2011 Websockets was made into a standard, which set the new direction on how you create web apps. Instead of having a back-end in Perl, PHP, CGI, etc, which renders the HTML on the server, the DOM is now rendered on the client, and the client communicate to the server via REST/HTTP or Websockets. This accelerated the growth of front-end frameworks as more and more started to port their back-end rendering to the front-end. In 2008 Google's Chrome browser was released which had a very fast JS engine called v8. And about that time a mathematician named Ryan thought that in order to have a performant web server, it need to be async ... While JS on the server was already a thing, it was not async. Ryan took the v8 JS engine from Chrome. and made a fully async library/API for IO on the server. He called it Node.JS. And it become popular. The "CommonJS" module system became the standard module system in Node.JS. NPM was created to host modules/packages. Webpack makes it possible to convert Node.js modules to run in the browser. Grunt was picked as the "make" system for Node.JS modules, and I think Gulp is a competitor to Grunt. Bower and Yarn sprung up as competitors to NPM. Then in 2015 the EcmaScript (ES) committee standardized JS modules, but incompatible with Node.JS module system, missing features such as lexical scoping, dynamic import and lazy loading available in the NodeJS module system. As a result Node.JS has still not implemented ES modules. But you can use Babel to transpile the code. Personally I try to avoid transpilation and front-end framworks, and only use vanilla JS. Node.JS is a really good back-end JS framework. There's a module for everything you need. And all of them are free and open source!
ivan_ah 8y ago
Here is a language diff that shows when new language features added to Firefox. This might be helpful to get an exhaustive list of the changes: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_2015_support_in_Mozilla https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_... In practice the only thing you absolutely need to know is the spread syntax for arrays `blist=[...alist]` and objects `objb={...obja}` that will trick you up if you're never seen in before alist = [1,2,3] blist = [...alist, 4] // == [ 1, 2, 3, 4 ] obj = { a: 5, b: 6 } obj2 = { ...obj, c:7 } // == { a: 5, b: 6, c: 7 } See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... There is also this weird shortcut for creating objects for which key and value use the same identifier: d=8 e=9 obj = { d, e } // shorthand for {d:d, e:e} // == { d: 8, e: 9 }
- arethuza 8y ago
  I wouldn't say that latter thing is a "weird shortcut" - C# has had that for a while and I rather like it. :-)
sephoric 8y ago
Got you fam. Just posted one.
iseeyoubydesign 8y ago
its not any different ... except for .forEach, .map , and .filter ... but we have had closures for 20 years. thing like modules and classes are basically syntactic sugar and are because not using javascript as a functional language is implementing away from the core features of the language. Of course thats an opinion but things like importing libraries can be handled by js compilers , its not frontend engineers have been struggling with maintaining 3000 line files. And another opinion of mine is that type systems are not worth the key strokes, they only solve the lowest hanging problems that any testing would catch.
RodericDay 8y ago
This is exactly what you're looking for: https://eev.ee/blog/2017/10/07/javascript-got-better-while-i-wasnt-looking/ https://eev.ee/blog/2017/10/07/javascript-got-better-while-i...
SonnyWortzik 8y ago
There is a yt video that I found very well done and explained very well. He goes very deep in the inner workings of javascript. I think you will like it. It is "modern" but not a new video. It is probably about 3 years old. Still relevant. He has a udemy course for $10 bucks. https://www.youtube.com/watch?v=Bv_5Zv5c-Ts https://www.youtube.com/watch?v=Bv_5Zv5c-Ts
TheAceOfHearts 8y ago
I suggest reading the ExploringJS books [0]. If you already know ES5 then you can jump to Exploring ES6 [1], then you can work your way through Exploring ES2016 and ES2017, and finally Exploring ES2018 and ES2019. Each book explains what new features that were added to the language as part of that specific version. Don't feel daunted though! ES6 added the largest amount of features, and after that there haven't been nearly as many changes. If you find the book useful please consider buying a copy; I'm not associated with the author in any way, just a big fan of his writings. [0] http://exploringjs.com/ http://exploringjs.com/ [1] http://exploringjs.com/es6/index.html http://exploringjs.com/es6/index.html
smacktoward 8y ago
As a fellow old-schooler who's been getting back into JS myself, I've come across a couple of these types of resources that I found particlarly helpful. Here's the links: - "Modern JavaScript Explained for Dinosaurs," by Peter Jang: https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70 https://medium.com/the-node-js-collection/modern-javascript-... - "Modern JavaScript for Ancient Web Developers," by Gina Trapani: https://postlight.com/trackchanges/modern-javascript-for-ancient-web-developers https://postlight.com/trackchanges/modern-javascript-for-anc... (Don't let the "ancient"/"dinosaur" stuff scare you off -- they kid because they love.) Hope this helps!
- commandlinefan 8y ago
  Thanks, that is a big help!
gmiller123456 8y ago
I'm sure a lot of people are in this same boat. It used to be that I was afraid to use any new JS features for many, many years due to the fact that so many people were using old browsers. Today, browsers update automatically, and the only outlier is the 5% of people still using Internet Explorer. So, recently I've changed my attitude to accept anything in ES8 (or at least async/await). The problem now is that different sources of info will still use older methods. E.g. Promises were used to augment/replace the use of callbacks in many situations. And now async/await is augmenting and replacing promises in a lot of places. So you'll still run into a lot of sources saying promises are the new and better way to do some things, when async/await is actually a better choice.
sephoric 8y ago
How about this? "Learn modern JavaScript, for people who learned JavaScript in 1998" https://sephware.com/blog/2019-01-03-learn-modern-javascript-for-people-who-learned-javascript-in-1998/ https://sephware.com/blog/2019-01-03-learn-modern-javascript...
- commandlinefan 8y ago
  LOL, well that's perfect, thank you.
a_w 8y ago
I find this MDN JS guide very helpful. Quickly scan the chapters/sections and pick ones you are not familiar with. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

dentemple 8y ago

Search for guides that specifically call out ES6 and above.

ohitsdom 8y ago

I would read through AirBnB's JS style guide. Very well structured, and most rules have reasons specified in the guide. It should cover all the unfamiliar parts for you. After that, the next biggest thing is tooling so it'd be picking a framework and seeing how the development process has changed with npm & webpack. Start with Vue, Angular, or React and go through their hello world examples. Not that you need to be a "framework developer", but they are probably the best spots to see how the development process has changed. https://github.com/airbnb/javascript https://github.com/airbnb/javascript

jsty 8y ago

I was in the same position a while back, and found Eloquent JavaScript [0] to be a really good read. It's quite well structured, which makes diving into the bits that sound unfamiliar a lot easier. [0] https://eloquentjavascript.net/ https://eloquentjavascript.net/

charliepark 8y ago
(Wrote practically the same message at the same time, then deleted mine. Agreeing with the parent comment: Eloquent Javascript is really solid.)
arethuza 8y ago
I skimmed this (which looks good) and the Airbnb guide recommended (recommended in another comment) and I can't help noticing that one uses double quotes for strings and the other single quotes (Airbnb). Is there actually any sensible argument one way or the other - that isn't just being consistent with your team/project/platform...?
- deleted 8y ago
  [deleted]
- Klathmon 8y ago
  Like most lint rules, it's mostly preference. The important part is being consistent within your team/project like you said.
- __oh_es 8y ago
  The reason I’ve used (and stuck to) single over double is it’s easier to embed JavaScript within html (html convention being double). It can get cluttered when with nested quotes, but most linters will allow you to use the other type to encapsulate. IMO it doesn’t matter, as long as the team agrees and remains consistent throughout the codebase.
  - arethuza 8y ago
    Thanks - that's a decent explanation for favouring one over the other. I rather dislike "best practices" that don't provide any explanation of what they are recommending.
    - jrockway 8y ago
      I mean, it's because it doesn't matter. Picking one is valuable for consistency (no odd diffs when refactoring). Which one you pick doesn't matter.
      - chrisweekly 8y ago
        ... Unless you would prefer to skip the extra keypress required for ".
      - ficklepickle 8y ago
        The behavior is slightly different. "\n" is a newline, '\n' is a backslash and an n.

deleted 8y ago

[deleted]

Swizec 8y ago

https://es6cheatsheet.com https://es6cheatsheet.com aims to do exactly that. Old code on the left, modern alternative on the right. I didn’t go quite as far back as 1998, but if you kinda know ES5 and older it’s just the right fit.

chrisweekly 8y ago
... or use Babel, learn to write in es6+, and read the es5 output.
- Swizec 8y ago
  Babel’s output is really really not meant for human consumption.

z3t4 8y ago

I still code JS like it's 1999 :P Most new updates are syntax sugar. ES5 added a ton of stuff that are useful, for example binary buffers which is useful for optimization. When people say "modern" JS though, they mean the syntax sugar from ES6 and ES7. I actually prefer the "old school" style. I hate how the language has become more complex, but I guess it's an evil necessary in order to please everyone. If you for example are into functional programming you will love arrow functions. If you never liked async or functional programming you will like async/await. If you like meta programming you can use new tools like Babel to come up with your own syntax sugar. The tooling and ecosystem for JS has really exploded. If you haven't already, take a look at Node.JS.

kls 8y ago
While I agree some of that sugar does a lot to clean up a lot of boilerplate code that we used to have to write, such as arrow functions retaining this in scope without having to do binds or "self = this" stuff we used to have to do. as well as adding let which allows you to properly scope variables. It is sugar and the language was perfectly usable without them but they sure do tidy up the code we write.
commandlinefan 8y ago
For me, it's not really so much the JS syntax - I agree it's mostly syntactic sugar and if I really want to use something like, say, "map", I can always do something like: Array.prototype.map = Array.prototype.map || function(f) { var a = []; for (var i = 0; i < this.length; i++) {a[i] = f(this[i]);} return a;} What I'm still trying to get my head around is this whole new ecosystem of bower, webpack, babel, eslint, npm, node, grunt, jQuery, angular, react, vue, yarn, parcel, browserify, gulp, etc... and apparently Javascript has modules now?
- z3t4 8y ago
  Around year 2000 "AJAX" started to get popular which allows you to make HTTP requests from JavaScript (JS). "AJAX" makes it possible to have upload progress bars, or have "new messages" badges without reloading the page. "AJAX" made it possible to move back-end code into front-end JavaScript. To make the transition easier, front-end JavaScript frameworks was invented. AJAX was initially implemented differently between browsers, and jQuery became popular, as it added abstractions that work on all major browsers. In 2011 Websockets was made into a standard, which set the new direction on how you create web apps. Instead of having a back-end in Perl, PHP, CGI, etc, which renders the HTML on the server, the DOM is now rendered on the client, and the client communicate to the server via REST/HTTP or Websockets. This accelerated the growth of front-end frameworks as more and more started to port their back-end rendering to the front-end. In 2008 Google's Chrome browser was released which had a very fast JS engine called v8. And about that time a mathematician named Ryan thought that in order to have a performant web server, it need to be async ... While JS on the server was already a thing, it was not async. Ryan took the v8 JS engine from Chrome. and made a fully async library/API for IO on the server. He called it Node.JS. And it become popular. The "CommonJS" module system became the standard module system in Node.JS. NPM was created to host modules/packages. Webpack makes it possible to convert Node.js modules to run in the browser. Grunt was picked as the "make" system for Node.JS modules, and I think Gulp is a competitor to Grunt. Bower and Yarn sprung up as competitors to NPM. Then in 2015 the EcmaScript (ES) committee standardized JS modules, but incompatible with Node.JS module system, missing features such as lexical scoping, dynamic import and lazy loading available in the NodeJS module system. As a result Node.JS has still not implemented ES modules. But you can use Babel to transpile the code. Personally I try to avoid transpilation and front-end framworks, and only use vanilla JS. Node.JS is a really good back-end JS framework. There's a module for everything you need. And all of them are free and open source!

ivan_ah 8y ago

Here is a language diff that shows when new language features added to Firefox. This might be helpful to get an exhaustive list of the changes: https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_2015_support_in_Mozilla https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_... In practice the only thing you absolutely need to know is the spread syntax for arrays `blist=[...alist]` and objects `objb={...obja}` that will trick you up if you're never seen in before alist = [1,2,3] blist = [...alist, 4] // == [ 1, 2, 3, 4 ] obj = { a: 5, b: 6 } obj2 = { ...obj, c:7 } // == { a: 5, b: 6, c: 7 } See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... There is also this weird shortcut for creating objects for which key and value use the same identifier: d=8 e=9 obj = { d, e } // shorthand for {d:d, e:e} // == { d: 8, e: 9 }

arethuza 8y ago
I wouldn't say that latter thing is a "weird shortcut" - C# has had that for a while and I rather like it. :-)

sephoric 8y ago

Got you fam. Just posted one.

iseeyoubydesign 8y ago

its not any different ... except for .forEach, .map , and .filter ... but we have had closures for 20 years. thing like modules and classes are basically syntactic sugar and are because not using javascript as a functional language is implementing away from the core features of the language. Of course thats an opinion but things like importing libraries can be handled by js compilers , its not frontend engineers have been struggling with maintaining 3000 line files. And another opinion of mine is that type systems are not worth the key strokes, they only solve the lowest hanging problems that any testing would catch.

RodericDay 8y ago

This is exactly what you're looking for: https://eev.ee/blog/2017/10/07/javascript-got-better-while-i-wasnt-looking/ https://eev.ee/blog/2017/10/07/javascript-got-better-while-i...

SonnyWortzik 8y ago

There is a yt video that I found very well done and explained very well. He goes very deep in the inner workings of javascript. I think you will like it. It is "modern" but not a new video. It is probably about 3 years old. Still relevant. He has a udemy course for $10 bucks. https://www.youtube.com/watch?v=Bv_5Zv5c-Ts https://www.youtube.com/watch?v=Bv_5Zv5c-Ts

TheAceOfHearts 8y ago

I suggest reading the ExploringJS books [0]. If you already know ES5 then you can jump to Exploring ES6 [1], then you can work your way through Exploring ES2016 and ES2017, and finally Exploring ES2018 and ES2019. Each book explains what new features that were added to the language as part of that specific version. Don't feel daunted though! ES6 added the largest amount of features, and after that there haven't been nearly as many changes. If you find the book useful please consider buying a copy; I'm not associated with the author in any way, just a big fan of his writings. [0] http://exploringjs.com/ http://exploringjs.com/ [1] http://exploringjs.com/es6/index.html http://exploringjs.com/es6/index.html

smacktoward 8y ago

As a fellow old-schooler who's been getting back into JS myself, I've come across a couple of these types of resources that I found particlarly helpful. Here's the links: - "Modern JavaScript Explained for Dinosaurs," by Peter Jang: https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70 https://medium.com/the-node-js-collection/modern-javascript-... - "Modern JavaScript for Ancient Web Developers," by Gina Trapani: https://postlight.com/trackchanges/modern-javascript-for-ancient-web-developers https://postlight.com/trackchanges/modern-javascript-for-anc... (Don't let the "ancient"/"dinosaur" stuff scare you off -- they kid because they love.) Hope this helps!

commandlinefan 8y ago
Thanks, that is a big help!

gmiller123456 8y ago

I'm sure a lot of people are in this same boat. It used to be that I was afraid to use any new JS features for many, many years due to the fact that so many people were using old browsers. Today, browsers update automatically, and the only outlier is the 5% of people still using Internet Explorer. So, recently I've changed my attitude to accept anything in ES8 (or at least async/await). The problem now is that different sources of info will still use older methods. E.g. Promises were used to augment/replace the use of callbacks in many situations. And now async/await is augmenting and replacing promises in a lot of places. So you'll still run into a lot of sources saying promises are the new and better way to do some things, when async/await is actually a better choice.

sephoric 8y ago

How about this? "Learn modern JavaScript, for people who learned JavaScript in 1998" https://sephware.com/blog/2019-01-03-learn-modern-javascript-for-people-who-learned-javascript-in-1998/ https://sephware.com/blog/2019-01-03-learn-modern-javascript...

commandlinefan 8y ago
LOL, well that's perfect, thank you.

a_w 8y ago

I find this MDN JS guide very helpful. Quickly scan the chapters/sections and pick ones you are not familiar with. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...