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フレームワークのように、真剣に語れるべきではありません。JacaScriptフレームワークなんて、この記事が書かている時にはありませんでした。
「It’s the future」の素晴らしい翻訳記事もあるので是非、こちらも参考にして下さい。
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に帰ってきてwepアプリが最先端だってわかったんだ。
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のエンドポイントからデータを取得して、ソート可能なテーブルで表示させた後に、もしサーバー上で変更された場合は更新するってやつなんだけど、恐らくjQueyを使ってデータを引っ張ってきて、出力すればいいのかな?
-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?
あ、そうなんだ。所でRactって?
-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の略称だよ。このeditionはほとんどの人に受け入られて、今日では多くのブラウザに実装されているよ。
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を使用することができるけど、非同期通信のようなクールな機能使うなら、ES2016+を使用する必要があるね。 (わからない...) そうしないと、ES6 generatorsの非同期通信呼び出しによるコルーチン処理で右往左往してしまうからね。
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.
そうか。だったらその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?
nmpレジストリ..?
-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?
ああ、そうなんだ...、そしたら、nmpからライブラリをダウンロードする必要があるのかな?
-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を使うにはnmpを引っ張ってきて、その後に 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年でウェブにアセンブりを導入できるように動いているよ。
Sigh. You mentioned something called Webpack?
はぁ。 Webpacに関して君は言及しないの?
-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!
まって、それだったら1つの大きなファイルでまとめてからロードした方がいいと思ったよ。
-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を全体に導入する事になるだろうし、同時に生産性の効率も悪くなるだろうね。プロダクション上ではゆで卵のレシピの如く簡単に悪魔(Babel)召喚を行った上でプロジェクトを準備する前に一連のタスクを実行する必要があるんだ。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.
-初心者はみんなそんなもんだよ。なぁ、君は関数型プログラミングがOPP(オブジェクト指向言語)よりも優れていることを知っておく必要があるし、それを2016年では使うべきなんだよ。
Wait, I learned OOP in college, I thought that was good?
待って、OPPは大学で学んだよ。あれはいいよね？
-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 gameって意味でね。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.
-サーバからデータを引っ張っぱるのを引っ張ってくるんだ。
i’m sorry? You use Fetch to fetch the data? Whoever is naming those things needs a thesaurus.
なんだって?データを引っ張っるのを引っ張ってくるって ? そんな言葉、誰が辞書に登録させたんだ?
-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をそのまま使用する。当然だけど。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.
-そう、君はサーバに対して毎回非同期通信を実行する度に、応答をまたなきゃいけないし、関数内に関数を追加するから、コールバック地獄からピラミッドって呼ばれてるんだ。
Oh, Ok. And this promise thing solves it?
あ～なるほど、で、それは解消されたの?
-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.
-そうだね、だけどユーザがブラウザににIEを使っているなら、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 を使うんだ。
It’s the third time you mention await but I have no idea what it is.
君がその台詞をいうのは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は-非同期通信呼び出しブロックを可能にして、データを取ってくる際に制御しやすくして可読性のあるコードを全体的に増やしてくれるんだ。凄いよ、君は只、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? これは双方向バインディング(two-way-binding)を持ってるね。
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,やWepback、或いは同様に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.
そして、awaiを使いたい場合はBabelで送る。
-Correct.
-合ってるね。
So I can then use Fetch, promises, and control flow and all that magic.
それで、Fetch,promisesや、flowを制御しや全ての魔法を使う事が出来る。
-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.
-That’s fine, in a few years we all are going to be coding in Elm or 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.
-I hear you. You should try the Python community then.
Why?
-Ever heard of Python 3?
原文を読めばわかるとおりこの文章はジョークです。 従って私もその気持で楽しく翻訳しましたが、原文は長年JavaScriptを触ってきたエンジニアしかわからない専門用語やスラングが沢山あり、その意味を解釈するのに大変困惑しました。なので、一時的に私はさも「JavaScriptを書けるイケてるエンジニア」を装う必要があった為、多くの参考文と資料を頭にぶちこみましがそれは余りに無謀で馬鹿げた事であり、全部が全部翻訳しきれなかった可能性があります。
従って、もし「おい、なんだこの意味は！全然違うじゃねーか！」っという点があれば、遠慮なくコメント欄やブコメでもいいのでまさかりを投げて頂ければ、すぐに修正致します。
この文章を翻訳してる際に私は「フロントエンドの世界は改めて日々改良が加えられ、最先端にいるんだな」と思った同時にThe Little Printf : 「我々はなぜプログラミングをするのか？」を追う寓話の以下の台詞が頭から離れませんでした。
「いいえ、そういう意味じゃなくて、」Little printfは言葉をさしはさみ、こう続けました。「 僕たちにとってツールは問題を解決するためのものなのに、あなたからしたらツール自体が問題になっているのが面白いと思ったんです。」 その男は無言で（新しくてかっこいい仕事机に）立ちつくし、その間にlittle printfは部屋からひょいと飛び出ました。
誤解を招きそうなので説明をしますと、私は今のJavaScriptについてネガティブな意見を伝える為にこの文章を翻訳しておりません。たまたまHacker Newsを見てたら「おや？この英文は何か面白そうだぞ..!!」っという只の勢いで翻訳しましたし、従ってJavaScriptのJの意味すらわかってなかった自分は本当にこの記事と同じようにどうしようもなく困惑し、つらい体験を経験しました。従って、正直後悔はしています。
[https://twitter.com/endo_f181/status/787272224600236032?lang=ja:embed]
ですが、この様な視点から少しでもJS 界隈における歴史と技術を理解できた事はエンジニアを志す者として大変勉強になり、いいきっかけになった事に改めて感謝しています。 : -)
尚、私は暫くサーバサイドに引きこもるつもりでいますが、「JavaScriptなら俺に任せろー」な人はこの文章に対する別の視点から解釈した記事があるのでそちらも良ければ見て下さい。
- Stop blaming on JavaScript when all you want is to talk about Front End
- JavaScript in 2016: How much scaffolding do you need?
おわり
[https://gist.github.com/Fendo181/ab86ec0cc7cd7a29b1903493eb021766:embed:cite]