Is anyone else finding the ES6 stuff somewhat challenging??
Ive been coding in various langs on and off since 1979, so not exactly a novice, but to me the ES6 stuff is a real struggle. Its starting to feel a little like PERL - almost a set of random chars you just have to learn what they do.
Somehow the explanations in the ES6 module don’t seem as detailed as the other JS sections??
Anyone point me at a good resource to support the section?
You’re definetely not the first to have found ES6 to be a bit of a jump from the other Javascript challenges. However, once you get your head around a few new concepts it really does become intuitive from there.
I’d recommend this article here from FCC, it provides a good summary of most of the new concepts in ES6. Let us know if you’re having any more issues.
And at the risk of diverging the thread somewhat - having had a look through all of the JS section, I’m not seeing much that relates to the DOM?? Unless I’m missing something somewhere this seems puzzling, as the later frameworks stuff is surely going to rely on that?
@cjrw42 I’ve recently finished Front End Development Libraries and can confirm up to this point there isn’t a section on DOM specifically, and I find that somewhat strange, too.
Some of the challenges do touch on DOM stuff slightly but they kind of explained it on-the-go.
And just to add my two cents to your original question, I find MDN web docs to be a good reference for the ES6 stuff in that they explain them in great detail including pointing out the trickier stuff (e.g. let & const have block scope, arrow functions don’t have their this binding etc.) upfront, and that they also provide links to even more detailed readings e.g. follow this link and look for “Exploring ES6”.
Re DOM - manual DOM manipulation seems to be falling out of style, from what I hear.
Re ES6 - let and const are much better than var. The functional style took me a while to get used to, but I find it much more readable and expressive now that I understand it.
@gaac510 Yes, the MDN stuff looks very useful - Thanks
@JeremyLT Interesting… I would have thought an understanding of how the DOM works would make many of the later concepts easier to understand, but I guess I’m out of touch.
As far as ES6 being easier to read, yes I’m sure that with familiarity it will make more sense. I think that because of my coding background, I’m used to more “longhand” structures that are easily recognised syntactically across all of the major langs, and this more “shorthand” style takes a lot of that away.
My primary language in professional work is C - I am very used to writing everything ‘longhand’. Between newer JavaScript and Rust though, I’ve become a really big fan of the functional style. At least in Rust, there are performance benefits to using the functional style.
Everything seems strange and unintuitive the first time you see it. Especially if you’ve already learned a different way - primacy bias. When I was learning ES6, I kept wondering: If var works just fine, why change it?We already have a way to make functions, why do we need a new one? But that’s just because: 1. I was used to the old way. 2. I didn’t yet understand the subtle differences.
I think you just need to get used to it. You have to trust that there is a reason that they went to all the trouble to create these new ideas.
As far as resources, I would say that one of the great things about learning ES6 is that it is mostly a bunch of independent ideas. In other words, you can learn it one small section at a time - the different parts don’t depend on each other. When I was learning, I would just throw on some youtube videos before I went to sleep.
And I too started out in C. OK, technically Pascal before that. Like anything, you just need to get used to it.
Yeah, the “look” of Python gets on my nerves. But again, it’s just familiarity. When I went from Basic to Pascal, it was weird at first. When I went from Pascal to C, it was weird at first. When I had classes in ForTran, COBOL, and Assembly, they were all weird. When I got to JavaScript, that was really weird. And whatever language I learn next, I’m sure it will be weird at first.
The one that gets me the most is JSON, I hate the required quotes around property names and I hate that you can’t have trailing commas. Ugh.
But again, it’s just a matter of getting used to it.
Yes, I (and many others) have felt the same way. But now, I really, really like arrow functions and they are my default. You also have some destructuring there, and that can save you a lot of typing. It looks weird at first, even incomprehensible. But if you take a class in German, you are going to run into the same problem.
when considering this particular code snippet, consider also object destructuring const {min, max}= stats . The last line of code will create two variable named min and max, which will inherit the values of stats.min and stats.max respectively(they grab the values of the identically named keys in the stats object. const half = ({ max, min }) => (max + min) / 2.0 is creating a function named half. In its arguments area, we create two variables, min and max, which would inherit the values of the object passed as an argument of the function. So when you call the function like this half(stats), it creates its local variable min and max which inherit the values of the respective keys in the stats object, similarly to how i demonstrated object destructuring in my first example. The function would call correctly with any object which has properties(keys) named min and max. Hope that explanation can make the syntax slightly more intuitive!
To give some input on my experience with the ES6 module, it definitely comes a bit early, before you had chance to better familiarize with regular js functions and objects/arrays use. Im already few modules ahead and i still find myself occasionally returning to the ES6 section to refresh my memory on techniques explained there, and id look on the net for further examples whenever needed. Most recently i had to work with the export/import methods, as i had almost no practical use of them up until now. Object destructuring was also something i was barely familiar with, but the more i dived in back-end challenges, the more i was motivated of using it. Considering this, dont pressure yourself if you cant graps the concepts in ES6 yet, try to learn as much as you can but consider it a work in progress. Make up marks on stuff you couldnt comprehend and whenever you encounter them in current challenges, go back to revise. This comes occasionally true with other modules too
Having worked on projects in the past with dozens of developers its not out of the question that another member of the dev team will create an object with the same object keys - especially for common types of keynames like age or id etc
actually, if we must be precise, the object is referenced in the start of the code, where stats is declared. You mean, the function have never been called, which makes the code make less sense to novice programmer. You must recall that functions are reusable code. The function itself will only produce effect when it is called. There is no conflict with two objects with identical keys, the instance where you call the function only operates with the object you call as argument and the function itself doesnt modify the object, it only returns a result based on the input