14
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

JSXAdvent Calendar 2013

Day 22

「Haxerから見たJSX」という感想文を書いてみた。

Last updated at Posted at 2013-12-23

HaxeからJSXをスパイ活動してきました@nobkzです

Haxerから見たJSXについて。

そもそもなぜHaxerなのにJSXのAdvent Calendarに参加したか?

12月7にきしださんが主催していたイベントに参加したときのことでした。言語パフォーマンスについてのイベントで、いろいろと勉強になったのですが、それで、JSXの人(@kazuhoさん )が来ていました。普段AltJSとして、CoffeeScriptや、Haxe(AltJS以外でもですが。)、TypeScriptなどは書いたことがありましが、JSXは一番疎いところであり、また、「JSXは速い」って散々言われてそれに疑問を抱いていたので、丁度良い機会でした。

それで、いろいろとJSXの高速化の話しを聞き、なるほど納得して、じゃあ家に帰って実際にJSXでコードを書いてみようと思いました。んで何を思ったか、 「せっかくだしJSXあんまり書いたことないけどJSX Advent Calendar参加しよう。たぶん、Haxeから視点で互いに刺激になるから面白いだろう!] と思いました。そして、「まぁ22日あたりぐらいに設定していれば、その間にJSXスパイ活動できるだろう!」と思いました。

JSXやっぱり、確かに速いなーと思った。

んで、ちょっとしたJSXでシューティングゲームを作ってみました。いや、というより、Haxeで書いていたものをJSXで書きかえました。

JSXはやっぱり速い 気がした。ベンチマークとかやってないけど。ただゲームの規模が小さいのか、体感で早い気がしました。実際にコンパイルされたコードを除くと、いろいろと最適化が図られて良いと思いました。

JSXの最適化は伊達じゃなかった

JSXとHaxeの静的型の考えかたの違い

JSXの静的型はなんというか、 速度と安心感のための静的型付け と感じました。静的片付けにおける型安全はもちろんですが 型情報を元に最適化を計っている ように思いました。事実そういう面はあると思います。その一方 静的型付けによる煩わしさ は残ってしまいました。それは、型指定の煩わしさ、多態の実現のための煩わしさが残ってしまいました。

一方 Haxeは、 安心と生産性向上のための静的型付け だと思いました。JSX並に型情報を元にした最適化をコンパイラがしてくれるわけではありませんが、Haxeには型推論や匿名型、構造的部分型付けなどの、静的型の煩わしさを開放してくれる機能がたくさんあります 更には、Haxeは 型推論から得た型情報を元にコード補完機能までコンパイラについている始末 です!

ただ、どちらも型安全は守られるので、ある程度の品質は保証されているという点でどちらもそこは共通しているとは思います。

言語機能はやっぱりHaxeだとおもった。

JSXはすごく新しい言語で、Haxeは出てきて以外と長い(2005年ぐらいに登場した)ので、言語機能面ではやっぱりHaxeは強いですね。Haxerとしてやっぱり、JSXの言語機能としてほしいと思ったのが、

  • やっぱり強力な型推論
  • (Haxeの代数的データ構造をとれる) enum
  • パターンマッチ

やっぱり、型推論があるかないかが一番大きいと思います。enumやらパターンマッチはその次に欲しいですね。やっぱり、直和型を作りたいですから!

JSで書かれてたライブラリのバインドするときのつらぽよ

HaxeやJSXの違いではなく、共通することですが。

HaxeもJSXもクラスベースのオブジェクト指向言語であり、JS はプロトタイプベースのオブジェクト指向言語ですが、そのJSとの言語間の差が生み出す苦しみはHaxe、JSXどちらもあります。それは、JSのライブラリをバインドするときで、そこでちょっと困惑するときがあります。

JSが何らかのクラスを意識したライブラリであるならば、バインドは書きやすいのですが、そうじゃないライブラリの場合、なんらかのクラスを再設計しないといけない場合が多くそれはとてもつらぽよなのです。HaxeなどはJSのコードを埋めこんだり、Dynamic型があるけれどもそれだと型の安全が保証されなくなってしまいます。(あとDynamic型だとコードの補完がされないので不安になるってこともありますw)

また、使う側も、元のライブラリと同じ様に使用できれば良いのですが、設計が変っているので、そこの対応付けの手間がかかりつらぽよなのです。

JQueryなんかは、HaxeもJSXどっちもつらぽよなので、あんまり使用をお勧めしません。ただ、HaxeではDom自体が型を持ってたり、Ajaxがやりやすいライブラリなど、JQueryの機能でやりたいことの変わりに使えるライブラリが沢山あるので、それを利用することでなんとかなっています。JSXもDom操作のしやすい機能かライブラリをつけるとまた良いのかなとか思ったりします。

まあぶっちゃけ TypeScriptを使え って誰かが言いそうですが。

サーバーサイドとクライアントサイドJSについて。

ずっと僕は、web開発における、Haxeマインドについて、node.jsとの何処かの共通性を感じていました。それは、サーバーサイドと、クライアントサイドで、 共通するデータ構造を一つのソース で管理できるということです。

もちろん、サーバーサイド、クライアントサイド、(Haxeにおいてはコンパイルする言語環境)によって依存コードが出るのは当たり前です。ですが、 共通するデータ構造を一つのソースを異なる環境で利用できるというメリットはどちらも享受できます。 HaxeではJS以外にも、PHP,neko、C#、Javaなど様々な環境に掃き出せるので、その傾向が強いです。それで、環境依存コードはその環境で、継承やらmixinなどでクラスに機能追加してしまえばいいのです。

僕が最近Haxeで書く理由はそういうことで、サーバーサイドとクライアントサイドで異なる言語でかかれたリソースは一つの言語で書き、サーバーサイドとクライアントサイドで異なる言語でかかれたある意味コードの重複をひとるにしようということです。

nodejsはそいういうことを実現できます。ですが、JSは大規模開発に向かないと思います。JSだけで本格的に、webアプリケーションを作るのは大変だと思います。僕が一番JSXに期待しているのは、実はサーバーサイドJSの方です。今後なにかの機会に、JSXでサーバーサイドもクライアントサイドで最適化が書けられたJSを吐きだし、webアプリケーションを作成してJSXを試してみたいとおもいます。

あと思ったこと

  • 日本でつくられたのに、なんでドキュメントが英語なの?(英語キライwww)
  • エディタは結局なんか良いのないの?
  • JSXの"X"ってなんなの?

最後に

おそくなってすいませんですたーーーーーーーー!!!!

14
14
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?