You're welcome! Very glad you enjoyed it.

Pros: Additional documentation on top of what's already available for the individual components, and how they work best together You don't have to make as many choices, which can get fatiguing and you're more likely to get them wrong Sometimes these groupings help with employment and hiring, like what LAMP did. I love React. I love React. Cons Redux being included as part of it contributes to the issue of people bringing in Redux too early and/or in apps that don't need it. MongoDB might not be the best choice for every use case. It also hasn't had the best rep recently with the accidental exposure/deletion/ransom of people's DBs. All in all, I think MERN is a fair guide for those who just want a more complete paved road. To be honest though, I don't know anyone personally who has used the actual MERN stack CLI or boilerplate stuff. They just use the things that happen to be part of the acronym.

Hey Ahmad, shoot I'm sorry I made it sound like I hate React! I love love love it! It's my daily driver. If you have a moment to share the tweets you're referring to it would help me prevent this in the future.

I think I really leveled up when I started writing more libraries as well as trying to understand more about how things work. e.g. really understanding prototype inheritance. I'm a armchair compiler nut, so I would also refer to the ECMAScript spec quite often too. One thing that I've found helpful in teaching others is actually reviewing what ES6 -> ES5 compiled code looks like from Babel and understanding the choices it makes, particularly when in spec-compliance mode where the output can be a bit verbose. I'm not a big book person, so I can't recommend any on JavaScript unfortunately. I have heard lots and lots of praise for the "You Don't Know JavaScript" series, but I have not myself read them: https://github.com/getify/You-Dont-Know-JS I've found egghead.io to be pretty awesome, and they have lots of free content too. I recommend them so much I sometimes wish they had some sort of referral program lol.

PWA's are great when they're available and work. Many devices/browsers don't support them fully yet though (or in a usable form) and they're still a bit tough to get right for the average dev. I got frustrated for an embarrassingly long time learning ServiceWorkers. As far as Netflix.com becoming a PWA, it might happen at some point, just not yet. e.g. iOS Safari is DOA because no ServiceWorkers and no Encrypted Media Extensions. Their "save to home" UX isn't yet as seamless as Android's. I'm not on the team responsible, so I don't want to speculate too specifically! :o)

Without a doubt, and it's already begun. First it was separate processes per tab, then they started splitting off things like HTML parsing, layout, GC, etc into separate threads. I'm super excited about the innovation that's being made--Mozilla's Quantum and Servo are shining examples of this. If I didn't know better it seems like Mozilla is going to have their cake and eat it too: multithreaded performance while also becoming more memory safe than all the others, thanks in part to Rust. But don't count out the other browsers, this race will continue!

The monkeys live! I haven't heard of any new monkeys recently, but we've upgraded Chaos Monkey a number of times and continue to increase our failure injection initiatives. Speaking of which, the Chaos team recently released a free e-book through O'Reilly if this stuff tickles your fancy: http://www.oreilly.com/webops-perf/free/chaos-engineering.csp

This one is tough for me as I don't have any experience building software for kids. But I do have lots of UX experience, so I would probably approach it similarly: start off with a prototype, going with my gut on UX decisions. From there, have some kids use it with as little direction as possible and watch their behavior. What do they click on? Where does their mouse move to? Where do they get confused? What's missing? It's definitely useful to have them provide feedback as well, but I imagine it's like UX for adults in that often people say one thing but do another. Just keep it in mind and correlate with others too. There are also data collection laws regarding kids. To be honest, because kids software feels like a whole different realm to me I'd probably bring in someone else to help me, or at the very least do a ton of research into existing studies and observations of others.

I usually advise: 100% don't learn React while also learning Redux. Learn React with setState and for the average app (which is most) Redux would have just been significantly overcomplicating things. That said...if you're the curious type it's very cool to learn Redux in your free time to understand the paradigm and get a better idea of what it's good at and more importantly what it's bad at.

Sure thing! Netflix definitely has a unique way of doing things. Pretty much everything revolves around the idea of getting every engineer the same freedom as well as responsibility. Avoiding rules as much as possible. This philosophy drives our engineering efforts too: teams decide what technologies they want to use, what they want to work on, etc. Now, certainly some roads are paved more than others, but no one is going to tell you no. It's not all chaos though, as engineers collectively realize being aligned, when possible, helps everyone. So we do a lot of collaboration and you'll definitely see trends, like our heavy usage of Java and React. But I think it's really important to know that Netflix has the whole gamut of things. Ember, Angular 1/2/3/4, Polymer, Backbone, Vue, Groovy, Scala, Kotlin, Haskell, Python, Ruby, PHP, etc. Some of the most complex UI apps at this big companies are internal and not written in React. They have to deal with very unique scaling issues as well as a user-base who's highly technical and often make mission critical decisions. As far as Vue vs. React, they're both excellent. Vue is going to feel much more at home if you come from an Angular 1 background and/or you prefer template-based UI layers. React on the other hand is all about JavaScript. There's no brand new templating language, though nearly everyone uses the JSX language extension to JavaScript to make things a bit more similar to HTML. Vue does have a lesser-known way of using JSX too which is AWESOME, but it's not currently the recommended way. I prefer React at the moment because I got jaded using templating languages, constantly needing to make and expose helpers, bikeshed with the maintainers about adding syntax to the template language, etc. With React I just write JavaScript. I love map/filter/reduce, so that's what I can use! Again though, Vue technically can allow you to do this too, but it's not the recommended approach at the moment. That said, I'm pretty confident that most templating languages have the potential to beat the pants off JSX-style virtual DOM because they can better statically analyze them and do all sorts of optimizations. Ember's Glimmer is actually leading the way in this right now IMO but like the browser wars the UI libs seem to take turns becoming the perf leader of the year. There's also still a lot of optimizations you can do to JSX, and even more if you're OK with sometimes deoptimizing certain edge cases that are ambiguous. A great example is automatically extracting ports of your JSX that never changes: https://babeljs.io/docs/plugins/transform-react-constant-elements/ While I’ve used Ember and Angular pretty extensively, my actual experience with Vue so far as mostly been playing around, as well as helping others who just happened to be using Vue. So definitely my opinions are skewed. Vue also has a much more first-class experience with Observables, which I’ve been keeping a close eye on.