Kyle Simpson

Observables are about getting and processing a "stream" of multiple values for a single subscription/request. This is different from having multiple promises, which are more conceptually multiple *independent* request/response type transactions. Broadly speaking, the observables hype seems to suggest that you can just have a single message observable and it serves the same purpose as a promise. That's not really true in all senses, but it's close enough to sound convincing as a hype statement.

But a single message observable is a much bigger hammer for the purpose of a single transaction's value. A promise is more direct for that specific purpose. It's kinda like comparing using a sledgehammer and a ball-pin hammer. They both are roughly used to drive thin pieces of metal into wood... but a sledgehammer is better for big spike nails and a ball-pin hammer is better for tiny picture hanging nails. Can you do each of those jobs with the other respective tools? Sure. But it's not a good idea.

O'Reilly currently has a bundle with big discounts (60%!) including all six (e)books of my YDKJS series, as well as several of my training videos from Frontend Masters:

http://shop.oreilly.com/category/get/frontend-masters-bundles.do

The whole bundle is available for $116.40! That's a great deal for all that content. Biggest discounts O'Reilly has offered yet on my content. Don't miss it!

Yes, there are those who have made that claim. I respectfully think it's because they're missing the most important part of a promise -- that it's a time-independent immutable value wrapper. Observables are great, but they're not the hammer I hit every nail with.

I just wrote a blog post that sorta comes at this from that different perspective: Thoughts On Thunks (http://blog.getify.com/thoughts-on-thunks/)

In this code:

var re1 = "\\d{16}";

The first backslash is an escaping of the second one backslash, to keep it present, because JS string literals are processed for escape characters. So the contents of the string will actually be a \, then a d, as separate characters.

Once that string is processed as a regexp, the \d is a character that tells regex to match a single number character. The {16} says repeat it 16 times.

Yeah, JS is not actually a FP language. But I do think you can *think functionally* in parts of your program, which helps improve things, even if you don't have an entirely pure FP approach to all the code.

I taught a 3hr Frontend Masters course called "Functional-Lite Programming" which tries to sift through the bits of FP theory/concept that we can easily apply to JS without getting into all the terminology and dogma. I encourage devs to explore this more fully, as I've found that it really helps to be 50% FP than 0% -- 100% is not necessary to improve code.

https://frontendmasters.com/courses/functional-js-lite/

My take is that ES6 `class` is the worst feature ever added to JavaScript. And this is not because I'm anti-class. It's because I'm anti- features that aren't coherent in terms of explainable behavior. The `class` keyword attempts to patch up and pave over a number of weirdnesses about the "prototypal inheritance" pattern and syntax from ES5 and before. While it does a decent job of painting over these flaws, it does so at extreme cost to mental models and coherency.

ES6 `class` is a feature you can use extremely well as long as you don't actually care about how it works. If you're into just accepting things on the surface and not going deeper, you'll be fine. That's the opposite of my take on JS and the appropriate ways to teach it. I won't teach something with just "take my word for it" or "don't worry about how it works". Just not my style.

And btw, no, ES6 `class` is most definitely not "just" sugar for prototypes. Don't believe that hype. There are a number of under the cover differences. I won't go into painful detail about them now, though. Also, the stuff being planned to add to `class` in ES2017 and beyond are going to even further diverge it from what we knew before, with all manner of cool looking features on the surface that under the covers are quite incoherent.

That's necessary to keep patching up the fundamental distinction that a live-link prototypal system doesn't actually behave the same way as a static copy inheritance system. They're fundamentally opposite, and in a sense, most of the history of JS has been wrapped up in trying to cover up these differences.

By contrast, the prototype system itself, without the `new` keyword, `instanceof`, constructor functions, and such... that system is actually really beautiful and powerful. I advocate a style of prototypal object-only coding that I call OLOO (objects-linked-to-other-objects). It embraces just creating concrete objects and linking them together for **delegation** -- a whole design pattern in itself -- and staying away from all that pseudo-kinda-but-not-really class stuff.

I've written in detail about these thoughts in Chapters 4-6 and Ap A of "this & Object Prototypes" of my YDKJS book series: https://github.com/getify/You-Dont-Know-JS/blob/master/this%20&%20object%20prototypes/README.md#you-dont-know-js-this--object-prototypes

Say you define an operation like:

function sum(x,y) { return x + y; }

Easy to use when you have two numbers, right? But what if you want to have a bunch of numbers that you add a single number to? You could:

var numbers = [3, 17, -4, 91, 11, 8, 0]; for (var i = 0; i < numbers.length; i++) { numbers[i] = sum( numbers[i], 42 ); } console.log(numbers); // [45, 59, 38, 133, 53, 50, 42]

But that's ugly and awfully imperative. Instead, we can use a built in method on arrays called `map(..)`:

var numbers = [3, 17, -4, 91, 11, 8, 0]; numbers = numbers.map(function(x){ return sum(x,42); }); console.log(numbers); // [45, 59, 38, 133, 53, 50, 42]

Cool!

But we can do better than that. Let's pull out that function expression:

function add42(x) { return sum(x,42); } numbers = numbers.map( add42 );

Notice how I only pass a reference to `add42`, but I don't call it like `add42()`. That's super important. `map(..)` will call `add42(..)` for us.

But, instead of defining that function manually, we could use another FP technique, closure, to make a utility that produces a composition on top of `sum(..)`:

function makeAdder(y) { return function(x) { return sum(x,y); }; } var add42 = makeAdder(42); numbers = numbers.map(add42);

The `makeAdder(..)` function makes and returns a new function. The new function that's returned is what we assign to the variable `add42`. That function has a closure over the variable `y`, which we pass in as `42`. It's then called by `map(..)` once for each value in the list, which will be the `x` parameter. Now that we have an `x` and a `y`, the `sum(x,y)` call computes the new value for each item in the list.

For our last trick, let's say we wanted to first add that `42` to all numbers in our list, and then sum all the numbers to get one big number. We can use another array method `reduce(..)` for that. `reduce(..)` takes a function similar to `map(..)`, but *that* function needs two values. The first parameter is the running total, and the second parameter is the current value in the list. In other words, it might be used like this:

var v = numbers.reduce(function(total,val){ return total + val; },0);

Also, look at that `0` as the second argument to `reduce(..)`. That's the initial value to start the reduction with. But does that function signature look familiar? It's exactly the same as the `sum(..)` we already defined. So we could just call `reduce( sum, 0 )`. Next, we'll observe that since `map(..)` is returning a new array, we can *chain* the `reduce(..)` call directly off the `map(..)` call. Putting all this together, we have:

function sum(x,y) { return x + y; } function makeAdder(y) { return function(x) { return sum(x,y); }; } var numbers = [3, 17, -4, 91, 11, 8, 0]; var add42 = makeAdder(42); var total = numbers.map(add42).reduce(sum,0); console.log(total); // 420

Processing values in lists is a lot more fun when we learn tools like `map(..)` and `reduce(..)`, and function closure. Happy coding!

My favorite features of ES6 are:

* destructuring (https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20&%20beyond/ch2.md#destructuring)
* `...` spread/gather/rest operator (https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20&%20beyond/ch2.md#spreadrest)
* interpolated string literals, aka "template literals" (https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20&%20beyond/ch2.md#template-literals)
* generators + promises, for sync-looking async (https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20&%20beyond/ch3.md#generators and https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20&%20beyond/ch4.md#generators--promises)

The proper way to think of ES6 features is that they're not new things you couldn't do before, but better (more readable, understandable) ways of doing old things. The more understandable your code is, the longer life it will have as new developers come to your code (or you, later) and can understand it and fix it instead of not understanding and just replacing.

Avoid setting event handlers in this way:

onsubmit = "checklength()"

Instead of specifying inline in your markup, the proper way to do this is to setup an event handler using JS, like this:

<form id="someFormID"> .. </form>

var myform = document.getElementById("someFormID"); myform.addEventListener("submit",checkLength,false); // .. function checkLength(evt) { evt.preventDefault(); // this prevents the default form submission behavior // do your validation logic here // if validation passes? evt.target.submit();

Whenever possible, try to keep your markup clean of JS and your JS clean of HTML. Will help with code maintainability.

> CoffeeScript

Nope, definitely dead. It had its impact though, and the best parts made it into ES6. Time to move on from coffee though.

> TypeScript

Yep, still very relevant. I don't recommend it as your general programming language, but I do recommend it if you're interoperating with a more strongly typed language in the back-end. It's great in the microsoft stack, for example.

> So, right now, what's important and what's a passing fad?

Everything other than JS the language itself is probably in some sense or another, a passing fad. Some last longer than others (jQuery) and others are here and gone before you know it. I recommend investing first, heavily, in your deeper understanding of the core language. That is learning that pays off year after year and won't any time soon be "passing".

When picking a library, look for all the usual signs, like good community support, proper documentation, etc. But also, look for a library that constrains itself to a limited scope of behavior. Tools that claim to be "everything you need" usually aren't. Look for libraries that do one set of things really well.

For frameworks, look for real modularity. That means more than just "stuff in separate files". It means real attention has been given to keep pieces loosely coupled and easy to remove. That kind of thing won't seem to matter much in the early going, but it pays off exponentially more as your project moves into maturity and maintenance.

Lastly, I'd say, if you have a tool or framework but you're not completely happy with it, don't necessarily be looking around to jump to something else. Whatever tool you use is going to have flaws. React is not better-enough than Angular to mean you should switch. It just isn't. They both have pluses and minuses. You're far better served by learning the thing you're using -- and the language it's built in! -- better, and learning better patterns of use of that thing. Investing not in re-learning and moving to a whole new thing, but instead in trying to make your current code more understandable and cleaner, will mean that it's less likely that your code will eventually have to be re-written a few years from now when a new group of devs can't figure out your code and they just throw it away.

Ever written code like this before?

var name = "Kyle", book = "YDKJS"; var msg = "Hello, I'm " + name + ", author of " + book + ". Welcome!";

All that manual string concatenation to interpolate `name` and `book` values into the string. Yuck.

ES6 adds a new kind of string literal, often called the "Template Literal" (bad name, but anyway...). It works like this:

var name = "Kyle", book = "YDKJS"; var msg = `Hello, I'm ${name}, author of ${book}. Welcome!`;

What's different? Notice the backticks around the string instead of single or double quotes. Also, notice that we list the interpolation expressions with `${ .. }` wrapped around them. These expressions can be anything really, not just variables. They could be even function calls or whatever you need.

These new kinds of strings can also span multiple lines, like this:

var msg = `This is a long enough string that I would like to break it onto another line.`;

Bam, that's cool, huh!? Careful, though... the breaking onto the new line actually does insert a newline character into the string value, which is different from normal strings where you break to multiple lines by escaping the line ending with a \ character -- in those cases, the newline is escaped so NOT included in the string value.

To learn more about these new string literals, check out Ch2 "Template Literals" in my "ES6 & Beyond" book, here:

https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20&%20beyond/ch2.md#template-literals

Hi everyone! Thanks for stopping by the forum during the promotion for my six book series, "You Don't Know JS". To get a better idea of the series, you can find all six books online here:

http://YouDontKnowJS.com

The six books are:

* Up & Going: beginner/intro
* Scope & Closures
* this & Object Prototypes
* Types & Grammar
* Async & Performance
* ES6 & Beyond

The title "You Don't Know JS" isn't intended to be an insult. It's intended to be a challenge for all of us to take seriously the process -- ongoing, it never ends -- of learning JS more deeply. You never fully know JS, you just learn it better and better. I try to help developers move beyond surface "I can get stuff done" to deeper, more confident "I know why this code works" type of understanding.

I truly believe that if you don't know why a piece of code works, you have no hope of understanding why it broke.

Some of you may have read and enjoyed "JavaScript: The Good Parts". This book series stands in opposition to that book in that I encourage and challenge you to learn ALL of JavaScript, not just a small slice that I have deemed OK for you to use. Knowing and appropriately using all of JS is how you move to the next level as a JS dev.

If there's anything I can do to help you learn JS better, please let me know!

I'd say among the most commonly misunderstood features of JS definitely are things like the `this` keyword. Probably more than 90% of developers that I encounter don't know how it really works, only parts of it. The rest they treat as a black box of magic and unpredictability. It's actually quite simple. There's just 4 rules, and they're based entirely on how the function is called.

1. Is the `new` keyword used in front of the function call (like `new foo()`)? If so, a new empty object will be assigned to `this` inside that function call.
2. Is a `call(..)` or `apply(..)` used at the call site (like `foo.apply( someObj )`)? If so, that `someObj` will be the `this` inside that function call.
3. Is a context object used at the call site (like `obj.foo()`)? If so, that `obj` will be the `this` inside that function call.
4. Otherwise, default the `this` to the global object (in non-strict mode) or `null` (in strict-mode).

See? It's really not that hard. But most just never learn it. So `this` is mysterious for devs even seasoned by 10 or more years of development.

If you're interested in more info on `this`, check out Ch 1 and 2 of "this & Object Prototypes" of the YDKJS series.

----------

How the `==` actually works (and compared to `===`) is probably another of the most misunderstood. Several chapters of "Types & Grammar" are devoted to explaining types and coercion, which are essential to realizing that `==` is not something to avoid in your code, but to embrace as a powerful tool (only if you know how to use it responsibly).

I definitely have strong opinions on the appropriate usages of `var` as well as ES6's added `let` and `const`. To summarize, I recommend:

1. use `var` for more declarations
2. use `let` when you have a specific variable to be used in a specific, small block of code
3. if you really find a place where having a variable un-reassignable, such as when you are doing something like `var SOME_CONST = 42`, then you can use `const`.

That advice is literally opposite of what you hear from most JS experts.

I expound on the why's of my positions in great detail in these two blog posts:

https://davidwalsh.name/for-and-against-let

http://blog.getify.com/constantly-confusing-const/