Second edition: ES2015

[addyosmani]

Over the last two years one of the biggest pieces of feedback we’ve had on the book is that everyone would like a version that is updated to use ES2015+. There are a few different approaches we could take to this work in but I would like to explore starting on this soon.

Conversion of existing patterns to ES2015

One option would be a direct conversion of all code snippets to use ES2015 syntax. This could in part be done with Lebab.io with manual tweaks. Its perhaps the easiest initial option for getting to the goal. We need to decide whether the book includes both ES5 and ES2015 snippets or just the latter.

One argument for including both is that beginners often reading this book have come from a course or level of experience that hasn't really touched on ES2015 syntax all that much - we could initially include both to cater for different audiences. Interested in any perspectives folks have on this.

Full re-evaluation of patterns for an ES2015, ES2016+ world

The next option is that we reevaluate all of the different patterns in this book and try to ascertain if they still make sense in an ES2015 world. Most should.. but some may very well not. We might also want to document ES Modules or class patterns now that they are in the language.

In my daily work, we often also run into lots of patterns where using language features like async/await can subtly have an impact on how code gets structured. I'm unsure just yet on how much we might do this for the book, but it's something I've got in the back of my mind right now.

This larger re-evaluation effort is something we could either do after the initial ES2015+ port or instead of it.

When

I may try to tackle some of this rewrite over the Christmas break this year. If anyone would be interested in contributing to this effort help is always very welcome. Even if you're unable to contribute, I'm keen to understand what folks would like out of an ES2015 version so we can plan out that work accordingly.

Thanks!

[destromas1]

Hey @addyosmani
I would like to contribute on a regular basis here , i am really curious/excited to do!
And I am the first person who commented on this thread 🥇

[forforeach]

Hi @addyosmani ,
I'm voting for the latter option. I think that direct conversation doesn't give much impact and everyone can make it by herself using some tools or even manually.
On the other hand during a re-evaluation you may change a patterns' implementation entirely, so that it will fit the tools you have now in a much better way.
Also I'd be happy to help with that.

[jserrao]

Your book is one of the best resources on the internet for learning JS deeply; I referred many of my students towards it but have shied away lately because it is out of date as you say.

For people learning, I think having ES5 / ES6+ side-by-side would be the best path for right now. That's how I teach it. In fact I actually show jQuery, ES5, ES6+ when I can - showing the arc of what people will see out in the real world.

[addyosmani]

Thanks for the input folks. Some ideas for next steps here. Evaluate: - What are patterns in the book that no longer hold true/useful in an ES2015+ world? We can add a note to this affect under each one qualifying. - What are ES2015+ patterns the book is missing? - What other considerations should we keep in mind? A lot has changed in the JS landscape over the last few years, including a shift to slightly more functional programming and state management. Figuring out where to draw the line in topics for this next edition would help I think.

…

On Dec 19, 2017 8:42 AM, "John Serrao" ***@***.***> wrote: Your book is one of the best resources on the internet for learning JS deeply; I referred many of my students towards it but have shied away lately because it is out of date as you say. For people learning, I think having ES5 / ES6+ side-by-side would be the best path for right now. That's how I teach it. In fact I actually show jQuery, ES5, ES6+ when I can - showing the arc of what people will see out in the real world. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#218 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGxaUhd90WTewY-q3rDx3lRfpryWvpLks5tB-dxgaJpZM4QjIGs> .

[jserrao]

I'll make some time to go back through the book tomorrow in-depth and make some constructive comments for you.

[jserrao]

I don't know if this type of feedback helps, but here is an example of what I did with your constructor JS stuff. Could be a model for how to do the ES5/ES6+ showcase.

/*
 * //////////////////////////////
 * //////// Constructor /////////
 * //////////////////////////////
 */

// Set up a constructor function of a `car`, works a lot like a class
// Creation of `car` object requires a model name passed into it
function car( make, model, color, year, miles ) {
  this.make = make;
  this.model = model;
  this.color = color;
  this.year = year;
  this.miles = miles;

  this.toString = function () {
    return "This " + this.color + " " + this.year + " " +
           this.make + " " + this.model + " has " +
           this.miles + " on it.";
  }
}

// Create list of cars to create
var civic = new car("Honda", "Accord", "silver", "2009", "75000");
var focus = new car("Ford", "Focus", "blue", "2013", "54000");

console.log(civic);
console.log(focus);

// ###############################
// ES6 constructor - using a class (new with ES6)
class Food {
  // Instead of making a function for the constructor, you make an actual constructor
  constructor (name, protein, carbs, fat) {
    this.name = name;
    this.protein = protein;
    this.carbs = carbs;
    this.fat = fat;
  }

  toString () {
    return `${this.name} | ${this.protein}g Protein :: ${this.carbs}g Carbs :: ${this.fat}g Fat`
  }

  print () {
    console.log( this.toString() );
  }
}

// Instead of making a new instance with a variable, use const instead
const chicken_breast = new Food('Chicken Breast', 26, 0, 3.5);

// Calling the constructor's .print method gives us all the data
chicken_breast.print(); // 'Chicken Breast | 26g Protein :: 0g Carbs :: 3.5g Fat'

// But you can also just call object properties with the standard dot notation
console.log(chicken_breast.protein); // 26 - output from the constructor

// ###############################
// ES6 subclass with constructor extends
// FatFreeFood is a derived class of Food
class FatFreeFood extends Food {

    constructor (name, protein, carbs) {
      // Call with reserved word `super` creates reference to Food class
      // Must call super before `this`
      super(name, protein, carbs, 0);
    }

    print () {
      super.print();
      console.log(`Would you look at that -- ${this.name} has no fat!`);
    }

}

const fat_free_yogurt = new FatFreeFood('Greek Yogurt', 16, 12);
fat_free_yogurt.print(); // 'Greek Yogurt | 26g Protein :: 16g Carbs :: 0g Fat  /  Would you look at that -- Greek Yogurt has no fat!'

[jserrao]

@addyosmani - some feedback after a review of the book

-I'm not really sure how much decorators would be used in a world where we have classes / subclasses now. They just seem outdated. I think ES6 classes might need a whole section to be explained. How they impact singletons is significant.

-This might get confusing, but it could be interesting to try to explain the new Array methods (like map, reduce, etc) as facades or iterators related to for/forEach. That's how I think of them in my head. A similar approach for promises & async / await might also be useful.

-Modular JS section needs the ES6 module info added, and probably some info on doing ES5 transpiling.

-The whole back part of the book where you take apart jQuery methods to explain the design patterns was extremely powerful the first time I read it. It's really what made the whole book click for me. But I'm old at this point and jQuery isn't as widely used as it was back then. It makes me think this whole section has to go at some point.

-Something more generic around plugin creation that adopts the idea of modular code structure would be welcome. That section feels old when I reread it now.

-I wonder if younger developers would benefit from a take down of React patterns like you did for jQuery, undressing their approach in design or maybe recommending how design patterns would relate to structuring a React app. It would kind of make sense as a transition out of the MV* stuff.

[forforeach]

@jserrao regarding decorators, there is a new decorator syntax proposal. It is stage 2, so I think it would be useful to show how to decorate classes and functions with it https://github.com/tc39/proposal-decorators

Another useful thing will be a reactive patterns. It may include examples of rxjs or something else.

Maybe also state management patterns (Flux, Redux etc.)

[addyosmani]

All of this detailed, insightful feedback is incredibly helpful. Thanks John! I agree with pretty much all of the points you raised. Transitioning from the jQuery patterns section to one based on React could certainly also be valuable if well scoped. Decorators: closest modern change in that direction is the ES Decorators proposal, however I would be skeptical of capturing patterns for something that isn't a standard too much just yet.

…

On Wed, Dec 20, 2017 at 8:14 AM John Serrao ***@***.***> wrote: @addyosmani <https://github.com/addyosmani> - some feedback after a review of the book -I'm not really sure how much decorators would be used in a world where we have classes / subclasses now. They just seem outdated. I think ES6 classes might need a whole section to be explained. How they impact singletons is significant. -This might get confusing, but it could be interesting to try to explain the new Array methods (like map, reduce, etc) as facades or iterators related to for/forEach. That's how I think of them in my head. A similar approach for promises & async / await might also be useful. -Modular JS section needs the ES6 module info added, and probably some info on doing ES5 transpiling. -The whole back part of the book where you take apart jQuery methods to explain the design patterns was extremely powerful the first time I read it. It's really what made the whole book click for me. But I'm old at this point and jQuery isn't as widely used as it was back then. It makes me think this whole section has to go at some point. -Something more generic around plugin creation that adopts the idea of modular code structure would be welcome. That section feels old when I reread it now. -I wonder if younger developers would benefit from a take down of React patterns like you did for jQuery, undressing their approach in design or maybe recommending how design patterns would relate to structuring a React app. It would kind of make sense as a transition out of the MV* stuff. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#218 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGxaUNOPMTmZshHEp4k0stjh1DmTeAyks5tCRZcgaJpZM4QjIGs> .

[addyosmani]

State management would be a strong addition. Rx worth considering on the reactive patterns bit.

…

On Wed, Dec 20, 2017 at 8:33 AM Addy Osmani ***@***.***> wrote: All of this detailed, insightful feedback is incredibly helpful. Thanks John! I agree with pretty much all of the points you raised. Transitioning from the jQuery patterns section to one based on React could certainly also be valuable if well scoped. Decorators: closest modern change in that direction is the ES Decorators proposal, however I would be skeptical of capturing patterns for something that isn't a standard too much just yet. On Wed, Dec 20, 2017 at 8:14 AM John Serrao ***@***.***> wrote: > @addyosmani <https://github.com/addyosmani> - some feedback after a > review of the book > > -I'm not really sure how much decorators would be used in a world where > we have classes / subclasses now. They just seem outdated. I think ES6 > classes might need a whole section to be explained. How they impact > singletons is significant. > > -This might get confusing, but it could be interesting to try to explain > the new Array methods (like map, reduce, etc) as facades or iterators > related to for/forEach. That's how I think of them in my head. A similar > approach for promises & async / await might also be useful. > > -Modular JS section needs the ES6 module info added, and probably some > info on doing ES5 transpiling. > > -The whole back part of the book where you take apart jQuery methods to > explain the design patterns was extremely powerful the first time I read > it. It's really what made the whole book click for me. But I'm old at this > point and jQuery isn't as widely used as it was back then. It makes me > think this whole section has to go at some point. > > -Something more generic around plugin creation that adopts the idea of > modular code structure would be welcome. That section feels old when I > reread it now. > > -I wonder if younger developers would benefit from a take down of React > patterns like you did for jQuery, undressing their approach in design or > maybe recommending how design patterns would relate to structuring a React > app. It would kind of make sense as a transition out of the MV* stuff. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#218 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAGxaUNOPMTmZshHEp4k0stjh1DmTeAyks5tCRZcgaJpZM4QjIGs> > . >

[destromas1]

@addyosmani
As on the current book , it has all the patterns ( such as Singleton,Command,Facade,Factory etc) implemented with ES5 function constructor as class and Prototype based stuff. It would be good to do all those with ES2015+ Class and OOP based.

Also there are few require AMD things to import. We can try using ES2015 import/export to show how that works

[destromas1]

Also for AJAX based section , there is jQuery API calls , we can try using fetch , as its natively available on most of the Browsers

[destromas1]

@addyosmani
As React/Preact Developers are trying to achieve Immutability on their applications, it might be a good thing to show how immutability can be achieved ?
Such as - immutable-js , Spread Operator , map , filter , reduce etc

[destromas1]

For big React/Preact apps,
HOC (Higher Order Component) pattern would be good to show how it could be implemented if you think to add some React/Preact flavours ?

[jserrao]

@addyosmani - React design patterns, could be the start of redoing that big jQuery section towards the back of the book: http://lucasmreis.github.io/blog/simple-react-patterns/

[addyosmani]

@jserrao With a number of developers starting to shift away from jQuery, I have been wondering whether it's worth showing off simple framework patterns. As @destromas1 noted, there are quite a few out there in the React ecosystem (like HOCs etc) that we could include.

The main thing I'm wondering is how evergreen / relevant those sections would be in 2-3 years. Definitely something to think about.

[addyosmani]

An update on..updating the book :)

@guar47 is taking a first-pass at extracting and porting over each of the patterns to ES2015. Part of this exercise will help identify where some patterns need a bigger overhaul (e.g anything to do with the module pattern switching over to ES Modules).

We're going to work on this as a single PR. If anyone is interested in helping out with reviews, feel free to drop comments into #220 as we work along. @forforeach @jserrao etal. your input is more than welcome.

At the end of this round, I think we'll have a better understanding of a few things:

1. What patterns are worth dropping or heavily rethinking
2. What patterns enabled by ES2015 aren't really covered at all.
3. Whether we should also capture React (or similar) patterns in place of the jQuery section in the book. I was a fan of https://levelup.gitconnected.com/react-component-patterns-ab1f09be2c82.

[destromas1]

@addyosmani
"On The main thing I'm wondering is how evergreen / relevant those sections would be in 2-3 years. Definitely something to think about.",
If ES2015+ is used all over, it would sustain for more than 2-3 years.So thats safe.
async/await would be lot more useful in coming years, so 👍 for that.