Skip to content

Instantly share code, notes, and snippets.

Created Jul 20, 2015
What would you like to do?
JSJ The Future of JavaScript with Jafar Husainのメモ 📝

168 JSJ The Future of JavaScript with Jafar Husain


Page 4

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というけど..

Page 4

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


Page 5

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?


Page 6

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

Page 7

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


Page 7

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


Page 8

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


Page 8

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?

Page 8

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


Page 9

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.

Page 9

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?


Page 9

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

Page 10

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


Page 10

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



Page 10

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


Page 10

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


Page 11

So, what is TC and what is 39?

TC is 何、39 is 何?

Page 11

TC stands forTechnical Committee

Page 12

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


Page 12

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



Page 12

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

元々はconsensus-based modelだった。

Page 13

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


Page 13

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



Page 14

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

Page 14

decorators aredifferent than annotations.



Page 16

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を今後使い続ける = 新しい機能の仕様策定が進みやすいとも言い換えることができるのかも。

Page 16

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

Page 16

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



Page 17

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


Page 17

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



Page 17

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


Page 17

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


Page 18

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


Page 18

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のウェブ、最近のシングルページアプリケーション。




Page 21

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

Page 21

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


Page 21

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


Page 21

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


Page 22

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

Page 22

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?

Page 22

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.


Page 22

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


Page 22

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.


Page 23

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.

Page 25

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


Page 25

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