2016年にJavaScriptを学んでどう感じたか.md

2016年にJavaScriptを学んでどう感じたか

※この記事は"How it feels to learn JavaScript in 2016"著者であるJose Aguinaga氏による、以下のツイートの本文を確認して記事を翻訳しています。
https://twitter.com/jjperezaguinaga/status/784058480613322752?lang=ja
As long as you reference the original article, please feel free to translate/quote “How it feels to learn JavaScript in 2016” in any media.
また、このような素晴らしい記事を書いて頂いたJose Aguinaga氏に感謝致します。ありがとうございました。

※追記2016_11_23

本人からのコメントがありましたので、よかったらご覧下さい!

原文:How it feels to learn JavaScript in 2016

The following is inspired by the article “It’s the future” from Circle CI. You can read the original here. This piece is just an opinion, and like any JavaScript framework, it shouldn’t be taken too seriously. No JavaScript frameworks were created during the writing of this article.

この記事はCircle CIによる「It’s the future」にインスパイアされています。この記事は単なる一つの意見であり、JavaScriptフレームワークのように、真剣に語れるべきではないです。執筆中に新たに生み出されたJSフレームワークなんてありません。

Hey, I got this new web project, but to be honest I haven’t coded much web in a few years and I’ve heard the landscape changed a bit. You are the most up-to date web dev around here right?

やぁ、新しいwebプロジェクトがあるんだけど、正直ここ数年webのコーディングをしてなかったし環境が少し変わったって聞いたんだよ。それで、聞くところによると、君がもっともweb業界に精通してるんだろ?

-The actual term is Front End engineer, but yeah, I’m the right guy. I do web in 2016. Visualisations, music players, flying drones that play football, you name it. I just came back from JsConf and ReactConf, so I know the latest technologies to create web apps

僕はフロントエンドエンジニアだけど...まぁそうだね。僕はやったよ。ビジュアライゼーションに、音楽プレーヤー、ドローンでサッカーとか、とにかく何もかも全部ね。ちょうどその頃にJsConfやReactConfに帰ってきてウェブアプリが最先端だってわかったんだ。

Cool. I need to create a page that displays the latest activity from the users, so I just need to get the data from the REST endpoint and display it in some sort of filterable table, and update it if anything changes in the server. I was thinking maybe using jQuery to fetch and display the data?

いいね。今ちょうど、ユーザーからの最新のアクティビティを表示するページを作成する必要があって、流れとしてはRESTのエンドポイントからデータを取得して、何らかのフィルタできるテーブルを表示させた後に、もしサーバー上で変更された場合は更新するってやつなんだけど、恐らくjQueryを使ってデータを引っ張ってきて、出力すればいいのかな?

-Oh my god no, no one uses jQuery anymore. You should try learning React, it’s 2016.

おいおい冗談だろ。今どきjQueryなんて誰も使ってないよ。君はまずReactを学ぶべきだし、今は2016年だぜ。

Oh, OK. What’s React?

そうなんだ。所でReactって?。

-It’s a super cool library made by some guys at Facebook, it really brings control and performance to your application, by allowing you to handle any view changes very easily.

ReactはFacebookの社員が作ったイケてるライブラリさ。Reactを使うとビューの変更をとっても簡単に扱うことができて、統制が取れ、パフォーマンスもいいんだ。

That sounds neat. Can I use React to display data from the server?

へぇ～いいね。じゃ、Reactを使う事でサーバからデータを表示する事はできるのかな?。

-Yeah, but first you need to add React and React DOM as a library in your webpage.

もちろん、でもまず最初に、君のwebページにReactとReactDOMが必要だね。

Wait, why two libraries?

ちょっと待ってくれよ、何で2つもライブラリが必要なんだ?

-So one is the actual library and the second one is for manipulating the DOM, which now you can describe in JSX.

1つは本当に只のライブラリで、2つめはJSXで記述する事ができて、DOMを操作する為なんだ。

JSX? What is JSX?

JSX?JSXって何?。

-It’s 2016. No one codes HTML directly anymore.

ここは2016年だ。もう誰もHTMLを直で書く奴なんていないよ。

Right. Anyway, if I add these two libraries then I can use React?

そうなんだ。とにかく、React使いたければ、2つのライブラリを入れろって事だね?。

-Not quite. You need to add Babel, and then you are able to use React.

いや、待って。Babelも必要だ、それでReactが使えるようになるよ。

Another library? What’s Babel?

また別のライブラリが必要なの? Babelって何だよ?。

-Oh, Babel is a transpiler that allows you to target specific versions of JavaScript, while you code in any version of JavaScript. You don’t HAVE to include Babel to use ReactJS, but unless you do, you are stuck with using ES5, and let’s be real, it’s 2016, you should be coding in ES2016+ like the rest of the cool kids do.

あっ、Babelは君がJavaScriptの任意のバージョンでコーディングしているときに、特定のバージョンにJavaScriptを合わせてくれるトランスパイラだよ。BabelはReactJSを使うに含めなくていいけど、ES5で立ち往生しているならやった方がいいし、今は2016年だ。イケてるエンジニア( the rest of the cool kids)がやっている様にES2016+に沿ってコーディングするべきだよ。

ES5? ES2016+? I’m getting lost over here. What’s ES5 and ES2016+?

ES5? ES2016+? ついていけないよ。ES5とES2016+って何？。

-ES5 stands for ECMAScript 5. It’s the edition that has most people target since it has been implemented by most browsers nowadays.

ES5はECMAScript5の略称だよ。このバージョンはほとんどの人に受け入られて、今日では多くのブラウザに実装されているよ。

ECMAScript?

ECMAScript?。

-Yes, you know, the scripting standard JavaScript was based on in 1999 after its initial release in 1995, back then when JavaScript was named Livescript and only ran in the Netscape Navigator. That was very messy back then, but thankfully now things are very clear and we have, like, 7 editions of this implementation.

そう、今のJavaScriptの標準スクリプトは1995年の最初のリリースされた後の1999年に基づくもので、当時はLivescriptという名前でNetscape Navigator(初期のブラウザ)で走ってたんだ。当時これが非常に厄介だったけど、今はありがたい事に物事が非常に明確で、今度7が実装されるみたいにね。

7 editions. For real. And ES5 and ES2016+ are?

7だって?。まじかよ。それでES5やES2016+って何?。

-The fifth and seventh edition respectively.

それぞれ5th edition、7th editionだよ。

Wait, what happened with the sixth

おい待ってくれよ。6th editionはどうしたんだよ?。

-You mean ES6? Yeah, I mean, each edition is a superset of the previous one, so if you are using ES2016+, you are using all the features of the previous versions.

ES6の事を言ってるのかい? あぁー、各editionは以前の上位バージョン(superset of the previous one)なんだ。だから、もしES2016の+を使用するなら、以前のバージョンのすべての機能を使用している事を意味するよ。

Right. And why use ES2016+ over ES6 then?

そういうことね。でも、なぜES6を無視してES2016+を使うの?。

-Well, you COULD use ES6, but to use cool features like async and await, you need to use ES2016+. Otherwise you are stuck with ES6 generators with coroutines to block asynchronous calls for proper control flow.

いや、君はES6を使用することができるけど、async and awaitのようなクールな機能を使うなら、ES2016+を使用する必要があるね。そうしないと、ES6 generatorsのasynchronous呼び出しによるコルーチン処理で右往左往してしまうからね。

I have no idea what you just said, and all these names are confusing. Look, I’m just loading a bunch of data from a server, I used to be able to just include jQuery from a CDN and just get the data with AJAX calls, why can’t I just do that?

何言ってるか全然わからないし、なんでこんなに名前が紛らわしいんだ。なぁ、単にサーバからデータを読みこんで、jQueryをCDNから引っぱてきて、AJAX呼び出しでデータを取得したいだけだ！なぜそれすら出来ないのさ？。

-It’s 2016 man, no one uses jQuery anymore, it ends up in a bunch of spaghetti code. Everyone knows that.

2016年だからさ。もはや誰もjQueryは使わないし、jQueryなんか使ったらスパゲッティコードを量産するよ。誰もがそれを知っているね。

Right. So my alternative is to load three libraries to fetch data and display a HTML table.

そうか。じゃあ、jQueryの代わりに3つライブラリ読み込めばデータ取ってきてHTMLテーブルを表示できるんだね。

-Well, you include those three libraries but bundle them up with a module manager to load only one file

そしたら、その3つのライブラリはモジュールマネージャー使う事で1つのファイルで束ねてロードする事ができるよ。

I see. And what’s a module manager?

そうなんだ。それでモジュールマネージャーって?。

-The definition depends on the environment, but in the web we usually mean anything that supports AMD or CommonJS modules.

定義は環境に依存するけど、WebではAMDかCommonJSのモジュールをサポートしているモジュールマネージャーのことを指すね。

Riiight. And AMD and CommonJS are…?

なるほどね。それでAMDとCommonJSって?。

-Definitions. There are ways to describe how multiple JavaScript libraries and classes should interact. You know, exports and requires? You can write multiple JavaScript files defining the AMD or CommonJS API and you can use something like Browserify to bundle them up.

定義だよ。複数のJavaScriptライブラリとクラスが相互作用する方法を記述するんだ。読み込み(requires)と公開(exports)は知っているよね？君はAMDやCommonJS APIを定義する複数のJavaScriptファイルを書き込むことができるし、それらを束ねる為のにBrowserifyみたいなのを使う事もできるね。

OK, that makes sense… I think. What is Browserify?

あー、確かにね...そうだよね。 Browserifyって何？。

-It’s a tool that allows you to bundle CommonJS described dependencies to files that can be run in the browser. It was created because most people publish those dependencies in the npm registry.

Browserifyはブラウザ上でCommonJSを実行可能にする為にファイルへの依存関係を管理してくれるツールだよ。多くのエンジニアがnpmレジストリに依存関係を公開するから、Browserifyは作られたんだ。

npm registry?

npmレジストリ..?。

-It’s a very big public repository where smart people put code and dependencies as modules.

賢いエンジニアがコードとそのモジュールの依存関係を置く為の、非常に大きな公開リポジトリさ。

Like a CDN?

CDNのように?。

-Not really. It’s more like a centralised database where anyone can publish and download libraries, so you can use them locally for development and then upload them to a CDN if you want to.

ちょと違うかな。CDNは誰もが公開してライブラリをダウンロードが出来る集中型データベースだから、開発の為にローカルで使用できるし、その後にお望みであればCDNにアップロードすることができる。

Oh, like Bower!

あっ、それBowerみたいだね！。

-Yes, but it’s 2016 now, no one uses Bower anymore.

まぁね、だけどさ、今は2016年だぜ。もう誰もBowerを使うやつなんていないさ。

Oh, I see… so I need to download the libraries from npm then?

ああ、そうなんだ...、そしたら、npmからライブラリをダウンロードする必要があるのかな?。

-Yes. So for instance, if you want to use React , you download the React module and import it in your code. You can do that for almost every popular JavaScript library.

そうだね。だから、もしReactを使用したい場合、Reactモジュールを君のコードにimportすればいい。君はそれで、皆から注目されているJavaScriptライブラリを使えるのさ。

Oh, like Angular!

あっ、それAngularみたいだね！

-Angular is so 2015. But yes. Angular would be there, alongside VueJS or RxJS and other cool 2016 libraries. Want to learn about those?

Angularは2015年だろ。でもまぁ、確かにAngularはVueJSやRxJSのようなクールな2016年のライブラリと一緒になるね。どれを学ぶんだい?。

-Let’s stick with React, I’m already learning too many things now. So, if I need to use React I fetch it from this npm and then use this Browserify thing?

もうReactでいいよ。だいぶ多くの事を学んだしね。それで、Reactを使うにはnpmを引っ張ってきて、その後に Browserifyを使えばいいの?。

-Yes

その通り。

That seems overly complicated to just grab a bunch of dependencies and tie them together.

これは、たくさんある依存関係を1つにまとめる事が、かなり難しいそうだね。

-It is, that’s why you use a task manager like Grunt or Gulp or Broccoli to automate running Browserify. Heck, you can even use Mimosa.

それこそが、まさにGruntやGulp、Brocooliみたいなタスクマネージャーを使ってBrowserify自動化する為の理由だ。やばいのは、Mimosaも使うことだね。

Grunt? Gulp? Broccoli? Mimosa? The heck are we talking about now?

Grunt? Gulp? Broccoli? Mimosa? やばいのは、今俺たちが話しているこの会話だろ？。

-Task managers. But they are not cool anymore. We used them in like, 2015, then we used Makefiles, but now we wrap everything with Webpack.

タスクマネージャーに関してはね。でもさ、全部が全部イケてないわけじゃないんだ。2015年で言うとMakefilesを使っていたけど、今じゃWebpackで全部包んでるね。

Makefiles? I thought that was mostly used on C or C++ projects.

Makefile？それって主にCやC++のプロジェクトで使用されていたと思ってたよ。

-Yeah, but apparently in the web we love making things complicated and then going back to the basics. We do that every year or so, just wait for it, we are going to do assembly in the web in a year or two.

そうだね、だけど、どうやらウェブ業界のエンジニアは物事を複雑化してから基礎に立ち返ることが大好きなんだ。毎年そんな感じだよ。見てなよ、1、2年もすればWebでアセンブラが動くようになってるから。

Sigh. You mentioned something called Webpack?

はぁ。あとさっき君が言ってたWebpackって何?

-It’s another module manager for the browser while being kind of a task runner as well. It’s like a better version of Browserify.

Webpackはブラウザの為のモジュールマネージャーでありながら、タスクランナーの一種として動いているんだ。まるでBrowserifyの改良版のようにね。

Oh, Ok. Why is it better?

へぇ、そうなんだ。なぜ改良なの?。

-Well, maybe not better, it’s just more opinionated on how your dependencies should be tied. Webpack allows you to use different module managers, and not only CommonJS ones, so for instance native ES6 supported modules.

ええと、改良されたって言うのは違うかも、今のは単純に依存関係をどうまとめるべきかに対する多数派の意見だね。WebpackはCommonJSだけじゃなく、Native ES6のインスタンスがサポートしているモジュールも使えるように、異なるモジュールマネージャーを使う事ができるんだ。

_I’m extremely confused by this whole CommonJS/ES6 thing.

そのCommonJS/ES6全体の話でわけがわからなくなってるよ。

-Everyone is, but you shouldn’t care anymore with SystemJS.

みんなそんなもんだよ。でも。SystemJSについてはもう気にしなくていいよ

Jesus christ, another noun-js. Ok, and what is this SystemJS?

なんてこった冗談だろ、また別のjsだ。おーけ、それでSystemJSって？

-Well, unlike Browserify and Webpack 1.x, SystemJS is a dynamic module loader that allows you to tie multiple modules in multiple files instead of bundling them in one big file.

BrowserifyとWebpack1.xの時とは異なり、SystemJSは、1つの大きなファイルとして束ねるのではなく、複数のファイルに複数のモジュールを使う事で結合することが可能な動的モジュールローダーなんだ。

-Wait, but I thought we wanted to build our libraries in one big file and load that!

まって、一つの大きなファイルにまとめてロードさせたかったんじゃないのかよ！。

-Yes, but because HTTP/2 is coming now multiple HTTP requests are actually better.

確かにね、でももう間近に迫っているHTTP/2は復数のHTTPリクエストに対応できるし、ぶっちゃけそっちの方が良いんだ。

Wait, so can’t we just add the three original libraries for React?

まってくれ、Reactを使う為に3つライブラリを単純に追加する事すらできないのかい?。

-Not really. I mean, you could add them as external scripts from a CDN, but you would still need to include Babel then.

そうでもないよ。やるとしたら、君はCDNから外部スクリプトとして追加することで可能だ。けれど、その後にやっぱりBabelが必要となるだろうね。

Sigh. And that is bad right?

またかよ。それで、そいつも問題があるんだろ?

-Yes, you would be including the entire babel-core, and it wouldn’t be efficient for production. On production you need to perform a series of pre-tasks to get your project ready that make the ritual to summon Satan look like a boiled eggs recipe. You need to minify assets, uglify them, inline css above the fold, defer scripts, as well as-

そうだね、babel-coreを全体に導入する事になるだろうし、同時に本番環境の効率も悪くなるだろうね。プロダクション上ではゆで卵を作る如く簡単に悪魔召喚を行った上でプロジェクトを準備する前に一連のタスクを実行する必要があるんだ。minidy assetsは必要だし、酷くなっていて、inline cssは倍になって、スクリプトは遅くなるし、同様に...

I got it, I got it. So if you wouldn’t include the libraries directly in a CDN, how would you do it?

もういい、もういいよ。CDNを使って直接ライブラリを含めることができないなら、どうすればいいのさ？。

I would transpile it from Typescript using a Webpack + SystemJS + Babel combo.

僕ならTypescriptを使ってWebpack + SystemJS + Babelの組み合わせでトランスパイルするかなぁ。

Typescript? I thought we were coding in JavaScript!

TypeScriptだ? JacaScriptでコーディングするんじゃないのかよ！

Typescript IS JavaScript, or better put, a superset of JavaScript, more specifically JavaScript on version ES6. You know, that sixth version we talked about before?

TypeScriptはJavaScriptだよ、って言うかJavaScriptの上位セットで、ES6のJavaScriptをより具現化した言語だよ。前にES6について話をした事を覚えてるだろう？

I thought ES2016+ was already a superset of ES6! WHY we need now this thing called Typescript?

ES2016+が既にES6の上位セットだと思ってたよ！なんで今になってTypeScriptと呼ばれるものが必要になるんだ？。

Oh, because it allows us to use JavaScript as a typed language, and reduce run-time errors. It’s 2016, you should be adding some types to your JavaScript code.

あぁ、なぜならTypeScriptのおかげで型付き言語としてJavaScriptを使用できて、実行時エラーを低減させたんだ。2016年だよ、君もJavaScriptに型を導入すべきだよ。

And Typescript obviously does that.

Typscriptが全部やるんだな

-Flow as well, although it only checks for typing while Typescript is a superset of JavaScript which needs to be compiled.

Flowも同様だけど、Flowは型をチェックするだけの一方でTypeScriptはコンパイルを必要とするJavaScriptのスーパセットだからね。

Sigh… and Flow is?

はぁ..Flowって?

-It’s a static type checker made by some guys at Facebook. They coded it in OCaml, because functional programming is awesome.

FlowはFacebookのエンジニアが作った静的型チェッカーだよ。関数型プログラミングが素晴らしいから彼らはOCamlでFlowを書いたんだ。

OCaml? Functional programming?

OCaml? 関数型プログラミング?。

It’s what the cool kids use nowadays man, you know, 2016? Functional programming? High order functions? Currying? Pure functions?

イケてるエンジニアはみんなやってるよ、だって今は2016年だよ? 関数型プログラミングもあるよ?高階関数だぜ?カリー化だぜ?純粋関数だぜ?

I have no idea what you just said.

何いってんだお前。

-No one does at the beginning. Look, you just need to know that functional programming is better than OOP and that’s what we should be using in 2016.

初心者はみんなそんなもんだよ。なぁ、君は関数型プログラミングがOOPよりも優れていることを知っておく必要があるし、それを2016年では使うべきなんだよ。

Wait, I learned OOP in college, I thought that was good?

待って、OOPは大学で学んだよ。あれはいいよね？。

-So was Java before being bought by Oracle. I mean, OOP was good back in the days, and it still has its uses today, but now everyone is realising modifying states is equivalent to kicking babies, so now everyone is moving to immutable objects and functional programming. Haskell guys had been calling it for years, -and don’t get me started with the Elm guys- but luckily in the web now we have libraries like Ramda that allow us to use functional programming in plain JavaScript.

JavaがOracleに買収される前まではね。僕が言いたいのは、OOPは良くなったし今日でも未だ現役で使われている、だけど今じゃ誰もがオブジェクトの中の状態遷移がサッパリわからない事に気がついている、それで皆イミュータブルなオブジェクトや関数型プログラミングに移行しているんだよ。Haskell使いはその事を何年も言ってたし、 -Elm使いの事は言わせないでくれ- 今じゃ幸運な事にwebではRamdaみたいなJavaScriptで関数型プログラミングが書けるライブラリが用意されているんだ。

Are you just dropping names for the sake of it? What the hell is Ramnda?

それを言うためだけにわざわざ色々言及してるのかい？ Ramndaが何だって?。

-No. Ramda. Like Lambda. You know, that David Chambers’ library?

Ramdaだよ。Lambdaのようにね。David Chambers氏のライブラリは知っているだろう?。

David who?

Davidって誰?。

-David Chambers. Cool guy. Plays a mean Coup game. One of the contributors for Ramda. You should also check Erik Meijer if you are serious about learning functional programming.

David Chambers氏はイケてる人で、意地悪なCoup（っていう）ゲームで遊んでいる人で、Ramdaに貢献してる一人だ。君が関数型プログラミングを真剣に考えているなら、Erik Meijer氏もチェックした方がいいね。

And Erik Meijer is…?

Erik Meijerって..?

-Functional programming guy as well. Awesome guy. He has a bunch of presentations where he trashes Agile while using this weird coloured shirt. You should also check some of the stuff from Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani-

同じように関数型プログラミング使いだよ。やばい人なんだ。アジャイル開発を非難したプレゼンテーションの場では彼、奇妙なシャツ着てたんだ。同様にチェックすべき人物がいてTjや、Jash Kenas, Sindre Sorhus, Paul Irish,それにAddy Osmani...

Ok. I’m going to stop you there. All that is good and fine, but I think all that is just so complicated and unnecessary for just fetching data and displaying it. I’m pretty sure I don’t need to know these people or learn all those things to create a table with dynamic data. Let’s get back to React. How can I fetch the data from the server with React?

わかった。もうやめてくれ。十分満足だ。でも、データを引っぱてきてそれを表示するだけなら今のは非常に複雑で必要ないと思うんだ。これを実行するだけなら、その人達を知る必要もないし、データを直接出力するテーブルの作り方学ぶ必要もない事を確信したよ。Reactに戻ろう。さぁどうやってサーバ上でReactを使ってデータを引っぱてくるんだ?

-Well, you actually don’t fetch the data with React, you just display the data with React.

あぁ、実際の所君はReactを使ってデータを引っ張れない、Reactはデータを表示するだけなんだ。

Oh, damn me. So what do you use to fetch the data?

あぁくそが。それで、何を使ってデータを引っ張ってくるんだい?

-You use Fetch to fetch the data from the server.

Fetchを使ってサーバからデータをfetchするんだ。

i’m sorry? You use Fetch to fetch the data? Whoever is naming those things needs a thesaurus.

なんだって?Fetchを使ってfetchするって？そこらへんの名前つけてる奴は類語辞典使った方がいいよマジで。

-I know right? Fetch it’s the name of the native implementation for performing XMLHttpRequests against a server.

わかるだろ?Fetchはサーバーに対してのXMLHttpRequestsを実行するためのネイティブ実装の名前だよ。

Oh, so AJAX.

あー、AJAXね。

AJAX is just the use of XMLHttpRequests. But sure. Fetch allows you to do AJAX based in promises, which then you can resolve to avoid the callback hell.

AJAXはXMLHttpRequestsの用途の一つに過ぎないよ。でももちろん、(AJAXでも)できるさ。FecthはAJAXのPromisesが基になって利用できて、コールバック地獄を解消してくれるんだ。

Callback hell?

コールバック地獄？

-Yeah. Every time you perform an asynchronous request against the server, you need to wait for its response, which then makes you to add a function within a function, which is called the callback pyramid from hell.

そう、君はサーバに対してasynchronous requesを毎回実行する度に、応答をまたなきゃいけないし、関数内に関数を追加するから、コールバック地獄からコールバックピラミッドって呼ばれてるんだ。

Oh, Ok. And this promise thing solves it?

へ～なるほど。それはpromiseで解消されたの?

-Indeed. By manipulating your callbacks through promises, you can write easier to understand code, mock and test them, as well as perform simultaneous requests at once and wait until all of them are loaded.

いかにも。promisesを通してのコールバックの操作は、コードやモック、テストを理解しやすく書くことができるし、同様に一度で復数のリクエストを同時実行させて、全てがロードし終わるまで待つ事が出来るんだ。

And that can be done with Fetch?

それをFetchがやってくれるのかい?。

-Yes, but only if your user uses an evergreen browser, otherwise you need to include a Fetch polyfill or use Request, Bluebird or Axios.

そうだね、だけどユーザが標準ブラウザを使っているなら、Fetch polyfil、もしくは Requestや、Bluebird、Axiosが必要になってくるね。

How many libraries do I need to know for god’s sake? How many are of them?

これを上手く実行する為だけにどんだけのライブラリを知らないといけない?どんだけだよ?。

-It’s JavaScript. There has to be thousands of libraries that all do the same thing. We know libraries, in fact, we have the best libraries. Our libraries are huuuge, and sometimes we include pictures of Guy Fieri in them.

これこそがJavaScriptだ。同じ事を行うライブラリが何千もある。事実、僕らが知っているライブラリは、最高のライブラリでもあるんだ。ライブラリはデカすぎて、たまにGuy Fieriの写真なんかも交じってるね。

Did you just say Guy Fieri? Let’s get this over with. What these Bluebird, Request, Axios libraries do?

Guy Fieriって言ったか?片付けよう。Bluebird、Request、Axiosライブラリは何をしてくれるんだい?。

-They are libraries to perform XMLHttpRequests that return promises.

これらのライブラリはXMLHttpRequestsのpromisesを実行する為にあるんだ。

Didn’t jQuery’s AJAX method start to return promises as well?

jQueryのAJAXメソッドも同じようにpromisesを返してくれるんじゃなかったけ?

-We don’t use the “J” word in 2016 anymore. Just use Fetch, and polyfill it when it’s not in a browser or use Bluebird, Request or Axios instead. Then manage the promise with await within an async function and boom, you have proper control flow.

その"J"って言うのは2016年では使わないんだよ。Fetchを使って、ブラウザが適応してなかったら代わりに Bluebird, Request or Axios を使うんだ。そして、async functionnやboom内のawaitと一緒にpromiseで管理する事で君は適切なフローを制御できるよ

It’s the third time you mention await but I have no idea what it is.

そのawaitっていうの君が言及するのは3回目だけど、何を言っているのかわからないよ。

-Await allows you to block an asynchronous call, allowing you to have better control on when the data is being fetch and overall increasing code readability. It’s awesome, you just need to make sure you add the stage-3 preset in Babel, or use syntax-async-functions and transform-async-to-generator plugin.

Awaitはsynchronous呼び出しブロックを可能にして、データを取ってくる際に制御しやすくし、可読性のあるコードを全体的に増やしてくれるんだ。凄いよ、君はBabelのstage-3 presetを追加するか、syntax-async-functionsやtransform-async-to-generator pluginを使えばいいんだ。

This is insane.

正気じゃないな。

-No, insane is the fact you need to precompile Typescript code and then transpile it with Babel to use await.

いや、正気じゃないってのは、awaitを使おうとするとTypeScriptを再コンパイルして、Babelでトランスパイラする必要がある事実だよ。

Wat? It’s not included in Typescript?

何? TypeScriptは含んでないだろ?

-It does in the next version, but as of version 1.7 it only targets ES6, so if you want to use await in the browser, first you need to compile your Typescript code targeting ES6 and then Babel that shit up to target ES5.

次のバージョンではね、でもバージョン1.7はES6だけをターゲットにしている、だから君がブラウザでawaitを使いたかったら、最初にTypeScriptをES6向けにコンパイルして、BableでES5向けに吐き出せばいいんだ。

At this point I don’t know what to say.

この時点で何を言ってるのかわからないよ

-Look, it’s easy. Code everything in Typescript. All modules that use Fetch compile them to target ES6, transpile them with Babel on a stage-3 preset, and load them with SystemJS. If you don’t have Fetch, polyfill it, or use Bluebird, Request or Axios, and handle all your promises with await.

なぁ、簡単だよ。全てTypeScriptで書くんだ。多くのモジュールはES6向けにFetchコンパイルを使っていて、Babel on a stage-3 presetでトランスパイラして、そしてSystemJSで読み込むんだ。もしFetchがなければ、polyfillかBluebirdやRequest 、Axiosを使い、それからawaitと一緒にpromisesで処理するんだ。

We have very different definitions of easy. So, with that ritual I finally fetched the data and now I can display it with React right?

僕達の簡単という定義は多く違うみたいだね。それで、その儀式とやらでやっとデータを引っぱてきて、Reactで表示するんだろ?

-Is your application going to handle any state changes?

君のアプリは何か状態遷移を扱うのかい?。

Err, I don’t think so. I just need to display the data.

あぁー、そうじゃないんだ。只、データを表示したいだけなんだよ。

-Oh, thank god. Otherwise I would had to explain you Flux, and implementations like Flummox, Alt, Fluxible. Although to be honest you should be using Redux.

あ、そうだね。そうでなければ、僕は君にFluxを説明してただろうし、 Flummoxや、Alt、Fluxibleを実装するだろうね。でも正直に言うと Reduxを使うべきだよ。

I’m going to just fly over those names. Again, I just need to display data.

もうその名前はどうでもいいや。もう一度言おうか、データを表示したいだけだ。

-Oh, if you are just displaying the data you didn’t need React to begin with. You would had been fine with a templating engine.

あ、データを表示するだけならReactを始める必要はないんだ。テンプレートエンジンで上手くいくだろうね。

Are you kidding me? Do you think this is funny? Is that how you treat your loved ones?

馬鹿にしてるのか？これのどこが面白いと思うんだ?こんな感じに家族とかにも対応するのか？

-I was just explaining what you could use.

君が使えるようにと、説明してるだけさ。

Stop. Just stop.

もういい、やめてくれ

-I mean, even if it’s just using templating engine, I would still use a Typescript + SystemJS + Babel combo if I were you.

僕が言いたいのは、たとえテンプレートエンジンを使うとしてもTypeScript+SystemJS+Babelを使うだろうね、僕が君だとしても。

I need to display data on a page, not perform Sub Zero’s original MK fatality. Just tell me what templating engine to use and I’ll take it from there.

俺はページにデータを表示したいだけだ、Sub Zero’のMK(モータルコンバット) fatalityみたいな事はしないんだよ。単純にテンプレートエンジンの使い方とその先からの事を教えてくれ。

-There’s a lot, which one you are familiar with?

たくさんあるし、どれを知りたい?。

Ugh, can’t remember the name. It was a long time ago.

うわっ、もう名前は覚えれないって。とっくの昔に。

-jTemplates? jQote? PURE?

jTemplates? jQote? PURE?。

Err, doesn’t ring a bell. Another one?

あぁー、心当たりないな。他は。

-Transparency? JSRender? MarkupJS? KnockoutJS? That one had two-way binding.

Transparency? JSRender? MarkupJS? KnockoutJS? これは双方向バインディングを持ってるね。

Another one?

他は?。

PlatesJS? jQuery-tmpl? Handlebars? Some people still use it.

PlatesJS?jQuery-tmpl? Handlebarsかな?何人かは未だに使っているよ。

Maybe. Are there similar to that last one?

かもね。最期のやつと似ているのは?

Mustache, underscore? I think now even lodash has one to be honest, but those are kind of 2014.

Mustacheやunderscoreとか?正直、今ならlodashが一番だと思うけど、大体2014年のものだね。

Err.. maybe it was newer.

あぁー...ことによると新しいかもね。

Jade? DustJS?

Jade? DustJS?

No.

違う。

DotJS? EJS?

-DotJS? EJS?

No.

それも違う。

-Nunjucks? ECT?

Nunjucks? ECT

No.

ノー

-Mah, no one likes Coffeescrip syntax anyway. Jade?

まぁ、誰もがCoffeescriptのシンタックスが好きではないからね。 Jade?

No, you already said Jade.

違うし、Jadeはさっき言った。

-I meant Pug. I meant Jade. I mean, Jade is now Pug.

Pugって意味だよ。昔はJadeだった。今ではJadeはPugって意味なんだ。

Sigh. No. Can’t remember. Which one would you use?

はぁ。もういい。覚えられない。どれを使えばいいんだ?。

-Probably just ES6 native template strings.

恐らく、元々のES6テンプレートかな。

Let me guess. And that requires ES6.

当ててやろうか。それはES6が必要だ。

-Correct.

その通り。

Which, depending on what browser I’m using needs Babel.

そして、ブラウザに依存する為、Babaleを使う必要がある。

-Correct.

その通り。

Which, if I want to include without adding the entire core library, I need to load it as a module from npm.

そして、全体のコアライブラリーを追加せずに含めたい場合は、npmからモジュールを読み込んでくる必要がある。

-Correct.

その通り。

Which, requires Browserify, or Wepback, or most likely that other thing called SystemJS.

そして、Browserify、やWebback、或いは同様にSystemJSと呼ばれる物が必要となる。

-Correct.

その通り。

Which, unless it’s Webpack, ideally should be managed by a task runner.

そして、Webpackでないかぎり、理想的にタスクランナーで管理されるべきである。

-Correct.

その通り。

But, since I should be using functional programming and typed languages I first need to pre-compile Typescript or add this Flow thingy.

しかし、関数型プログラミングや型付き言語を使うならば、最初にTypeScriptを再コンパイルするか、Flowを追加する必要がある。

-Correct.

その通り。

And then send that to Babel if I want to use await.

そして、awaitを使いたい場合はBabelで送る。

-Correct.

合ってるね。

So I can then use Fetch, promises, and control flow and all that magic.

これで、Fetch、promisesを使ってフローを制御して全ての魔法を使う事が出来る。

-Just don’t forget to polyfill Fetch if it’s not supported, Safari still can’t handle it.

只、もしSafariなどまだ対応していない場合はFetch polyfillを使うという事を忘れないでくれ。

You know what. I think we are done here. Actually, I think I’m done. I’m done with the web, I’m done with JavaScript altogether.

なぁ。もうこれで終わりだと思うんだ。実際のところもう十分だ。webも十分だし、JavaScriptもまったくもって十分、もういい。

-That’s fine, in a few years we all are going to be coding in Elm or WebAssembly.

それは良かった、数年の間にELMかWebAssemblyで全てコーディングする事になるよ。

I’m just going to move back to the backend. I just can’t handle these many changes and versions and editions and compilers and transpilers. The JavaScript community is insane if it thinks anyone can keep up with this.

俺はバックエンドに戻る事にするよ。こんな多くのバージョンやedition、コンパイル、トランスパイラの変更に対応できない。その事に誰もがついていけると思っているのなら、JavaScriptコミュニティはどうかしているね。

-I hear you. You should try the Python community then.

わかるよ。そしたら君はPythonコミュニティを覗いてみるべきだね。

Why?

なぜ?。

-Ever heard of Python 3?

Python3を聞いた事はあるかい?。

終わりに

原文を読めばわかるとおりこの文章はジョークです。従って私もその気持で楽しく翻訳しましたが、原文は長年JavaScriptを触ってきたエンジニアしかわからない専門用語やスラングが沢山あり、その意味を解釈するのに大変困惑しました。なので、一時的に私はさも「JavaScriptを書けるイケてるエンジニア」を装う必要があった為、多くの参考文と資料を頭にぶちこみましがそれは余りに無謀で馬鹿げた事であり、全部が全部翻訳しきれなかった可能性があります。

従って、もし「おい、なんだこの意味は！全然違うじゃねーか！」っという点があれば、遠慮なくコメント欄やブコメでもいいのでまさかりを投げて頂ければ、すぐに修正致します。

この文章を翻訳してる際に私は「フロントエンドの世界は改めて日々改良が加えられ、最先端にいるんだな」と思った同時にThe Little Printf : 「我々はなぜプログラミングをするのか？」を追う寓話の以下の台詞が頭から離れませんでした。

「いいえ、そういう意味じゃなくて、」Little printfは言葉をさしはさみ、こう続けました。「 僕たちにとってツールは問題を解決するためのものなのに、あなたからしたらツール自体が問題になっているのが面白いと思ったんです。」その男は無言で（新しくてかっこいい仕事机に）立ちつくし、その間にlittle printfは部屋からひょいと飛び出ました。

誤解を招きそうなので説明をしますと、私は今のJavaScriptについてネガティブな意見を伝える為にこの文章を翻訳しておりません。たまたまHacker Newsを見てたら「おや？この英文は何か面白そうだぞ..!!」っという只の勢いで翻訳しましたし、従ってJavaScriptのDOMと初代ガンダムのドムの違いすらわかってなかった私は本当にこの記事と同じようにどうしようもなく困惑し、つらい経験をしました。

https://twitter.com/endo_f181/status/787272224600236032?lang=ja

ですが、この様な視点から少しでもJS 界隈における歴史と技術を理解できた事はエンジニアを志す者として大変勉強になり、いいきっかけになった事に改めて感謝しています。 : -)

尚、私は暫くサーバサイドに引きこもるつもりでいますが、「JavaScriptなら俺に任せろー」な人はこの文章に対する別の視点から解釈した記事があるのでそちらも良ければ見て下さい。

おわり

Fendo181/2016年にJavaScriptを学んでどう感じたか.md

2016年にJavaScriptを学んでどう感じたか

終わりに

参考資料

Fendo181 commented Nov 23, 2016