00:02
皆さん、こんにちは。雨宿りとWEBの小噺へようこそ。
Podcast配信者のkeethこと桑原です。
この番組は、日々降り注ぐ情報の中でちょっと雨宿りしながら、
様々なWEBテクノロジーの成り立ちや裏話を小噺としてお届けする番組です。
State of JS 2024 の概要
今回の話題は、State of JS 2024 の結果を眺めよう第一回、となります。
State of JS、改め、State of JavaScript。
こちらはですね、全世界のエンジニアにアンケートを投げて、
そのアンケートの回答結果をまとめたもの。
有志の方がやられていて、僕も何度か回答したことがありますし、
皆さんでも参加できるようになります。
メールを登録すれば、次回からアンケート回答しねっていう風に
メールが飛んできますので、そこから回答する感じになりますと。
このアンケートは、2016年から2万人以上の開発者に対してやられていて、
現在もこれらのトレンドについてデータを結構集めてます。
開発者が、次はどんなライブラリー学びたいなとか、
どんなライブラリーが今最も満足度高いか、
もしくはJavaScriptのこんな機能が今ホットですよ、
などなど、こんなことを知るためのアンケートですので、
これ全世界で回答しているので、
自分たちが今やっているものとか、
自分たちが使っているものと世界がどんなふうに差分があるかっていうのは、
特に日本においては、そういう情報は大事だと思いますので、
ぜひこれを僕も毎年しっかり追っていきたいなというので、
今年も見ていこうかなと思っています。
冒頭ですね、代表の方、これは運営されている方からのメッセージもあったので、
そこもちょっと眺めてみようかなと思っています。
日本語翻訳しちゃったものをちょっと読みますね。
2024年のフロントエンドフレームワークのトップ3っていうのは、
いずれも10年以上前に発表されたものだ。
確かに3つともその過程で多くの進化を遂げ、
2014年のパターンは、本日ではまさに時代遅れに思えるでしょう。
しかし、JavaScriptのエコシステムが絶えず変化の渦に巻き込まれているという評判を考えると、
不変のものもあるということを知っておくのはいいことかもしれない。
不変といえばビートとビーテストは依然としてあらゆるチャートのトップに君臨し、
より新しくシンプルな世代のツールをリードしています。
また、新しいメタデータをメタデータフログを追加しました。
また、クエリビルダーを使用して、これらの新しい変数を他のチャートに適用することもできます。
それでは今年のJavaScriptの活躍を楽しみくださいっていうので冒頭のメッセージでした。
サシャ・クリーフさんって方ですかね。
このアンケートもいくつかの大カテゴリに分かれていて、
その大カテゴリの中に中カテゴリと小カテゴリがかなり細分化されていまして、
内容がかなり多いので、今回から5回に分けて配信していきたいと思いますので、
ゆるりとお付き合いいただければ。
今回は回答者の特性もしくは機能ですね、JavaScriptの機能のところで一旦とどめようと思います。
それでも多分20分は硬いんじゃないかなと思ってますので、
では早速見ていければなと思ってます。
まず最初回答者の属性ですね。
回答者の属性と年収
今回の回答者は合計14,015人回答いただいたそうです。
増えましたね。数年前とかまだこれの半分、3分の1以下の4,000人ちょっとだったはずなんですけど、
どんどん増えてきました。
このアンケート、サーベイが価値を感じられた、強化されているっていうことの小差だと思いますけど。
まずは前回答者の国または地域別の差を見ていきましょうかというところでランキングになってます。
1番はやはりUSAですね。
アメリカ合衆国が1番回答していて1596人。
実に15%占めます。
2位がドイツの8%で874人。
3位がフランス7%で710人。
4位スペイン4%で448人。
5位はユネイテッドキングダム、イギリスですね。
こちらが4%同じくらいで436人。
トップ5がこんな感じになってます。
では日本人はと言いますと、第21位ですね。
今回は1%ぐらいですね。
合計150人が回答をしてます。
大体そんな感じの回答ですので、この数増えていただくといいのかなとはやっぱり思いますね。
続いて年収ですけども、年収ランキングを見ますとやはりこれもアメリカダントツ1位ですね。
USAは価格帯が、これ多分中央値だと思いますけど、
そうですね、50%でいくと100、嘘つけ17万5千ドルですね、年収が。
はい、大体2千万いく、2千万ちょっとぐらいが50%だそうです、アメリカって。
いやすごいですね、しっかり稼いでる感じがありますし、評価されている。
第2位から4位までが50%が一緒で、
オーストラリア、スイス、イスラエル、これらが12万5千ドルということで、
これも結構高いですね本当に。
漢字の日本はっていうとですね、日本はだいぶ確か下がっていって、
50%タイル数が5万ドルですので、大体750万円ぐらいが中央値だという感じですね。
されて聞くと750って意外と高いんじゃないかなっていう感じはありますね。
こんなところでした。
ちなみに25%タイルが3万ドルので450万、500万いかなくぐらい。
90%タイル数でいくと12万5千ドル。
日本でも高い年収稼いでる人は稼いでいる。
年齢分布と経験年数
続いて年齢を見ていきましょう。
ジェンダーはさすがにいろんな話があるのでジェンダーは割愛します。
年齢を見ますと、回答者の一番多いのは30から39代、30代ですね、が一番多くて43%。
4705人が30代です。
僕もちょうどこの30代に値しますね。
もうすぐ40代見えてきますけど。
第2位はやっぱりJavaScript、フロントエンドの開発をする方が多い。
ノードJSもあるかもしれないですけど。
なのでやっぱり20代が第2位で32%で3508人。
第3位が40代で17%。
418人でガクンと減ります。
嘘つけ。
17%で1877人でした。
第4位が50代ですね。
50歳から59歳の方が第4位で4%で418人。
第5位が20代以下で271人。
ラスト60代以上がそれでも0.7%で73人回答されてるんですよ。
これすごいです。
世界の60代以上でもフロントエンド、わからないけどJavaScript少なくとも書かれている方ってのはいるんだなと。
書いてるかわかんないですね。
このアンケートに回答してるだけですので。
回答してる内容的には書いてなきゃ、もしくは使ってなきゃ回答しないでしょうみたいな内容のものがいくつかあるので。
やはり現役で書いてるんですかね。
すごいなと思いました。
続いて年収も一緒ですね。
年齢と年収はだいたい比例していくものなので。
年収一番高いのは50代ですね。
50代の50%対率が119,500$ですね。
ちなみに90%対率で198,500$なんでかなり稼いだもんね。
第2、40代。
第3、30代、20代と下がっていくといったところですね。
60代以上の方でも50%対率が86,000$いくので、
割と40代といい勝負をしているっていうところですね。
いやーほんとびっくりです。
続きまして経験年数ですね。
経験年数見ていきますと一番多いのは5年から9年。
こちらが31%で3444名。
第2が10年から14年ですね。
これが21%で2355名。
第3位は0から4年間ですね。
20%2195名。
そのまま第4位15から19年。
こちらが1322人。
20から24年の人が958人。
25から29歳の人が493人。
オーバー30years。
すごい30年以上JavaScriptでやられている方が315人いると。
それまたそれですごいですよ。
30年以上JavaScriptを書いている。
ESとか言ってない世代ですよねこれ明らかに。
いやーほんとすごいなと思いました。
ネットスケープ、インターネットエクスプローラー、
あの戦争時代からJavaScriptを書いているんじゃないか。
会社の規模はまあまあ参考値ですけど、
一応ざっといきますと100名から1000名の会社が
一番多くて22%ですね。
で、次が1000名以上の会社で21%。
まあまあこれはそうですよね。
会社大きければ大きいことそれはその人たちが
パイを取ると思いますので、まあそうだよね。
で、そこから20人から50人、50人から100人
みたいな順位が続いていきますね。
はい、まあ一人でやられている。
一人企業とか個人事業主の方で一応7%いるって感じですね。
はい、回答なしの人が508名なんで、
まあこの人たちもどっかに属していると思いますけど。
以上、まあだいたいそんな属性周りのところを
ざっと見ていきました。
あとは一応年収のところでいくと、
年収の価格帯で何パーセントですかっていう
割合を一応出してくれておりますけど、
まあ場所を見ます。
で、一応USA vs WORLDっていうものもあるんですけど、
アメリカって言ってもアメリカのどこの地域によるか
っていう話変わりますからね。
フランシスコだったら多分バーンと跳ね上がるでしょうけど、
まああそこで生活する分には
跳ね上がってないとそもそも生活できませんから。
みたいな話があるので、
あまり参考にならない気がするんで、
こちらは端折ります。
で、肩書きもまあ端折っていいでしょう。
はい、あとは高等教育の学位やジェンダーとか、
人種・民族みたいな話もありますけど、
一応ちょっと人種・民族は僕は気になるので
見ようかなと思います。
1位は白人が多くて圧倒的ですね。
68%が白人ですと。
はい、6649名。
第2位、ヒスパニック・ラテン系です。
これが16%。
第3位が東アジア系で6%。
で、第4位南アジアで4%。
なのでアジア系で10%とって、
第3位と言ってもいいでしょう。
第5位は中東系で4%。
で、あと中南アジア、黒人・アフリカ系、
マルチ・レイシャル、ネイティブ・アメリカン、
大変洋諸島ホゲホゲみたいな感じです。
で、あとヨーロッパ系とつながりますけど。
まあそんなところですかね。
はい、じゃあ続いて機能のお話いきましょうか。
機能もたくさんあるので、
新しい構文機能の使用状況
全部言っていくと一気に時間が振っておりますけど、
まあ一個ずつ見ていきましょう。
まず一つ目、公文機能からいきたいと思いますけど、
こちらはですね、今から出てくる機能を
使ったことがありますかみたいなお話ですね。
一つ目、ヌル合体演算子ってやつですね。
これ使ったことある人は実に85%なので、
もうほぼ皆さん使われているよってところです。
二つ目、二つ目はダイナミックインポート。
ダイナミックインポートもまあまあ使わなくはないですけど、
ちょいちょい確かに見るなってことで、
こちらの回答は使ったことある人67%で、
まあそこそこいますねって感じでした。
続いて三つ目、プライベートフィールドですね。
例えばクラスの中にシャーププライベートフィールド
みたいな名前でプライベートの変数が作れるんですけど、
まあまあそもそもクラス公文書かないしな
っていうのはあるんですけど、
これまさかですね、使ったことある人45%なので
意外といるなって感じです。
今使っているっていう数字じゃなくて
使ったことがあるっていう数字ですので、
ここまで行くのもわからなくはない。
昔のそのクラス公文を使っているときに
書いたって人もいるんでしょうけど。
僕は使わなかったですね。
一度も使ったことないです。
続いてロジカルアサイメント。
こちらが回答44%です。
正直言うと名前を聞くことすらほとんど僕ないので、
意外と44%いるんだなっていうのはちょっとびっくりしました。
続いて五つ目、ハッシュ版文法ですね。
JavaScriptのスクリプトファイルの冒頭に
ハッシュ、びっくり、なんちらかんちらみたいな。
ノード.jsで使ったりすることもあると思いますけど、
ハッシュ版が使ったことある人20%なので、
ノード.jsを書いて言える人が少ないんだろうなと思います。
このサーベイの回答者の中には。
わかんないですけど、一応そういう予測もできるな。
あとコマンドラインツール系とかを作って
NPMに公開したことある人とかだと、
一度はハッシュ版を使うんじゃないかと思いますけど、
そういう人あんまり少ないのかなって感じはしました。
続いてError.causeってやつですね。
これ中身は知ってるんですけど、
使ったことは一度もないです。
トライキャッチとかでスローニューエラーとかするじゃないですか。
スローニューエラーしたときの第2引数に
オブジェクトで構図、コロン、変数名とか出てきます。
変数名っていうか文字列で、
こうすることでコンソールにどういうエラーですか
っていうメッセージもそこに表示できるんですよ。
これを使ったことある人が18%。
正直言うとシンプルにコンソール.logでいいんじゃないか
って話もあるので、
必要性があるかっていうとないんじゃない。
少し便利になるかなぐらいの感覚ですけど。
Error.causeってやつでした。
以上、まず構文機能の話でした。
文字列と配列の機能
続きまして、文字列の機能ですね。
今回文字列の機能は3つだけですけども、
1つはstring.replaceallですね。
試管ですけど、
replaceは確かにあるけど、
replaceallは僕あんま使ったことないですね。
そもそもそんな長大な文字列を
変換する、試管することないんでね。
なのでreplaceはありますけど、
all使ったことある人は実に76%いるので
意外といるっていう感じですね。
アプリケーションの質とか種類とかにもよりますけど。
続いてstring.matchallですね。
matchもあるけどmatchall。
僕は実はmatchallは使ったことあります。
ほとんど使わない。
普通にmatchだけでいいんですけど。
これが45%なんで意外といないんですね。
matchで十分事足りてるよっていうことな気はします。
続いてregexpoのmatchindices。
読み方知らない時点で使ったことねえな。
こういう関数ありますね。
こちらの使用率は27%。
これ初めて見たんですいません。
僕これどういう機能なんだ。
start and position of each matched capture group。
それぞれのキャプチャーグループについて
そのポジションはどこですかっていうのを見ていく。
アウトプットは配列で書いてるんですね。
何番目と何番目みたいなところが返ってくるっていうのを教えてくれる。
確かに使わないかもしれない。
パッとちょっと用途が浮かばなかった。
これが27%なのであんま使用されてないってことですね。
続きましてもう一列終わったら次は配列ですね。
一つ目はarray.toSortって言ってですね。
最初から相当していくってやつ。
こちらは使ったことある人40%です。
続いて二つ目array.findlast。
これを使ったことある人が32%で
ちょっと少ないと思いましたね。
少ないと思ったけどあんまラストを使わないのかな。
知らないっていう可能性もゼロじゃないですけど。
インデックスラストを取ってきて
それをfindで指定することもできなくはない。
それをそのまま使ってる人もいらっしゃるかもしれないですね。
それ別に問題ないし計算回数一回減るぐらいなので
無理に置き換える必要もないよなっていう気はしますけど
1キロで書けるんだったらそれにおしたことはないと。
で三つ目array.reversed。
reversedも僕今知ったぐらいなんですけど
これの使用率は32%です。
あんま使われてない感じですね。
続いて三つ目array.toSpriteですね。
without mutating the original arrayって言ってたので
破壊的ではないっていうところが美味しいんでしょうね。
それ意味だと使ってもいい気はしますけど
僕はそもそもSpriteはあんま使わないので。
実際に使ってる人も実に19%しかいかないので
そんな皆さん使われてないって感じ。
やっぱ存在を知らない気がしますね。
これ使ったことありますかよりも
そもそも知ってますかっていうサーベイが
欲しいなっていう気はしましたね。
では続いてarray.withです。
withね。
存在を実は知ってますが
僕使ったことないですねこれ。
これは使用率13%なのであんまりと。
続いて六つ目。これが配列ラストですけど
array.fromasyncですね。
asyncの中で使うものがあるのか。
array.fromasyncにiterableのものを指定してあげて
.thenでわちゃわちゃやる。
yieldそもそもあんま使わないので
使うケースはほぼないが
そもそもyieldを使ってない限りは
使わない気がするんで
大きいライブラリーとかフレームワークを
作る方なら使う可能性はあるけど
実際にユーザーが使うような
トゥエンドのアプリケーション開発では
見ない気がしますね。
こちら使用率5%だってほとんどいないよ
というところでした。
非同期機能とブラウザAPIの調査
続いて非同期の機能。
一つ目。promise.allsettledですね。
これも存在は知ってますが
いまだに僕使ってないですし
そもそもあんまpromiseで書きたくない。
async awaitで書けるんだったら
そっちのほうがいいなと思っているので
そもそもpromiseは使わないので
厳密に言うと裏で使ってるかもしれないですけど
allsettled使ったことある人
47%なんで意外といるなって感じでした。
続いて2つ目。promise.anyですね。
anyは僕1回だけ使った
1回か2回自分で書いた記憶はありますけど
これもほぼpromiseを使わない時点で
あんま使用しないですけど
一応僕はあります。
こちら使用率は43%でした。
意外といる。
3つ目。promise.tryです。
そんなんあったんや。
ちょっと僕知りませんでした。
promise.tryと全キャッチファイナリとつなげる
一番最初に使うものかな。
これ使用率15%です。
続いてラスト。toplevelawaitですけど
こちらに関してはもはやほぼいない。
たぶんtoplevelawaitは
知られてる気はしますね。
ちょっと話題になりました。
僕の周りでは少なくとも話題になって
存在は知ってるんですけど
使ったことある人13人です。
ほぼ0%。
というところでした。
非同期の機能ですね。
続きましてsetfeaturesってやつですね。
セットのオブジェクトの機能ですけど
セットをそもそも使ってる人って
どれくらいいるんだろうって気はしますけど
該当なしがそもそもあって
76%でそもそもセットを使ってる
分母が少ない気がしますね。
今回割愛しますね。
興味ある人は見てみてください。
続いてobjectfeaturesですね。
こちらもほぼ該当なしで
67%該当なしですね。
1個だけあるのはgroupbyです。
object.groupbyは
意外と使われてるかなと思ったら
そうではないんですね。
使用率33%なんで
これ僕ちょっと意外でした。
続きましてここからちょっと
話が変わりまして
ブラウザのAPIですね。
今まではJavaScript本体の機能ですけど
今度はブラウザの方に話が移ります。
ブラウザのAPI見ていきますと
1つ目websocketですね。
websocket使ったことある人が
62%なんで
まあまあこれはそうだなと思いました。
もうちょっといってもおかしくない気がします。
意外と6割なんですね。
続いてprogressivewebapps
PWAですね。
PWA49%なんで
間隔値として僕は
50%いかないぐらい
JavaScriptのAPI使用状況
まあまあそうだろうなって気はします。
続いてgeolocationAPIが35%で
僕ちょっとこれは少ないと思いましたね。
意外とみんな使わないもんね。
続いてwebanimationが19%
webanimation
続いてwebglが5つ目ですけど
これ同着で19%ですね。
人数差もちょっとしかないんです。
webanimeとかwebglは
そういうアプリケーションを作らない限りは
使わない気はしますので
まあこれもそうだなって感じです。
続いてpagevisibilityAPI
これ俺知らんもん。
ちょっと後で見てみます。
かなユーズもちゃんとリンク載ってますので。
続いてwebrtcが15%
こういうアプリケーションじゃない限り
webrtcは使わない気がしますね。
続いてwebauthenticationAPIですが
これ伸びるかなと思ったら
意外と伸びなくて12%ですね。
オース周りのところ専門にしっかりやってるチームとか
しっかり実装しなきゃいけないっていう方じゃない限りは
確かに使わんかもしれないですね。
続いてtemporal
いやーtemporalね。
でもまだ新しい機能じゃなかったっけ。
ですので使用率が低いのも分かります。
まあ10%ぐらいですね。
あとはbroadcastchannelAPI
すいません今初めて名前を知りました。
これも10%いる。
あとはwebspeechAPIですね。
あとはgamepadAPIっていうのがあるらしい。
知らんか。
これ3%いる。
ゲームパッドって言ってる上だから
まあまあそういう業界じゃなきゃ
使わないんじゃないかな。
あとはwebXRDeviceAPI
はいこれもですね。
やっぱり業態とかアプリケーションやらない限りは
使わん気がしますね。
webXR
ただ使ってる人はこれコアに使ってるんですかね。
はい。
あとはcutoffanswersがほいほいと言って
まあ6名ぐらいいますよってところでした。
以上webブラウザーのAPI。
言語の課題
まあ新しいAPI結構生えてるんだなっていうの
こうやって見ると分かりますね。
webブラウザーもいろいろ進化してきているなっていうのと
まあ実際に対応してるかどうかっていうのもありますけど
どんどん便利になっていく
代わりにエフロントの複雑さとか難易度は上がっていくので
どこまで僕らは難しさと戦うのかっていう気はしますが
まあ進化することそのものは別にいいと思っていて
あといろんなものがあるのでしっかり使っていきたいなと思います。
1個名前読み忘れました。
webassembly
wasmがありましたね。
wasmちょっと読み忘れましたけど
これ18%いましたね。
これが多いか少ないかあれですけど
僕はもうちょっとwasm伸びると思ってたので
意外と少ないなって感じです。
と言って自分は書いてないんで
今年ちょっと触ってみたいと思ってる機能ですね。
続いては皆さん好きそうな話題。
言語の辛いところです。
1つ目はstatic typingですね。
Lack of native typingですけど
タイプスクリプトを使っている限り
JavaScriptにはstatic typingがないんですよね。
これ欲しいよって人がいっぱいいる。
これ32%
あとブラウザサポートが8%
ブラウザサポート、コンパチビリティ、
コンシステンシーイシューズ
これが8%
続いてデイトですね。
デイトね。
Handling Dates and Times
時間管理、
Momentがついにプロジェクトとして終了になったっていう話があって
それぐらいみんなライブラリーとして
全世界時間管理回りのライブラリーで
Momentを使ってたと思います。
みんながみんなというわけじゃないし
DateFNSとかDateJSとかいっぱいあったんですけど
頭もうずっと何個も突き抜けていた
Momentが終了になるっていう大事件があったので
それぐらい時間の管理を
1点引き受けてくれたライブラリーが欲しいと思うぐらいには
逆に言うと複雑だし難しいんですよね。
言語で対応してくれる分には
それはすごくありがたいと思いますけどね。
ToISOstringとかToLocaleStringとか
メソッドあるんですけど
それだけだとカバーしきれないっていうところで
Dateは分かります。
続いてTypeScript Support
TypeScript Support
ちなみにこれは7%ですけど
どこまでJavaScriptの方で標準化するのかは
僕はちょっとまだ懐疑的でございますね。
型入ってくれる分には嬉しいです。
あとはESM&CJS
絶対1回はハマるやつですけど
統一してほしいなと思います。
歴史の話があって
介護官のこととかちゃんと考えるなら
仕方ないんでしょうけど
全部ESModulesで統一してくれると
みんなハッピーな気がしますね。
あとつらいところ
ErrorHandlingとかPerformanceとか
AsyncProgrammingとか
非同期まわりですね。
StandardLibrary
StandardLibraryがJSの範囲じゃなくないっていう感じです。
エコシステムの話です。
セキュリティもそうですね。
セキュリティまわりとか
ハンドリングオブジェクト
エコシステムイシューズ
ラックオブツールス
ディペンデンシーズとか
いろいろガチャガチャバーっと
いろんなケースがありますけど
みんなが渇望してるのは
スタティックタイピングだというところです。
ブラウザーAPIの問題点
他にも言語つらいところたくさん
他にもいっぱいバーっと出てきてるんです。
一般そんなところでした。
続いて言語のつらいところが終わったら
ブラウザーAPIのつらいところ
一つ目ですけども
これはさっきも出てきましたね。
ブラウザーサポートでした。
デバッグとかブラウザー側が
実際アプリ開発するときの
サポート弱いなって思うときは
しばしば出てきますので
これはわかりますが
ちょっと抽象度高いなと思いました。
2つ目がめっちゃ面白いですね。
2つ目ブラウザーAPIのつらいところ
サファリって書いてます。
気持ちはわからんでもない。
これは説明不要でしょう。
皆さん一度は経験してるんじゃないですかね。
続いてラックオブドキュメンテーション
読みついたらラックオブドキュメンテーションは
コードエグサンプル
サンプルコードさえあったら
こんな風に書けばいいんだっていうのは確かに出てくると思うんで
そうですね
この辺がいっぱい書いてあると
嬉しいなと思うけど
MDNにもいろいろサンプルコード書いてある気がしますけど
ちょっとユースケースとして
足りないんでしょうね。
もっと突っ込んだサンプルコード欲しいんだろうなという感触があります。
続いてパフォーマンスイシューズですね。
これもまあまあわからなくはない。
ここから
アクセシブコンプレキシティとか
ファイアーホックスイシューズとか
ブラウザー固有のイシューとかもありますし
インプットタイプデート
やっぱりデートですね
PWA、Chrome、DOM API
いちばん多いのは
ブラウザのサポートが弱いよと
ずっとおっしゃっていたところでした。
ではラストですね。
この配信ラストはリーディングリストですね。
アンケート終了後に
さらに詳しく知りたい項目を
保存することができる。
エラー.コースとかロジカルアサイメントとか
オブジェクト.グループバイが
回答者の好奇心を最も刺激した
機能ですよということでした。
1位がエラー.コースで31%
2位がロジカルアサイメント27%
3位がオブジェクト.グループバイで27%
あと順々にパーセントを
貼っておりますけど、アレイ.フロムエイシンク
テンポラル
アッシュファングラマー
プロミス.トライ
アレイ.ウィズ
オーセンティケーションAPI
という感じで連なっていきます。
その辺の項目が皆さん
気になっているよということでした。
というところで、JavaScriptの
機能の話までを
今回はここでお話しましたが
一旦ここで今日は終了したいと思います。
他にも
明日以降、次回以降はライブラリとか
フレームワーク周りだったり、あとその他のツール
使用状況とかで喋っていって
終わりにしたいと思いますので
ここから5回に連なりますけど
お付き合いいただければと思います。
長くなりましたけど、今回はこのところで
終わりたいと思います。
エンディングです。
この番組面白かったよという方は
ぜひチャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック
感想などありましたら概要欄のフォームや
Xでハッシュタグ
ウェブ小話でつぶやいてください。
ウェブはアルファベット、小話は漢字でも
ひらからでも大丈夫です。
それではまた雨宿りしに来てください。
今回もお聞きくださりありがとうございました。
雨宿りとウェブの小話
お相手はピースでした。さよなら。
