JavaScriptの魅力とTypeScriptの距離感
雨宿りとWEBの小噺、皆さんこんにちは。keethこと桑原です。この番組では、目まぐるしく変化するWEB業界の中、ちょっと一息つける裏話や小噺などをお届けします。
数年前から、門川土案語情報工科学院専門部というところで、プログラミングの講師をしているって話は以前もしたんですけど、今年はTypeScript と React の漢字音の講義をやっております。
一緒に手を動かしながら教えていて、その中でですね、JavaScript からやった方が良かったかなと思うことが何度かありまして、その深掘りをしていたんですけど、
そもそも僕自身が、TypeScript に関するちょっと距離感みたいなものがあるなっていうのがおぼろけに見えてきて、せっかくなんでそれを言葉にしたらそのまま発信したくなったので、今日はその話をしようと思っております。
前提として、私はTypeScript にはそれほど思い入れがないんですよね。それはTypeScript に私がまだ慣れ親しんでいなかったり、業務でそんなにガッツリ書いたという経験、時間がそんな長くないっていうのがあるからなっていうのが思うんですけど。
なので現時点でTypeScript はそうでもなく、どちらかというと JavaScript の方が大好きなんだなっていうのはあります。
その前提で話していきますが、そもそも僕が JavaScript を気に入った現体系みたいな話をするとですね、
私は大学院の時もずっと数学の研究をしてまして、学部の頃は結び目理論の中の体積予想っていう予想に関する研究を大学教授化されていて、
それの一つの分野を僕がお手伝いとする形で学んでいました。そのまま大学院も同じ研究室に所属して、大学院では
基礎解析にすごく魅了されまして、リーマン・ゼータってリーマンのゼータ関数に関する問題。
ミレニアム問題の一つにリーマン予想ってあるんですけど、それに関わるものの一つとしてリーマン・ゼータの特殊値に関する計算をしてました。
実際具体的にその数値が一つ計算されれば、その後発展見えるなっていうのが思っていて、
なんか一つその実績が作れたら嬉しいなと思ったんですけど、まあそこに僕はたどり着かなかったんですが。
そういうふうに数学の研究を大学院までずっとしてまして、所属としては情報システム工学専攻だったので情報系にはいて、
ある程度情報の基礎となるような学習、勉強とか、ウェブ周りもちょっとはやったかなっていう感じです。ほとんどやってないですけどね。
その中で、JavaScriptという言語の存在を知って、見た目の動きを作れるっていうことの楽しさが結構僕の中でありまして、
バックエンドとか見えないAPIを作るよりも、やはり側の方、見えるものを作る方が楽しいなっていうのがあって、
そこが僕の現体験かなと思っています。
まあそのままその時の楽しいとか面白い経験、体験がずっと残ってて、社会人になってもそのままフロントエンドエンジニアに最終的にはなりましたね。
今はEMなのでコードを書くよりも違うことをしてますけど、エンジニアとして僕が一番歴長いなフロントエンドかなと思います。
TypeScriptの経験と課題
ある種ですね、JavaScriptを書いているときに気持ちよさみたいなのを感じてますと。
そのどういう話かっていうと、他の言語で言うとRubyを書いている時も感覚は近くて、
要はそのメソッドをドットで繋いでいく、いわゆるメソッドをチェーンで繋ぐみたいな言い方をするんですけど、
そのチェーンで繋ぐ書き方が僕結構気に入っていて、なんとなく関数型っぽい。
それを使ってやりたい処理がチェーンで一個一個、この処理が終わったら次、この処理が終わったら次っていうのがすごく明確でわかりやすかったんですね。
それが繋いで一発で書けて処理が通ったっていう時、結構こういう時に僕気持ちよさを感じるタイプなんです。
あとはまあいろんなライブラリーを駆使して、やりたいこととか表現とかいろんな振る舞いとかですね、
っていうのが実装できた時もまあまあ気持ちいいなーっていう感覚はありますね。
プログラマーやってるくせに、ある種の魔法のような感覚を実は持っていて、あるまじき感想だったりするんですけど、っていうのがありますね。
ただまあこれはJavaScriptっていうかライブラリーの方が、それを強く感じるかもしれないですね。
いろんなものをラップして機能として固めてくれていて、それをうまいこと簡単に使えるようにしてくださってますので。
はい、言語仕様で特にJSが好きっていう理由はあんまり実はないかもですね。
どちらかというと、グローバルスコープだったりJavaScript、クロマ術とかって調べるといっぱい記事書かれていて、
いや、仕様に関する根本的な考慮が足りてないというか、落とし穴みたいなのがたくさんあるので、そういう意味だとあんまり言語仕様で言うとJSはそんな好きじゃなかったりするかもしれないです。
ただまあ強いて言うと、先ほど言った通り見た目のところが私は大好きで、ブラウザを操作するっていうところの全能感っていうんですかね、こういうのが好きなのかもしれないです。
続いてタイプスクリプトの経験とちょっと違和感的なものもちょっと語っていきますが、タイプスクリプト業務で最初に触ったのいつかはちょっともう完全に覚えてないんですけど、
がっつりタイプスクリプトを使って開発を仕事でやったっていうのは、多分延べ2年ぐらいじゃないですかね、ほとんど書くよりもマネジメントとか対応の方に注力するところが多かった。
まだまだ僕ががっつり現役でコードを書いている頃ってまだそんなタイプスクリプトが安定しなかったし、チームとしても入れてない時が多かったんですので、実はがっつり使ったの2年ぐらいですね。
タイプスクリプトを使っていて正直にちょっと面倒だなとかこれちゃうなみたいな風に感じること実はあって、そのうちの一つが型パズルとか複雑な型を見た時です。
ジェネリックス使われて、ジェネリックスも一回そうなるんですけど結構熱想することがいっぱいあるじゃないですか、ジェネリックスにジェネリックスが出てきてみたいなとかいう型定義を見ていくと、もう正直言うとまずそれを読み解かなきゃいけなかったり、これ何表現してんだっていう、見たことがない正規表現のコードを見る時と割と似てる感覚がありまして、認知もそ高いんですよね。
慣れた人だとそれが当たり前にすらすら読めるんですけど、タイプスクリプトじゃなくてJSだったらそんな書いてないからそもそも認知しなくてよい、その代わり型がわかんないのでこれ何が入るかわかんないという不具合発生する可能性ありますけど、たまに型パズル本当にこれいるのっていう風に感じることがちょこちょこあります。もうちょっと簡単にできないのかって思ったりですね。
長い型定義とか書いてあると正直可読性は絶対下がると思ってるんですよね。そこに時間とられるんだったらどっちかっていうともっとユニットテストの方を強化してバグを抑え込めるならそっちの方が僕は良いと思ってる派です。僕が単純に自動テスト大好きっていうのもあるんですけど、とはいえちゃんとテストは書いていかなきゃアプリケーションとしての堅牢性は保てないですから。
あとタイプスクリプトを書いてて、いわゆるフロー状態になるみたいなことって僕なかったんです。今まで一度もないなと思っていて。アプリケーション開発をしていてタイプスクリプトを書いてフローになることって別にそれがないわけではないですけど、そういうのは下手してJavaScriptの機能とか関数とかを使って実装してる時であったりするんですよね。この変数とか関数の定義に型をつけたり型を考えるみたいな時、実はここに僕あんま面白み持ってないんですよ。
表現の振る舞いとか実装から結構離れている感覚も正直あって、型を考えるって。脳のリソースを型に使った分をアプリケーションに回せる方が良くないかなっていう気持ちがあります。ですのでJavaScriptの方が好きなのかなっていうのはそういうところにあるかもしれない。
テストの重要性とプログラミング哲学
ちょっと話変えまして、先ほどユニットテストが僕大好きだしテストで担保できればええやんみたいな話をちょっとしたんですけど、ユニットテストで十分みたいな考えはテストってやっぱりどうやったって必須なんですよね。タイプスクリプトの型だけでは担保できないものってたくさんある。
ですのでテストはいると。あとアプリケーションとかシステムもしっかり細かく分けていく。小さなモジュールに分けていくと最終的にはユニットテストで十分なくらいの小ささになるわけですよね。そういうものが積み上がってシステムになっている。であれば極論ユニットテストでアプリケーションとかシステムの品質ですね。品質って言ってるのはいわゆる不具合っていう意味だけの品質です。
体験とか置いておきます。そこは担保できているというふうに僕は感じているんですよ。あとは僕自身がテストをはじめ自動ソフトウェアテストが大好きってのはあるんですけど、型で防げるバグとテストで防げるバグについては実態と外れてるかもしれないですけどテストで防げるバグの方が僕は多いんじゃないかなっていうふうに思っていて。本来バグを防ぐ、セキを担うっていうのは型ではなくて僕はテストだと思ってます。
テストと型の重要性
テストがなくて型があるコードよりも型がなくてテストがあるコードの方が私としては堅牢だって絶対思ってるんです。ですのでテストの方にリソースを割きたいなっていうのもありますね。でもタイプスクリプトの良い部分も僕も従順承知してますし、総合的にはタイプスクリプトの方が強いっていうのは思ってます。
例えば開発していてリアルタイムで型エラーとか起こしてくれる方がリアルに書いているその場でエラーを入ってくれる方が絶対体験としてはいいんですよ、開発者の。そこは気に入ってます。あとはタイプスクリプトを使ったチーム開発で、これ確かに良かったなって思うのは型があるおかげで変数とか関数の中身、もしくは引数の値の型ということがわかる。
ということでは不具合の少ないコードをかけているはず。リモートワークで僕ら仕事をしていることがエンジニアはかなり多いと思うんですけど、そういうのが見ればわかるというふうになっている。いわゆるドキュメンテーションの意味を成している。これ大きいですよね。地味に大きいと思ってます。それぞれで認知の差異が生まれなかって相当がなくなるようになる。これはかなり大きい。後でコミュニケーションのコストがいらなくなりますから。
あとはタイプスクリプトの良いとされる部分。型安全性とかIDの支援とか、この辺はもうまさしくまさしくっていうので、理屈ではわかってますけど、感情としてそこ好きになるかというと僕はそんな好きじゃないなっていう感じです。ただメリットとか強みっていうのはすごく理解して、その恩恵には預かりたい。気持ちは変わらないですね。
開発速度のお話もちょっと気になっていて、僕実はまだJSで書いた方が早いんじゃないかと考えている派なんですけど、実際計測したこともないし、そういうデータを見たことがなくて、軽く調べた感じ見つからなかったんですよね。
なんですけど、言うてドキュメンテーションの意味合いがあって、プロジェクトの認識の疎後とか差異があって、コミュニケーションしなきゃいけないみたいなところが一番プロジェクトのコストがかかるとかと思っているので、そこを解消するタイプスクリプトのいわゆるドキュメンテーションの意味合いがかなり大きいので、実はTSの方が早いのかなとか、テストもある前提で型もあるので、よりバグが最初から防げていることで、後でそのバグフィックスをするっていう時間も削られるので、
プロジェクト全体の長い目で考えると、タイプスクリプトの方が開発は早いかもしれないですね。ちょっと自分の意見でも矛盾してますけど。
コードの美しさと開発の速度
あと、観点としてJSのコードとTSのコードの美しさみたいな、コードの美しさについてもちょっと考えてみました。
これはもう皆さん意見は一致するでしょう。タイプスクリプトでいく場合が上がるんじゃないかなと思ったりしてますね。
やはり型ってさっき言った通りドキュメンテーションの意味もありますけど、いわゆるルールという意味も入ります。
ですので美しさでいくとそうかなと思いつつ、美しさの定義は人によってまた違ったりするんであれですけど。
僕はさっき言った通り過読性がタイプスクリプトが入ることで下がると思っているんですよ。
過読性ノットイコール美しさなので何とも言えないっちゃ言えないですけど、私としては型がいっぱいあるおかげで読むものも増えたりするので、
これは美しいのかなっていうと僕はあんま美しくないと実は思っていて、その意味だとJSの方が美しいかもしれないです。
コードってだけの美しさで言えば。これもでも型注釈のところとか複雑な型になればなるほど過読性下がりますけども、
慣れれば全然気にならないのかもしれないですね。認知コストやっぱ上がるのは僕どうしても気になっちゃうなというところですかね。
開発奥だって言ったけどチーム開発だと個人開発の使い分けみたいな話はあると思っていて、
チーム開発やったら絶対タイプスクリプトの方が早いんだろうなっていうのはぶっちゃけ頭では思ってます。
個人開発だったらどうなんという話はちょっとありますけど、最近は個人開発でもタイプスクリプトで書いてる人の方が圧倒的に多いんじゃないかなという気はしてますね。
僕の周りでもそういう人の方が圧倒的に多かった。チームでやるんだったらタイプスクリプト一択だっていうのは僕も心から思ってます。
学習のアプローチ
今から生JSをチームで書くっていう怖さっていうのも正直芽生えてます。
僕個人が一人で勝手に作るプロダクトとか、プロダクトは作ることはあんまりないですね。僕は多分ライブラリばっかり作るんですけど。
あとJSで書くかもしれないなと思いつつ、それでも一般公開するのはTSかもなっていう感じがしますね。
あとは他の話の観点で言うと冒頭で喋ったように、学習の話ですね。
新しく学習する方についてはですね、悩ましいところで、やっぱりこれもJSから入った方がいいんじゃないかっていうのが僕一周回ってやっぱり戻ってきちゃいました。
TSから入っていく方向で今は僕の講義をやってるんですけど、途中途中JavaScriptの機能の話絶対入るんですよ。
それを知らないままやってるので、これに関しては実はJavaScriptの機能ですっていう説明をしてて、機能とかAPIですみたいなのをしてるんですけど。
中途半端な説明だって、これはTS、これはJSみたいなちぐはぐな感じになりそうなのが結構懸念してます。
とはいえでもJavaScriptの学習から先にやると、ついついまずは座学をやりがちですし、でも座学は全然重いのないと。
逆にアプリをJSから作る、リアクト使ってもいいですけど。
作って、でもそれの型の良さっていうのを後でTS入れて、TSで作り直すっていうのだったらやっぱ最初からやった方が時間的コストもかかんないし二度手間にならないので、
じゃあTSからやったほうがいいかっていう気もしてて。
ここちょっと僕まだ答え出てなくて、どういう学習カリキュラムがいいのかっていうのが参考程度に皆さんご意見あればすごくいただきたいと思っているところでございます。
いろいろ語りましたけど、大衆意見は結局TSのほうが群馬に上がるっていうふうな感じはしてます。
諦めてるというか、JSの可能性はもうないのかってそういう意味ではなくて、単純にメリットがTSにあるっていうだけに過ぎないですね。
僕も理性ではTSのほうがそこ的にと分かっているので、TSで全然仕事もするし、今後個人コードもTSで書くかもしれないですけど、
それでも感情的にはJavaScriptが好きっていうのはずっとありますね。
これは本当、単なる感情なのでわかんないです。
三つ子の魂100までみたいな感じかもしれないですね。
最初に楽しいと思ったプログラミング言語がJavaScriptだったからっていうのはあるかもしれないですけど。
いろんなことを語りましたけど、そんな感じで。
今後僕のTSの習熟度が上がると、距離感とかもしかしたらTypeScriptが好きになるかもしれないっていう。
まずはその習熟度を上げるところからかなという感じです。
またその型パズル自体の面白さっていうのはあるじゃないですか。
パズルって言ってるぐらいなので、そこにピタッとはまるような型を考えられたみたいなところですね。
なのでもうちょっとTypeScriptにしっかり使って面白さっていうのを理解すると、また今後の意見変わるかもしれないですけど。
いろんな観点があると思いますので、今後も参考になれば幸いです。
といったところでございます。
感情も結構僕は大事にしたいなと思っているので、JSそのものが悪いとも思ってはいない。
好きですからね。
あとは自分もTypeScriptアンチでもないです。
今語ってきたからさすがに理解していただいていると思いますけど、
そういわゆる哲学というか、開発哲学というか思想とかいうところだとTypeScriptだっていうのは一緒ですか。
今後もJSの愛は変わらないですが、TypeScriptともうまく付き合っていきたいなと思っているので、今回の話は終わっていきたいかなと思います。
ではエンディングです。
ここからも雑談なんですけど、僕AIの話あんまりしないって言っておきながらいきなりするんですけど、
クロードに課金をずっとしていて、今回クロードのソネット4が出ましたじゃないですか。
新しく自分が課金しているAIのアップデートが来るのはすごく喜ばしくて早速使っているんですけど、
今回この台本を書く時にも割とクロードに自分のTypeScriptとJSの感覚の違いについて結構壁打ちをしてもらって台本を書いたんですね。
それについてわーっと語ってみたんですけど、そこで結構言語化できて、それを今喋ってきたところですね。
いやーかなり進化したなと本気で思います。
感情とかのお話を投げても割と丁寧に答えてくれたり、怒って実はこういう風な感じでませんかっていう、
クロードが投げかけてくる問いのクオリティがすごい高いんですよね。
その問いから僕がまた頭を考えて自分の気づきを得られたっていうのはかなり大きくて。
いやーこれはありがたいし、今後もっともっとAIとどっぷり生活していく流れっていうのは変わらないというか。
加速するんだろうなってちょっとも言いましたね。
プロンプトエンジニアリングの重要性
あとクロード4のモデルでオーパス4とソネット4って2つあるらしくて、
僕あんまちょっとまだ理解できないんで、この辺も公式ドキュメント、
クロード4、プロンプトエンジニアリングのベストプラクティスっていうページもあったので、
ここを読んでいきたいなと思ってますけど。
一般原則としていくつか書かれていて、指示を明示的に行いましょうっていう話とか、
コンテキストをちゃんと追加してパフォーマンスを向上させましょうと。
これ多分速度じゃなくてクオリティの話だと思いますけどね。
これ結構面白かったの。
効果的でない例として省略記号を絶対に使わないでくださいみたいな、
いわゆる否定のコメントですけど、これっていわゆる選択肢を絞っている。
選択肢の中の1つを絞っただけで結局じゃあどう出せばいいのみたいな話が出てくるじゃないですか。
そういうものよりもこういうケースでユースケースで使うとか、
こういう場面で回答する答えが欲しいみたいな。
これ結構具体な話ですよね。
とかが出てきて、そこをやるほうがやっぱり説明が入るわけで、
クロードとしても十分理解できて賢い回答が返ってくるみたいな話されてましたね。
つまり何をしないかではなくて何をすべきかっていうのを伝えましょう。
これはクロード以外の普通にAIも一緒かもしれないですけどね。
あと面白かったのがXML形式のインジケーターを使用するっていうところ。
ついに行動かけみたいなタグを書いてくれるみたいなところがあって、
これを試してくれって言われたのが割と面白かったです。
XMLとか慣れてない人だとこれ何?ってなるかもしれないんで、
エンジニアライクな感じはしますけど、
でもプロンプトエンジニアリングって言ってるぐらいだから、
このドキュメント読む人は基本エンジニアなんでしょう?と割り切ってる気がします。
あと他にもいろいろベストプラクティスの中に何を書くかみたいな具体例書いてあるんですけど、
いろんな人がXで投稿してまして、一番面白かったものの記述がですね、
ビジュアルおよびフロントエンドコード生成の強化というところで、
フロントエンドコード生成に関しては明示的な章例を提供することで、
Cloud4モデルが複雑で詳細かつインタラクティブなデザインを
作成するように導くことができますというので、
サンプルプロンプトの中に遠慮せずに全力を尽くしてくださいっていうコメントがあるんですよ。
いや本当にAIに関してこんなコメントとか指示を出すんやっていうのは興味深かったですけど、
よりAIが僕らの横にいるというか、
本当に伴走してくれる仲間に近づいてきたんだなっていう感じはあります。
昔はまだやっぱツールとか、言い方悪いですけど道具に近かったんですけど、
例えば同僚とか仕事仲間、部下とかメンバーの人に指示とかお願いをするときのやり方って、
やっぱり背景とかを語ったり、期待値はこうですとかを語ったり、
あまりにも雑だったらあれなんで、ちゃんと説明、詳細なものを伝えるじゃないですか。
それと同じことをやっぱりAIにやっているという話ですね。
AIに伝えるっていう感覚で伝えるんじゃなくて、
あくまでこれを仕事仲間に伝えるみたいな感覚で文章を作ってAIに投げる。
やってることは一緒なんですけど、意識として一回仕事仲間に投げる体で文章を考える方がいいのかなっていう感じですかね。
そんなことをこのドキュメント読みながら思いましたので、興味ある人見てみてください。
AIとの効果的なコミュニケーション
一応概要欄にも貼っておこうと思います。
クロージングです。
この番組面白かったよという方はぜひチャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック、感想などございましたら、
概要欄のフォームやXでハッシュタグ、web小話でつぶやいてください。
webはアルファベット、小話は漢字でもひらがなでも大丈夫です。
今回もお聞きくださりありがとうございました。
雨宿りをしながら考える技術の編成、次回もどうぞお楽しみに。
お相手はキースでした。さようなら。
次回をご覧ください。
No.1ポッドキャストクリエイターは誰だ?
