This is a good question. Because it's not like browsers couldn't implement another language if the wanted to. I think it comes down to a few things. First, JS has a governing body that sets a standard about what the language should support. It's vendor agnostic and has some really smart people on it making good (most of the time) decisions about the language. That would be hard to reproduce. Second, browsers have a hard enough time keeping performance and implementing features in JS let alone another language. Third, we've already seen that other compile to JS languages can implement their own spec and then just compile really good, performant JS code that gets run in the browser. JS is just leveraged like assembly with C.

I did a quick jsfiddle of what I was thinking. I do like your .find better! https://jsfiddle.net/xon0rxjh/

I think the dirty secret of Redux is that you don't *really* need it. You can choose to use it, and there are some good reasons to use it, but there's no reason everything in React can't just be props, children and state. Unless there is a compelling reason for me to use Redux, I don't. What Redux gives you is the ability to inject state into any component, anywhere. It can make it easy to get lazy with how you construct your application and nest your components unless you are diligent and keep some kind of structure in your state object that maps well to your set of components. If I were new starting out in React, I'd just do state and props and try to keep components in charge of their own data. When you work out this separation, it will make your app more structured and easier to manage. If you have the use case of saving an entire huge object at once, then maybe Redux is a better choice, but it adds overhead and complexity that can be heavy.

Usually mapping over an array implies you are modifying each member of the array, so maybe .reduce is a better option here. You reduce over the array and transform it into something different. I'd say that setting fiber = item if the function doesn't return isn't that great. Since you are doing two discrete operations - one is transforming the array and the other is picking out the single item that isn't celery - two operations is fine. The second operation could just call filter on the array and return 'celery'. Or .some() over it and return false when you find it. To me, combining the operations into that one callback is not as clear as doing the two separately. Performance shouldn't be a concern until it is a concern IMO.

I see compile to JS languages becoming more and more important due to limitations of JS itself. Do you see those types of higher level languages eventually becoming the web programming platform or will JS evolve into a language that fills those gaps? Do you see JS ever addressing static typing through native language constructs?

I like this answer, but every interview I've been to seems to center around trying to figure out if the interviewer can prove that they are smarter than you. Not one place I've interviewed at put that much weight on soft skills.

I do love front end development and it is indeed complex. I agree with Tommy Hodgins that our abstractions have made it difficult, but I will add that good, usable UI is a very complex thing. Why do we have hundreds of libraries and languages and tools that are dedicated to it? Because its a hard problem to solve and there are lots of people trying to make it easier, but after all of the work - it's still hard. Even with the best tools, it's hard. It's hard to not only write the code, but to design it so that users 'get it' and are able to use it in a way that makes it easy but at the same time powerful. I love UI work because its the closest you can get to the end user of an application. The work you do will be clicked on and dragged and dropped by the actual end users. Humans. You can make their day or piss them off. It's really cool in that way. When you build people something that solves a problem for them, and they love it, and they tell you they love it - that's a cool feeling.

I think in this case he intends serialization to mean the transformation of an action to a medium that can be sent to another system or application. An action can be serialized into JSON and then returned as an object to another system or application that can then read it, and use it. In this case it's temporarily stored as a JSON object, but for the purposes of communication. Storing it for later means just that. Write it to an object and persist it somewhere. Local storage in the browser or an object based DB or wherever. Then you can read it back later and use it. Both can be powerful techniques.

These both appear to be equivalent, but the main difference is that the second one is understandable by the next person to maintain it and the first one it not. The comma operator is a strange way to have multiple statements executed on the same line. It wouldn't pass my code review.

If I were trying to get a startup off the ground and I had to choose from all available technologies, I probably would choose something other than React; not 100% because of the patent clause, but it would weigh into the decision depending on what industry my startup was in. IANAL, but I believe for 99.9% of businesses, it's not going to affect them. So if I had 75% of my codebase written and I was trying to get to market as fast as possible, I'd check with a lawyer, but unless they told me to unequivocally shift stacks, I'd forge ahead. Time is a greater enemy at this point that the React patent clause. That being said, if I was just starting to write my platform or app, I'd take another look at my options and think about going in a different direction.