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.

I assume based on your tweets, sorry If i judge it wrong.

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: 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.

Absolutely. A lot of the hype around redux is likely driven simply by the fact that Facebook uses it and it's unofficially associated heavily with React from near the beginning.

Mobx is basically Ember for people who want to use React. (in a good way)

WebAssembly will be able to perform better in a lot of ways: file size, parse times, runtime performance. But it will also open the door for features JavaScript doesn't (and never will) support. True multithreading, SIMD, etc. asm.js was the attempt to force the square peg in the round hole of JavaScript, but it just reminded everyone that JavaScript is a great dynamic language but a lousy compilation target.

No.

Well....maybe. Some day. Depends on your definition of "die". I wouldn't be surprised if in 10 years most complex apps are written in another language like Reason/Elm/somethingelseyettobecreated. But while we've been mostly forced to use JavaScript this whole time, it's popularity isn't just because of monopoly. Through its faults it has a lot of traits that are perfect for many websites, particularly for people just getting started. I predict JavaScript will live for at least my lifetime, but the distinction between web and native will blur completely.

I'm a MacOS guy, primary editor for JS is VS Code. Nearly all my projects use webpack, eslint, and Babel/Typescript in some form or another.

Funky Karts for sure: https://www.funkykarts.rocks/demo.html

There's a first-person shooter game I saw a couple months back that was ported but I can't find it :( it was pretty sweet, showing 3D with particle effects, etc. But it was early and a bit glitchy still.

Hmm I'm not 100% sure on the first question, but I can confirm that using redux in general is often bringing in unnecessary complexity and pain. I think I'm too close to it all to know whether it's truly over-engineering in general though..definitely possible.

Our docs on testing have definitely been neglected..I had hoped that we'd have time to improve rxjs's testing story in general, since testing in redux-observable should be nearly the same. There's been some movement in that front but not super solid yet.

I most often test my epics these days by calling them directly, without redux/middleware at all. Check out the example here: redux-observable.js.org/docs/recipes/InjectingDep…

Some experiments around marble diagram testing (but still alpha quality):

https://www.npmjs.com/package/rxjs-marbles https://www.npmjs.com/package/rx-sandbox

We're given a ton of freedom to do what we think is best, so every team can and often does do things differently. Some teams to TDD, others (like mine) don't.

Most teams here use Jenkins for some things, but there's a lot of hardware related testing that goes on that's pretty complicated.

Automation is key 🔑

Seamless tooling for sure. Webpack is going to make this much more mainstream I think, at least for consuming existing wasm libraries.

Oh it's been talked about for sure. I'm not aware of any concrete usage yet, but it's only a matter of time before someone uses it somewhere at Netflix, probably for internal stuff since there are a lot more greenfield projects. I've been playing around and keeping an eye on it, so for me it's still too volatile to commit to. But I have my own language stuff I'm working on so I'm a bit biased :p

Being consistently challenged. I often see people stagnate in their jobs, not really learning much new. I love being in over my head and dig my way out. Remember it's not about how many years, but rather what things you've done and learned in your career. Side projects can be a great outlet to experiment and challenge yourself, if you have time.

Absolutely! You can make the experience even better using this: https://github.com/vuejs/vue-rx

Here are some my favorites:

• medium.com/@benlesh/learning-observable-by-buildi…
• https://www.learnrxjs.io/
• https://egghead.io/technologies/rx

There's not much specific to Node.js, but it will be helpful to learn how to create custom Observables so you can wrap more imperative APIs or make utilities. Ben's article above will definitely be the best resource for that.

While you're learning, keep an eye out for v4 vs v5 documentation and libraries as some things changed between those versions and people often get tripped up trying to use v4 code or APIs with rxjs v5. Hopefully this shakes out as time goes on. There are still some active efforts to mitigate this.

I unfortunately can't accurately speak for those teams. It's entirely possible that they've experimented or even have future plans for RN though. It's pretty sweet, and Netflix has a similar tech called Gibbon we use on our TV UIs medium.com/netflix-techblog/crafting-a-high-perfo…

Shoot, this is probably a subject in which I am woefully uninformed.

I'll give it a shot, but keep in mind these are just my opinions lol 🤡

Programmer: a person who can write code, very often relies on others to make decisions; e.g. advice from the lead engineer, or copying and pasting code off StackOverflow. Doesn't knowingly use their own abstractions.

Good Programmer: a person who can make complete solutions. They can go from an idea to a product on their own. They still copy and paste code off StackOverflow sometimes, but less often as usually they understand the solution's code and write their own variant. Uses abstractions, but sometimes prematurely.

Great Programmer: a person who can do all the above, but also enable others to do them too. Much better at not doing premature optimizations/abstractions, but of course still is guilty. Still copy and pastes code off StackOverflow.

I described them as three categories, but really people's paths and abilities vary. So the path to being a Great Programmer is tough to say, but I've found true passion for programming often correlates. Consistently challenging yourself with harder and harder problems that you enjoy is my advice. The saying "if you're the smartest person in the room you're in the wrong room" is very apt as well.