最近のフロントエンドへの違和感

そういえば今日これらを読んでて

d.hatena.ne.jp

d.hatena.ne.jp

その中で

Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており...

はぁ? 「海外では当たり前()なんですねw 海外ってどこですか? タンザニア? パフアニューギニア? 」などみたいなリアクションを取りつつ、んで、まぁ、フロントエンドに関して、書きたかったことがあって、丁度良いので書いてみる。

というのも、フロントエンドが「凄く変化が早い」「ついていくのに大変」「新しい!!すごい」「これからは○○フレームワーク」だとかそんないろいろな意見が見られて、なんというか違和感を感じてるので今回はそれについて書く。

フロントエンドは変化が早い?

まずこれ。僕は普通に違和感を感じている。確かに、jsフレームワークやライブラリとしたら、jQueryから、Backbone、Knockout、Angular、Ember、Vue、React、Riotや、CSSではOOCSSとかBEMとかSMACSSとか、みたいなCSS設計、ツールとかだとnpmやYeoman、grunt, gulp, bower, browserify, webpackなどいろいろなものが出てきた。本当に一杯出てきた。

しかし、考えてみると、こういったツールが出てくることは「変化が早い」というものだろうか?

一体何が変化してるのだろうか? 「流行」? 「当たり前」? 僕には、「フロントエンド流行がすごく早く変化している」という論調が多い気がする。

どうして流行りに乗らないといけないの?

僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか?

フロントエンドの「最新の」フレームワークに採用したり、置き換えたりすることで、誰が喜ぶのだろうか? 同じアプリケーションでフレームワークを起き変えたって、ユーザは喜ばないだろう。だって、置き変えるだけなら、機能は変わらないのだから。フレームワークが「最新の」ものになっても、サービスが変わらなければユーザにとって意味は無い。

開発が喜ぶのだろうか? それはどうして? 設計が良くなる? 本当だろうか? ただ、あなたたちが流行り好きなだけじゃないのか?と勘ぐりたくなる。

そもそも、それ流行ってる?

たまによくある違和感としては、そもそも、「流行ってる」という出所がわりと、限定的であるということである。非常にコミュニティが狭くて、そのコミュニティに属していなかったら、「流行ってる、流行ってる」というのに説得力がないときが結構ある。

流行じゃないツールは「終わってる」のだろうか?

じゃあ、視点を変えてみよう。流行じゃないツールは「終わってる」のだろうか? そんなことは無いだろう。だって、jQueryだっていろんなところで使われているだろうし、Backbone.jsで書かれてたり、他のフレームワークやライブラリが、採用されているサービスは沢山あるだろう。そのサービスはすべて、「流行のフレームワーク」じゃないと、技術的に終わってる?今すぐ、「流行の」フレームワークに書きかえるべきだろうか?

そのフレームワークを使わないとあなたの欲しいものが作れないの?

SPAを作るみたいなとき、「React + Redux」が最近の流行みたいだから使ってみよう、みたいな感じフレームワークを選択するみたいだが、ちょっとまって欲しい。そのwebサービスは本当に「React + Redux」じゃないとダメなの? 過去に培ってきたフレームワークなどの知識でも、それはできないの? できるとしたら、それを選択する理由は何?

フロントエンドは抽象化できるほどなのだろうか?

フロントエンドと一言で言っても、いろいろあるだろう。 アプリケーションによって、フォームが一杯あってしかもそれが同期するUIかもしれないし、アニメーションがたくさんあるゲームのようなGUIだったり、画面がどんどん遷移してしまうGUIだったりするかもしれないし、画面にグラフを一杯つなげるみたいなUIかもしれないし、タッチパネルのジェスチャーをどんどんやらないといけないものかもしれない。

それらを全部まとめて、抽象化して、「フロントエンドGUI」の技術として標準化できるものだろうか? どのフロントエンドアプリケーションとして「当たり前」な技術になるほど、抽象化して語れるのだろうか?

というか、「新しい技術」を出てきても、問題が解決しないというか、問題領域が違って「そこじゃねぇだろ!」「そこ解決しなきゃ意味ねぇだろ」と思うときがけっこうあったりするのだ。

そもそも、新しくない。変化してない。

そもそも新しくなくて、変化してないなとか、思う時があって、「新しい」といって出てきた技術が実は全然あたらしくない。いや、これ昔からあったから! みたいな気分になることがある。もちろん、その時は、ちゃんと比較して調べるとかするが、それにしても騒ぎすぎな感になるときがある。

そもそも、フロントエンド開発は大変であって、やり辛いところは、どれを使っても一緒だ みたいなところはあるとは思うが、もし、そういった辛みが、なくなれば新しいんだろうなとか思ったり。

以上が僕の違和感の概観である。

最後に

こうすると、僕が「最新の」フレームワーク嫌いな人に思われるかもしれないが、そいういうことでは無い。ただ、少なくとも「これをつかうのが当たり前」とか、そういうったのが嫌いなのは確かであって、つまるところ、よりよく技術選択をして、開発したいだけである。

追記

ただ、新しいフレームワークが出てきたら勉強するというか、調べておくことはやっておくべきではあると思う。ドキュメント読んだり、サンプル読んだり、ちょっと動かしてみたりね。(僕にはフレームワークを「勉強」っていう感覚が無い。)

追記2

ちなみに、どうでもいいけど、僕もSPAを作っている人間なのですよ。

英語とプログラミング

あと、もう一本、エントリすることにする。

まぁ、この記事についてだが....

d.hatena.ne.jp

ちょっと、ツッコミながら、僕も言いたいことがあるので言うていく。

英語の学習時間を考えてない。

、やはり「英語を先に学んでからプログラミングを勉強した方が、圧倒的にプログラミングの学習効率が高い」という結論に至りました。

「プログラミングを学んでから英語を学習するよりも、英語を覚えてからプログラミングの勉強をした方が圧倒的に学習効率が良い」というが、このエントリ、全く英語の学習時間を考えてないように思える。

そもそも、その文系大学生ってTOEIC940点になるまで、どのぐらい勉強したの? という感じで、そもそも、英語を勉強していた方が、学習が早いからって、「英語を勉強していた方が学習効率が高い」とはいえんやろというか。それを言うのであれば、英語できない+プログラミングできないで、「英語->プログラミングの順番に覚える」と「プログラミング->英語の順番に覚える」ということをやるべき。

というか、英語覚えながらプログラミングやるやろ普通は。

英語関係なしに、「デキルやつがプログラミングやっただけ」

正直に言うと、思った以上に成長が早くないというか、「ふつうに、デキルやつがプログラミング覚えたらこうなるわな。」という感じである。

ぶっちゃけ、いやまぁ、悪いけど、この記事に出てくる文系大学生、僕からすれば...そんなにプログラミング覚えるの早くない気もする。ここについてはあんまり言わんで置こう。

それに、英語ができればプログラミングの学習効率が高いというけど、プログラミングとか技術ぜんぜんできねぇアメリカ人とかもいるし。おすし。

英語よりコード見りゃわかる。

とはいえば、「英語ができた方が良い」というのが確かである。しかし、僕としては「ドキュメントが英語ばかり」で困ることが実は僕はあまりない。

僕の英語力っていうたら、英語は読めるけど、読むスピードは結構遅い方だとは思う。しかし、英語が読むのが遲くても分からなくても、そのにコードが書いてある限り、分かる。理解できるのだ。

正直、英語ドキュメントよりもコードを読む。ひらすらに。というか「英語ですらドキュメントが無い」なんてことざらにあるし、そのときは、ひたすらコード読めば分かるのである。

More Source Code than English!

あと、英語のコメントが長すぎるソースコードは大嫌いですね。

とはいえ、英語はできた方が良い

しかし、とはいえ、英語はできた方が良いとは思いますけどね。