Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

Created July 20, 2015 08:27
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save azu/ec6c5721393b8c3a6845 to your computer and use it in GitHub Desktop.
Save azu/ec6c5721393b8c3a6845 to your computer and use it in GitHub Desktop.
JSJ The Future of JavaScript with Jafar Husainのメモ 📝

168 JSJ The Future of JavaScript with Jafar Husain


I can clarify this for you. This is how it works. If you're speaking to a member of TC39, it's calledJavaScript 2015.

公式にはES 2015というけど..

DAVE:So, you're planning on annual releases?JAFAR:That's exactly the point of the name change, yes.


JOE:If the pace was so slow before, what's changing that makes you guys feel confident that a yearlyrelease is going to be viable?


What we have in JavaScript is we have this ladder process of maturity for features, the ES featurematurity stages. And so, as features move through stages, as part of moving through those stages

JOE:Well, we've also got the issue that there's a lot of features that you can't implement with Babel orany other transpiler because the browser... like WeakMaps as an example


Well, I don't know. So, WebAssembly is still pretty darn new.


So, does this have any relation to Google's NaCl?


So, my question was, at what point is it, you said you're working with the different browservendors so, at what point is it priority for them to focus on performance over getting out newfeatures for ES7?

JAFAR:Yeah, I think the interesting thing is performance is a bit of the chicken and egg problem.


So, I have a related question. It seems like a lot of features are easy to implement as polyfills. Andobviously not ES6 but with a lot of stuff we've had in JavaScript it's been easy to implement as apolyfill.

my questions is why do these browser vendors even bother implementingthings slowly and releasing them rather than just including a JavaScript file in with every singlepage? And then when they've got it fast enough, then switch over?


Bind, Ithink it's trivial to polyfill if you use bind in the 99, 98% case.

But that necessarily makes the implementation of certainfunctions like bind for example, more complicated than they need to be. And here's the thing.When people polyfill, they don't worry about that 2% or that 3% and they cut corners. Andsometimes, that's why they get better performance


AJ:So, then why are you worried about that 2 or 3%?



We need multiple implementations ofJavaScript that all conform and all work.


And it's very healthy to have all these implementations.But that means you can't really just gloss over stuff. You've got to be very explicit about whathappens when somebody passes this parameter, these parameters in this order, to this function,on Wednesday when it's raining. And then every single browser needs to do the exact same thing


So, what is TC and what is 39?

TC is 何、39 is 何?

TC stands forTechnical Committee

DAVE:So, what are the TC39 meetings like? Is it like the Microsoft engineers arm wrestling with theGoogle engineers?


JAFAR:And you know, here's the thing. I think it's great. It's actually, it's had an incredible effect on me asan engineer. It's actually really pushed me to level up, because you're working on that committeewith some giants, some absolute giants. People like Brendan Eich and people like Mark Miller forexample. And you've got people who have been in this industry for 20 years. They've reallydistinguished themselves



Iprefer the way that TC39 works, which is to say that it's a consensus-based model

元々はconsensus-based modelだった。

DAVE:Should we talk about some of the cool new features coming out, then?


some of the ones I'm actually really excited about at themoment are decorators.



JAFAR:Well so, decorators happen at run-time. There's no performance benefit. This is really purely abouta syntactic affordance.

decorators aredifferent than annotations.



Now, when it comes to the question about transpilers, are we going to have transpilers forever? Ihope so. Transpilers have been an incredibly valuable thing for the committee. Right now, when thecommittee proposes a feature, previously to transpilers, the only mechanism we had was to getbrowser vendors to go and implement it.

これからもTranspierをずっと使い続ける事になるのか? という質問にJAFARが “I hope so. Transpilers have been an incredibly valuable thing for the committee.” と答えてるの面白い

今までは、Firefoxなどフラグで新しい機能を試してフィードバックをもらうというプロセスを取っていた。 けどBabelのようなTranspilerが出てきたことで、このフィードバックのプロセスがほんとにすぐ出てくるようになってきた。 なので、Transpilerを今後使い続ける = 新しい機能の仕様策定が進みやすいとも言い換えることができるのかも。

I don't see transpilers as any different than any other piece of software, to be honest. Now that wehave things like

I don't think languages are special in the sense that they're just another piece of your softwarestack



Yeah. It's interesting. I think it's fair to say that momentum on Object.observe has stalled.


I mean, well I think it's things like there have been some incredible developments in thelast two years in UI development



I think a lot of people when they dropped Object.observe in their program didn't magically find thatmost of their model-view synchronization problems have been solved


And interestingly enough, this new approach with immutable types of modeling the state of youruser interface in an immutable pipe and then effectively creating a whole new copy of that typewhenever you change i


So, async/await, so I don't... immutable types are interesting because they were recently proposedfor JavaScrip


CHUCK:I just want to chime in here because the immutable stuff is, it's really interesting. I just got into Elixirwhich is a language that's written on the Erlang VM

昔ながらのPHP templateのウェブ、最近のシングルページアプリケーション。




DAVE:So, is immutable objects coming in a future version of the language?

JAMISON:So, I have a radical subject change. I've heard a lot about symbols in ES 20... 27, ES27


symbols are actually, I wonder how much the average developers are going to use symbols.Symbols might be one of these things that's a primitive that your library uses


JAMISON:It kind of does. That kind of sounds like symbols in Ruby. Is that similar?


I believe yes, they're basically similar in terms of what they are, yes.

I know you've done a lot of work with observables. Can you talk a little bit aboutthat? And does that fit at all in any of the new features in JavaScript?

JAFAR:Well, so observable is currently proposed for ES2016. And it's currently moving through thestandardization process. I think we're on stage one now.


JAMISON:This is... there are lots of libraries that do this already. So, is the difference... what's the differenceof building it into JavaScript?


AFAR:Well, so what's really interesting about observable is that a lot of people are familiar with iterable.Or I'm just curious, because I know now everybody has had a chance to fully digest some of thoseES6 features yet.


We touched on async/await for a brief second. And it's one of the mostpopular topics out there right now. So, can you go over that briefly?


asyncでfunctionをmodify awaitでpromiseがresolveされたらresume

async function top on generator.

. Do you have this n squared problem where for every new feature you have nfeatures you have to go back and review for edge cases like that?


JavaScript is not small. JavaScript isa big language and it's getting bigger and bigger


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment