This is a question I consider every day, and I wish I had a good answer. I'm not an expert on building communities. Some ideas I think work:

• Foster a community that is respectful and inclusive, especially to people with different backgrounds and experience levels.
• Call out specific tasks that new contributors might be able to tackle(ChakraCore has a your-first-pr label, for example). Offer mentorship if possible to help contributors make their first contribution as well.
• Encourage non-code contributions. Things like documentation, PR/issue templates, wiki, etc. are often more important than feature work.
• Evangelize. I've been speaking at some conferences lately about how people can get involved with ECMAScript. Sometimes directly reaching out to people is all the push they need to get involved.

Fundamentally, though, if your employer can't support you working on open source, you'll have to carve time for it. This can be hard and I don't have any good ideas to make it easier.

For Node, I've only ever used Azure AppInsights which did auto-reporting of errors, perf telemetry, and a few other things with little setup. It was pretty nice overall. But I can't speak for how well it stacks up vs. other solutions out there. Sorry I can't help more!

I mentioned a bit of it here. I've been a programmer for so long I don't really exactly recall when I started!

But, to continue that narrative, my senior year of high school was probably when my career technically started. I got a job building a simple ASP website for a small manufacturing education company. This job put me through college, along with another web dev job for a small human resources consultancy. Eventually both projects moved from classic ASP to Rails.

After graduating with a degree in CSci from the University of Minnesota, I did a startup thing for a while. Built a really cool app to make it easy for HR departments to survey compensation and benefits practices from their peer companies while complying with federal antitrust guidelines. It was a lot of fun and I learned a lot, but it was failing and Microsoft made me an offer to come work for them on the Test team for Chakra and, well, here I am almost 8 years later :)

I don't think I am prescriptive about this. Some people learn better by understanding the foundation (say, closures and prototypes) and then moving up. Others learn better by understanding the high level (classes) and dig down when needed. I'm not sure one way is better than the other personally!

JS For Life!!

Proposals follow this process document, which has all the entrance and exit criteria for each stage along the way. We accept basically any proposal from a delegate as Stage 0. The requirements get progressively steeper as you move along the process.

I'm usually not a fan of opaque patterns for saving keystrokes. I agree with you that Math.floor gives better readability here. I think the only shortcut I allow is !! for, essentially, ToBoolean.

So many things. Mentioned a couple already: VSCode and Hyper. A couple recent additions that I really love: the VSCode prettier extension that gives me format-on-save, and the Git Lens VSCode extension which shows inline git blame annotations. I use blame ALL the time for ECMA262 so having it inline has been a huge time saver.

Another task I do very frequently is compare how snippets of code run across various runtimes (Chakra, v8, Spidermonkey, JSC, etc). I build a tool called eshost that abstracts the differences between these runtimes and compares the results of them. This has probably saved me days of manual effort.

I'm more excited about what I can't see than what I can! But one thing that I've been thinking about lately is how Machine Learning can be applied to TypeScript, both in terms of using ML to gather information and inform TypeScript's design, and perhaps TypeScript itself using ML to infer complex things about your programs or carry out complex context-dependent tasks like refactorings or what-have-you. I feel like agent-assisted programming is going to be a thing in the future.

I would choose TypeScript over CoffeeScript for a lot of reasons! As someone who did professional Ruby development for a number of years, I have a soft spot for CoffeeScript, but I wouldn't use it today personally. First, TypeScript offers a type system which is extremely useful especially for editor tooling. Second, TypeScript is built on JavaScript so it's the same syntax with the exception of the extensions for type annotations (which are optional anyway with TypeScript's --checkJs flag) and is easier to learn. Third, many of the features which made CoffeeScript great have been incorporated into ECMAScript and therefore TypeScript itself, so many of the reasons to use CoffeeScript are no longer true.

I've answered previously about what's coming up. In general you can always keep tabs on the proposals repo - the higher the stage, the more likely it'll be in the next version!

I don't focus much on performance, but by and large, both engines are extremely fast for any real world use case (i.e. that exists on the Internet). I even help make sure that's the case by reporting performance issues to v8 when I find them! I'm not sure there's a strong performance reason to use one over the other, especially now that V8 has an interpreter too.

I answered some of this in another question, but in terms of how the meetings are arranged - the meeting schedule is set, and then we try to find hosts and locations. It is sometimes hard to find hosts for 50+ people for 3 days! Then we build the agenda on GitHub (you can watch these agendas here), and follow the agenda during the face-to-face meeting.

At a high level, the face to face meetings are all about getting consensus. We never vote, we only proceed with unanimous consent. In practice this might mean someone doesn't like the direction but isn't willing to stand in front of it. But it also means that delegates have to work hard to bring along the entire committee, not just a majority necessary to win approval for a feature. This is TC39's most awesome aspect, in my opinion. It ensures that everyone work together in good faith toward mostly common goals.

You can see some of our long term plans on the GitHub roadmap. We're continuing to invest in WebAssembly, with lots of work to be done there. We're continuing to improve performance across real world scenarios and implementing the latest and greatest language features coming out of TC39 as well. But this is mostly just our DNA - see the roadmap for more details :)

I like Lodash and Underscore. Very useful libraries. I'm not sure how Lodash functions and native functions compare generally speaking other than the obviously different API.

If ES.Next refers to ES9 (ES2018), then I'd say, hopefully: Async generators, public and private fields for classes, rest/spread for properties, and if we're lucky, a whole slew of new RegExp features (look-behinds, named capture groups, Unicode character classes, dot-all) that will make the RegExp writers among us super happy I think. I'm also really excited about BigInts which is a new number type that can only hold integers but can have any precision you want (to see why this is important, try 9007199254740992 + 1 and see what you get).

I've had a ton of fun working with TC39. I feel really lucky. It's been very rewarding to have an impact on the language that I love and to have so many phenomenal engineers and experts to learn from.

In terms of meetings, they are three days, 8 hours a day, with social events and break out sessions outside of meeting hours. Last meeting we had around 50 delegates all in one giant meeting room United Nations style!

For introverts like me, the meetings are incredibly draining, but I think they are also lots of fun. Delegates bring up agenda items related to language proposals they are working on and the committee discusses them. Delegates work to advance proposals through a staged process. And that's pretty much it at a high level.

Outside of meetings is where most of the TC39 work happens. Delegates are always working on their proposals on GitHub, and there is always editor work to be done on the main specification. I keep tabs on most of the proposals and am deeply involved with a few. These proposal repositories are a great way for everyone reading this to influence the future direction of the language as well :)

I spend probably half my time doing TC39 and standards related work, and I'm very thankful Microsoft lets me spend this much time doing it :)

Hardware wise, I really like my Surface Book. It's been my main machine now for over a year. I actually use the tablet mode quite a bit. And, I can't dev without a touch screen anymore. So handy for scrolling! In terms of its software, my favorites are probably VSCode and the Hyper terminal (both Electron applications... yay JS!!).

Otherwise the only hardware I always have on me is my phone. It's an S7 Edge, but I don't like the curved screen at all so I could live without it personally ;)

This is a pretty long list! I'm a fan of most things you'll find on the proposals repository. At a high level we're looking at:

• Improvements to classes (the ES6 design was deemed maximally minimal - the most we could get consensus on at the time - and the intention was always to come back and add more capabilities over time including decorators and private and public fields)
• Improvements for functional programming
  • Pattern matching (see my proposal here).
  • Pipeline operator & syntax for partial application
• Async programming improvements (including cancellation primitives)
• Fixing the Date dumpster fire

ES8, actually! My latest project is adding a --install flag for eshost-cli to install javascript hosts from public file shares so you can use the tool without manually downloading or compiling your own from source. I struggled with putting the logic into promises, but because it's really branchy and includes loops, it was very hard to reason about. Using async functions instead made it almost trivial! I love that feature (and not just because I championed it ;)). Yeah, now I have a node 8 dependency, but I could fix that with a transpiler if I cared enough.

Speaking for myself only... (this applies to all my answers)

I am not a lawyer, and am not really an expert on licenses (I know enough to know that, at least). I've read opinions from experts saying that the BSD+Patents license is risky for adopters, and I've read opinions saying it's just fine. I'm not sure where the truth lies.

While I think in practice for most projects the license is unlikely to be a big issue, it is a blow to the extent that we've devoted a bunch of cycles to debating this issue and there are some people who are worried. Thankfully there are a variety of great alternatives to pick from in our ecosystem!

I have built a few things with React. I don't have deep thoughts, but I found it to be easy to use (with create-react-app, anyway) and works nice with TypeScript too. I try to use all the big frameworks. It gives valuable perspective for the language work that I do both in TC39 and on TypeScript and Chakra.

I doubt this will be a good answer, but I'll give it a shot :)

TypeScript is just JavaScript but with a type system – a tool that understands how data is shaped and how it flows through your program. The type system lets JavaScript programmers take advantage of advanced editor features and tools like code completion and to prevent bugs that even experienced JavaScript programmers make frequently. TypeScript’s type system is one of the most advanced type systems in significant use, and in many ways eclipses the capabilities of languages like C# and Java while being highly expressive, easier to use, and a much better fit for JavaScript.

TypeScript makes it easier to write correct, bug-free code. For example, it will warn you as you’re writing your code if you call a function with a string instead of a number, access a non-existent property on an object, or if some variable might be null or undefined.

TypeScript also makes it drastically easier to develop large code bases because the type system ensures everything in the program remains consistent. For example, if you want to rename a method of a class, you can just do it and every usage of that method gets updated with the new name.

Depending on the novice, at this point I might go on to describe how one works with types in TypeScript (short answer: type inference, type annotations in jsdoc comments and/or using type annotation syntax), but maybe the above is sufficient. Let me know if you have more questions!

Speaking as someone who proposed types for JavaScript in 2014: I do not believe types are in the cards for the near future. This is an extremely complex problem to get right from a standards perspective. Just adopting TypeScript as the standard would of course be great for TypeScript users, but there are other typed JS supersets with pretty significant usage including closure compiler and flow. These tools all behave differently and it's not even clear that there's a common subset to work from (I don't think there is in any appreciable sense). I'm not entirely sure what a standard for types looks like, and I and others will continue to investigate this as it could be very beneficial, but don't expect anything near term.

This is hard to say. It's something I've almost always done! I've been very blessed to have had so many opportunities to become a developer, hone my skills, and apply them in the real world. My parents and a few excellent teachers probably inspired me the most. To call out some specific milestones that probably influenced my path:

• The Apple ][c my family purchased in the late 80s, upon which I learned basic and the joys of Lode Runner.
• My fifth grade teacher Mr. G who encouraged me to stay after school to work on the school's website, which I had a lot of fun doing
• Selling little calculator programs for 5 bucks a pop in middle school
• Building random web applications in classic ASP for my group of friends in high school