This AMA is over, Ask Direct Question!
You can ask a direct question on their Hashnode profile, anytime!
Thanks everyone for the great questions! This was a lot of fun! Please feel free to reach out to me on twitter (@bterlson) or email (brian dot terlson at microsoft dot com) or IRC (bterlson on freenode) if you would like to chat further. See you out on GitHub!
What do you think about recent Facebook ReactJS License controversy? Do you think it's a blow to the OSS world?
How would businesses and startups believe in OSS projects built by big companies like Microsoft, Facebook, Google, etc. in future?
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!
How would you explain TypeScript to a novice programmer?
I doubt this will be a good answer, but I'll give it a shot :)
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!
Hi Brian, It's awesome to see you!
What are the few dev tools (software and hardware) you cannot live without and carry with you always? :)
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 ;)
Do you think TypeScript will be the standard for writing types in ES7/ ES8/ ES9 or whatever in near future?
How would you describe your own experience with TC39?
For example, what happens during a meeting? How much time do you dedicate to TC39-related work?
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 :)
Hello Brian, thanks for doing this AMA.
These are my questions:
What are some exciting features we can watch out for in ES.Next?
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).
Can you tell us briefly how TC39 works and how are meetings arranged/handled?
Thanks for doing this.
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.
Hi Brian, Have you tried ReactJS library? What are your thoughts on it?
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.
Hey Brain, thanks for doing AMA, my question to you is what's the performance benefit of Chakra over V8?
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.
Thanks for doing the AMA Brian, I would like to know what inspired you to become a developer
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
Why would you choose TypeScript over CoffeeScript?
What major changes, if any, should we look out for in the consequent ECMAScript releases?
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!
What are the few things missing in ES6 and you would like to see in future upgrades?
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
What did you use in your recent project? ES6 or ES5? And why?
How and when did you start your career as a programmer? Would you mind telling us about your story?
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 :)
Should new developers learn ES6 directly or should they grasp old JS first?
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!
I have seen TC39 proposals in Github. On what basis you guys will accept the proposals?
Recently I have come to know that ~~5.3 == Math.floor(5.3).
I think Math.floor() gives better readability. What do you think about that?
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.
What tools/setup do you use to make your development workflow more productive?
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.
What are unexplored spaces in the TypeScript eco-system you'd like to see people explore further?
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.
What can we (as a community) do to encourage more and more developers to contribute to open source? I know many developers who want to contribute, but they don't know how to start. Besides most of their time is spent fixing bugs at their respective companies.
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.
What are Microsoft's long term plans for Chakra?
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 :)