Skip to content

Instantly share code, notes, and snippets.

@azu
Created July 20, 2015 08:27
Show Gist options
  • 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.

1年リリースのための名前変更

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?

ES6でGeneratorやPromiseなど大きな基盤は入ったので、これからそれを元にした機能などが入っていく。なので短い期間で済むのではという感じ

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

Transpilerでは実装できない機能もある。

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

WebAssemblyはTC39としては今のところ特に関係ない

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

NaClとWebAssemblyの関係?

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

polyfillは98%-99%ぐらいは問題ないけど、実装はそこもちゃんと気にしないといけないし、コーナーケースもちゃんと拾う必要がある。

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

=>

Twitterは一日に2億回Tweetしか失敗していません(2%)だと問題があるので

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

すごい人たちが集まる。


Tc39のプロセスモデル。

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.

Decoratorを例に

Decoratorは静的に見て同じAPIであるということがわかるのが良いところとかなんとか

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

decorators aredifferent than annotations.

annotationはmetadataを加えるだけだけど、Decoratorはそれにくわえてmethodへのmixinができる。


transpilerを使って新しい機能を試せるけど、それ以降にその機能が変更された時に、無数のバージョンのJavaScriptができてしまうのでは問題について

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

良い

Transpilerにより言語のプロトタイピングが進みやすい。


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

Object.observeが失速した感じがよね的な話から

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

最近、UI開発は変わった話

React、ClojureScript、Omの話

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

Object.observeのアプローチが解決すること

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

Reactとかで見るようになったアプローチが解決すること

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

async/await

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

Object.observeは配列の変更を監視して、その変更に合わせて差分を検知して変更して、Viewをへんこうして...

ReactみたいなJSON渡したらDOMができるような世界。

一つのStateのJSONをローカルストレージからre-hydratedしたら再現できるような感じ。

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

Symbolがいっぱいる増える。

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

Symbolはライブラリ向け

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

Rubyのと同じなの?

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.

今Stage1

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

今あるRxJSみたいなライブラリとは違うの?

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.

iterableと親和性が高くなってる

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/awaitの仕組み

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


以下ES2015,2016一問一答

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