Using ES6

[gyzerok]

What you think about rewriting all the code examples in the book in ES6? It feels more functional than ES5.

[gyzerok]

I can do it if you want.

[sdwolfz]

Better than rewriting why not provide the ES6 alternative alongside the ES5. I would be 👍 for that.

[hemanth]

👍 Re-write, there are few references at 1-liners

[jirutka]

+1

[DrBoolean]

I would rather not put the two together. My preference would be a "second edition" fork for es6. That way people are not forced to use babel or bombarded with examples.

[jonbnewman]

+1 for the second edition per @DrBoolean or alternative along side it per @SDWolf ...a lot of people have yet to learn the new ES6 syntax and features.

I think it is better not to necessarily require them to be super up to date on their language knowledge (as well as build process - babel/etc).

[gyzerok]

@DrBoolean Is there any reason to support version for out of date standard? I think only lazy didnt use babel. This book is not for lazy people :)
But if you anyway want to keep 2 additions let me say ES6 should be primary target and ES5 addition only for backward compatibility.

[sdwolfz]

@gyzerok How about front end javascript (browsers). It's gonna take a while for them to be ES6 compliant.
While it would not be hard for me to translate to ES5 for my own code when I need to, I don't think this is applicable for everybody.

[gyzerok]

@SDWolf A lot of software are still written with .NET 2.0. Does it mean we need to write new books for it? Out of date langs are used all over the place, not only in web world (javascript).

[sdwolfz]

@gyzerok just don't rush to take ES5 out. Having a reference to the "old way of doing things" can be useful in learning.

[Silverwolf90]

Just to add to this a bit... using import I think you can reduce the boilerplate of adding _. to everything. I do this with lodash-fp as I find _. everywhere to add a lot of noise.

But since this is a book, perhaps that might just add additional complexity to understand the examples. And maybe doesn't allow one to differentiate between library and non-library functions as easily.

Totally a style thing, so feel free to ignore.

import { compose, prop, map} from 'ramda';
...
let mediaUrl = compose(prop('m'), prop('media'));
let srcs = compose(map(mediaUrl), prop('items'));
let images = compose(map(img), srcs);
let renderImages = compose(Impure.setHtml("body"), images);
let app = compose(Impure.getJSON(renderImages), url);
app("cats");

[dusky3]

+1 for the ES6 alternative alongside the ES5 one

[slikts]

Using ES5 gives a slightly dated feel, and ES6 features like arrow functions aid readability and fit great with a functional style. Compare:

var safeProp = _.curry((x, o) => Maybe.of(o[x]));

var safeProp = _.curry(function (x, o) { return Maybe.of(o[x]); });

Or even with destructuring (this may be overkill, though):

var makes = cars.map(({make}) => make);

[calvinlfer]

+1 for second edition ES6 fork, I wouldn't mind helping

[mikegehard]

@DrBoolean Thanks for taking the time to write this book!

+1 for the 2nd edition fork. I would also be interested in helping translate the examples.

Has anyone started anything like this? If so, please post a link here so I can contribute.

Thanks!

[r-k-b]

I have created an es6 / es2015 fork: https://github.com/r-k-b/mostly-adequate-guide/tree/es2015

[KtorZ]

@r-k-b @christiantakle
You may want to talk to each other ^.^