2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
竹馬光太郎氏:いろいろ言ってきたんですけど、どういうトレンドかと言うと、やっぱりハードウェアソフトウェアが発展することによってデータをたくさんメモリ上に置くようになる。プリミティブなイベントってどこに残ってるかよくわかんないから、それを全部フレームワーク側が全部メモリ上に乗せて管理するようになる。
またそのレンダラー、ブラウザのinnerHTML、append〇〇、そういうのはフレームワーク側に全部隠されて賢いレンダラーとして実装されていく。やっぱり最初は富豪的な設計をしたあとにマイクロチューニングをするっていうことを繰り返すという世界観だと思っています。
雑な図なんですけど、テンプレーティングって富豪的な設計だなと思うんですよ。データバインディングはテンプレーティングをパフォーマンスチューニングしたもので、それをやっていくとSingle Page Applicationみたいな1 Component Applicationみたいな概念が出てくる。
だけど、それも足りなくてrequestAnimationFrameでガリガリチューニングしていって、その上に仮想DOMみたいな概念が出てきて、今回は仮想DOMの説明は一切する気ないんですけど、そうやってエンドユーザーからはよくわからない複雑な実装に近づいていくみたいなイメージです。
あと言語自体も変化してきてて、よくある図なのかちょっとわからないですけど、昔ECMAScript3書いてて、4はポシャったので5の時代になって、ES201○の時代になって、Babelが出て、Flowが出て、TypeScriptが出てというのがJavaScript系の世界観です。
ほかの言語からトランスパイルしてくる系もまだそれなりに元気で、あとJavaScriptなんて絶対に書きたくないんだから、彼らは(笑)。
(会場笑)
ScalaJSやElm、最近ならReasonというocamlからコンパイルするやつが熱いんですけど、さらにWebAssembly系と一応銘打っていて、これはまだ存在していません。おそらくこれから発生するだろうというのがC++やRustからDOMのファインディングをうまいこと作ってあげて、そっちの言語の世界観だけで表現するWebアプリケーションフレームワークというのがたぶんこれから出てくると思います。
すでにいくつかあるんですけど、quasarだったかな? RustはWeb的にわりと熱いですね。WebAssemblyがきて。
JavaScriptはTC39で毎年進化する言語になりました。多言語からはトランスパイルしてくる。WebAssemblyはみんなでがんばろうねみたいな状態です。その前にAltJSはいろいろあったんですけど、文法追加や機能提案のために行っていった結果、ES201○に全部吸収されてほぼ死に絶えました。CoffeeScriptが現場に残ってるものが多いですけど。
そういう時代を経て仕様が追いつかないものはプリコンパイラで先取りするという文化ができて、Babelでコードを書いたりして最新機能を使うみたいな雰囲気ができた。
ただ最近盛り上がっている言語というのは何か。さっきの図ですね。
この図で生き残っているFlow、TypeScript、Scala、Elm、Reasonって全部型がある言語なんですよ。ただの型じゃなくて、柔軟な型宣言があるというのが大事で、型推論があること。とにかく型、型、型みたいな。
フロントエンドの事業で、なんでこんなに型が最近重要視されるようになったかと言うと、GUIでテストってとにかく書きづらいですよね。Reactはすごくがんばってサーバーサイドレンダリングでコンポーネントのスナップショット撮ってみたいなことやるんですけど、静的検査で済ませられるんだったらそれに越したことはない。
さっき言ったFluxやObservableは、けっこうデータ構造がImmutableなものを前提としていて、書き換えにシビアにならなきゃいけないという前提があって、そうなると静的検査がないと正直コードを書いていられない。Rxを使う人たちAngularの人たちがよく言うのは、TypeScriptがあるからRxが使えるみたいなことをよく聞きます。
(会場笑)
昔はこういう気持ちでコードを書いていましたよね(笑)。
(会場笑)
あります? 伝わると思うんですけど(笑)。手動テストでポチポチやってた時代。赤が危険な範囲です。「頼む、動いてくれ!」「たぶん動いてるやろ」みたいな感じで苦労してたのが……まあこうなってほしいよねという、これはわりと理想的な姿ですね。
(会場笑)
手動テストは支配的なんだけど、End to End、Unit Test、Static Type Analysisなど、でもここはやっぱり祈りですね。祈りが消えることは絶対にないので。JavaScriptに限らず。カバレッジ100パーセントを目指した世界に何があるかちょっとわからないですけど……あ、これさっきと同じこと言ってるわ。
今までFluxや型の話をしてきたんですけど、「じゃあWebComponentsが来たらフレームワークは死ぬのか」みたいな話があるじゃないですか。今はたぶんこうなっていると思うんですよ。
div.root、root要素があって、AppContainerをマウントして、ABC、Button、WidgetA、WidgetB、WidgetCで、Buttonの下にPrimitive Elementがある。というのが、たぶんこうなると思うんですよね。
root要素があって、AppContainerがあってABCがあるのは一緒なんだけど、nodeの末端がWebComponentsになっていく。状態管理層としてのフレームワークは残るんだけど、Viewの末端はCustom Elementsになると思っています。
ただし、そのパラダイムに適した新しいフレームワークも出てくるのは間違いなくて、最近WebComponentsファーストなフレームワークとしてSkateJSがあっておもしろいんですけど。まあReactを使えたら別にいいかなと思っちゃったんですけど(笑)。そういうものとかもあります。
「じゃあWebComponentsが来たら何が死ぬか?」ですが、〇〇デザイン、〇〇実装は全部死にます。マテリアルデザインのReact実装、ViewJSのマテリアルデザイン実装、〇〇フレームワーク集みたいな流れが、みんなNPMから引っ張ってきて使うと思います。
そういうのがWebComponentsの役割としてそちら側に吸収されて、そのnodeの末端としてそれらを使うという感じになると思います。あとデザイントレンドって頻繁に変わるので、そういうものと密に紐付きたくないんですよ。
いろいろ理想的な話をして高まってきたんですけど(笑)、現場はそうではないと、一度落ち着いて考えましょう。
いろんな立場がありますよね。
僕は1番上のSPA開発者みたいな立場なんですけど、ファンタジーランドの住人が「関数型だ!」、Web標準原理主義者が「NLPMNなんて標準にないもの使ってんじゃねぇ」、あとは「現場はjQueryだからjQuery以外使うなんてあり得ない」みたいな人ですね。
僕らがワーッと、Redux、Reactだ、webpackだ。webpackは死ぬ」と言っている間に「付き合ってらんねぇ」と言ってるほかの言語開発者がいます(笑)。じゃあ我々はどうしたらいいのかと言うと、現場の糞コードをよ。な?
(会場笑)
泥臭いことやるしかないんですね。例えばlintを書く。ESlintを書く。型を書く。グローバル変数を潰す。テストを書く。こんなのみんな耳にタコができてるくらい聞いてきたと思うのでわざわざ言うまでもないと思ってるんですけど。
そもそも良いコード、悪いコードとは何かと言うと、僕はテストがしづらい環境の言語だからこそ静的解析、静的検査ができるというのが大事だと思っていて。
静的検査ができるとコードが捨てられるというのが大事です。コードは捨てるためのもので、動くことも大事なんですけど、それ以上に捨てるパスが用意されているというのが大事です。だから悪いコードというのはモジュール境界が明らかでないコードだと思います。
例えば、これは公開資料でだいたい書いてあることだから言ってもいいと思うんですけど。Qiitaで僕がやったのって、Rails SprocketsをBrowserifyに変えて、グローバル参照渡しをES Modulesに変えて、Backbone.ViewをReactに変えて、ViewとStateをState管理層とView層をきれいに切り離しました。
噂によるとHyperappに置き換えられたらしんですけど(笑)。
(会場笑)
これ別に中の人と喧嘩しているということではなく、けっこう誤解されて外野で騒がれたりしたんですけど、ViewとStateがきれいに切り離されていればそういうのが一瞬できるというのが大事です。
置き換えられるというのは、つまりそういうことです。フレームワークを気軽に変えられるくらいには柔軟。HyperappはJSX記法をそのまま食えるんで。あと中央のState管理層がきれいに切り離されているからこそ、あとの末端はなんとでもなるという話です。
最近freee社でちょっとお手伝いをしてるんですけど、ここでやったのはSprocketsをWebpacker......またSprockets殺してるんですけど(笑)。
(会場笑)
Sprocketsってなかなか手強いんですよね。Railsやっているみなさんに、正規表現で全部書き換えたんですけど、グローバル変数の渡しを変えたり、今Backbone.Routerを1個ずつ解体してたり、あと古いコードにflowの型付けて回ってます。
とりあえずこれやっとけ集で、なにがなんでもこれはやったほうがいいです。
本当に。prettierは最高。eslintのno-unused-vars、未使用変数があったらもうダメ。そのコードは消せる。eslintのprefer-constもimmutabilityが静的に判明してconstかletわかります。付けてください。
大事なのはOSエコシステムに従うこと、Web標準に従うこと、レイヤーを分解すること、それらの土台を確保した上で、全部をぶっ壊すことですね。守っていればより大きなジャンプができる。
ここまでいろいろ言ってきて、じゃあフロントエンドエンジニアとはそもそも何なのか? という話だと、僕はフロントエンドエンジニアはこういう。ちょっと面倒くさい図なんですけど、(こういうふうに)理解していて。
普通のtraditionalなWebからWeb Standardの系統と、node.js toolchainの系統があって、node.js toolchainで複雑なことをする合流地点がフロントエンジニアの目線の位置だと思っています。
Server Side node.jsをやってもいいし、Universalという視点で普通のWeb Standardのほうに合流してもいいし、SPA作ってもいいし、ReactNative作ってもいい。あとWebAssemblyを書いてもいい。WebGLも。わりとこれは修羅の道でおすすめです。
(会場笑)
みなさんそれぞれのゴールがあって、スピードのためにフロントエンドをやるという人も多いです。Webフロントエンドってスピードだという人も多いんですけど、継続してコードを発達させるということがそれと同じくらい大事です。
そのためにきれいなコードを書く。捨てられるコードを書く。静的検査で活きるコードを書くというのが僕は大事です。自分がどっちに重きを置いているかというのは意識しながらコードを書いたほうがいいと思います。
フロントエンドアーキテクチャのまとめとして、フロントエンドというもののGUI設計みたいなものと完全に合流したと思っていて、ユニティ、モバイルアプリなど、だからこそReactNativeみたいなものが出てきたんです。ただそれと一緒なのは違って、今のフロントエンドってオブジェクト指向、Functional promming、GUI設計の知見がごった煮で、それらの人たちが主張をぶつけ合うバトルフィールドなんですよ。だから声がでかい人が多くて(笑)。
あなたに必要なのは何ですか? ということで自分に必要なものをうまく見定めて使っていけたらいいですね! というところでこの話は終わりです。お疲れ様でした。
(会場拍手)
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略