TypeScript part3

**デフォルトの名無しさん** · 2018/04/26(木) 21:48:23.07

http://www.typescriptlang.org/

JavaScript that scales.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

part1
https://peace.5ch.net/test/read.cgi/tech/1349187527/
part2
https://mevius.5ch.net/test/read.cgi/tech/1430386649/

**デフォルトの名無しさん** · 2020/10/11(日) 22:42:52.59

>>617
TSについては、今のところ使う予定無いからね。
理由は既に言ったとおり、「スモークテストまでだけの為に記述が増えすぎ」だから。

ただTSは確かに立ち位置は悪くない。
型のおいしいところだけつまみ食いしよう、という意図が明確でいい。
そもそも使って無いから細かい粗も知らんし、批判しようも無い。
JSが糞な点は多々あるけど、それはTSでどうにかなるものでも無いし。

**デフォルトの名無しさん** · 2020/10/11(日) 23:10:58.87

>>616
>C#でも最初は採用されなかった理由だ。(C#は確か2,.0から)

Delegateは1.0からあるよ

**デフォルトの名無しさん** · 2020/10/12(月) 02:32:07.80

スレチは3行もいらん

**デフォルトの名無しさん** · 2020/10/12(月) 06:56:35.72

>>620
確認してみたがどうやらそのようだ。
なんだかんだでC#はマトモだな。

**デフォルトの名無しさん** · 2020/10/12(月) 08:01:12.80

実際のところ、皆さんtsを仕事で使ってたりするの？

**デフォルトの名無しさん** · 2020/10/12(月) 08:49:35.94

うん

**デフォルトの名無しさん** · 2020/10/12(月) 08:51:37.03

使ってるよ。
元々JS使いだから最初は型と戦ってばかりで時間かかって生産性下がって辛かったけど、慣れればむしろ早いし、リリースした後の安心感が段違い。
小規模開発でもこれだから規模が大きいとさらに影響は大きいだろうね

**デフォルトの名無しさん** · 2020/10/12(月) 08:55:55.53

フロントエンドエンジニアやってるけど、React + TypeScriptが鉄板過ぎる
これ以外でUI組む気になれん

**デフォルトの名無しさん** · 2020/10/12(月) 10:31:14.01

サーバーサイドでも使ってる人いるのかな
typescriptとサーバーサイドでググると
サーバーサイドでもtypescript 最高たぜ～みたいな記事出てくるけどほんまかいなと。

Java,や.NET使った上でそう判断してる現場もあるんだろうか。
いま.NETしか経験がないメンバーにtsを習得させるか、思い切ってBlazorに手を出しちゃうか悩み中。

**デフォルトの名無しさん** · 2020/10/12(月) 10:41:40.32

鯖サイドってOSコロコロ変わるイメージ無いんだけど、JVMにしろ.netにしろVMで動かす意味ってあるの？
GoとかRustで良いんじゃ無いかって思うんだが。

**デフォルトの名無しさん** · 2020/10/12(月) 10:56:21.63

>>627
.NET Core使っとけ

**デフォルトの名無しさん** · 2020/10/12(月) 11:29:41.17

Ruby on Rails では、Bootstrap, React だけど、
JavaScript(JS) に、Ruby の式を埋め込む、ERB を使って、JSへ変換する。
a.js.erb

<%= Rubyの式 %>

$( "body" ).append( "<%= j(render partial: 'example_partial') %>" );

こういう書き方で、TypeScript を使えるかな？

**デフォルトの名無しさん** · 2020/10/12(月) 11:39:26.90

>>628
むしろVM使ってるかどうかで言語を選択するケースのほうが稀

**デフォルトの名無しさん** · 2020/10/12(月) 11:47:16.30

>>627
TSに手を出すのとBlazorに手を出すのでは冒険度合いが違いすぎない？

**デフォルトの名無しさん** · 2020/10/12(月) 12:34:06.06

>>632
だよね…
こんなところで聞くことじゃないかもしれないんだけど、
サーバーサイドに記述されてるクラスって、フロントでも使えるの？
それともフロント側でもtypescriptで同じクラスを宣言しないといけない？
Blazorはクラスを共有できるくさくて…それはメリットとしてかなりでかいなあと。

**デフォルトの名無しさん** · 2020/10/12(月) 12:38:53.86

>>628
サーバーは言語何を使うとしても仮想化前提だろ。

**デフォルトの名無しさん** · 2020/10/12(月) 12:49:06.93

>>633
同じ言語だからクラス書いたファイルを両方から参照すれば良くない？
そういう意味でなくてサーバとクライアントでシームレスにインスタンスをやり取りしたいとかであればフレームワークが居るのでは？

**デフォルトの名無しさん** · 2020/10/12(月) 13:00:28.44

>>633
両方同じ言語なら共有ライブラリとしてそれぞれから参照すればいいけど
言語が違ってもOpenAPIみたいの使ってコード生成すればいいから
2度手打ちする必要はないかも

**633** · 2020/10/12(月) 13:15:11.55

ごめんごめん
サーバーサイドはasp.net coreです
OpenApiとやらを使えば、クラスの生成が楽ちんてことね…
しかし二度手間感はすごいあるな…
でもBlazorに手を出すリスクを考えるとまだマシか…

**デフォルトの名無しさん** · 2020/10/12(月) 13:38:59.49

Blazorも使ってるけど、まだ.NET5対応のツール周りが全然だめなんだよね…業務なら素直にTypeScriptでいいと思うよ

**デフォルトの名無しさん** · 2020/10/12(月) 15:15:45.91

over knight blazorくらいになってからが本番。

**デフォルトの名無しさん** · 2020/10/12(月) 15:31:28.54

>>631,634
だよね。
なのに何でJavaとC#何だろ？って思った。

**デフォルトの名無しさん** · 2020/10/12(月) 15:34:05.12

>>634
特に仮想化前提で遅くなるのに何で言語をネイティブコンパイラ言語にしないんだろ？と。
昔は実質C++しか無かったなら仕方ないとして、今なら選択肢はもっとあるのに・・・。

**デフォルトの名無しさん** · 2020/10/12(月) 15:46:11.22

Goのコードは高機能でファットなランタイムに依存している
ランタイムとアプリを分離できないだけで、実質VM言語みたいなものだ
一方、.NET Coreはアプリとランタイムを実行ファイルに全部ぶっこんで配布することも可能
従来のVM言語という線引きは曖昧になりつつある

**デフォルトの名無しさん** · 2020/10/12(月) 16:22:11.38

C#だとジェネリクス関連はJITに任せたほうが速かったりできるし、
.NET CoreはReady to Runでネイティブコンパイルされたコードを同梱することもできるぞ。

**デフォルトの名無しさん** · 2020/10/12(月) 18:07:07.48

あー・・・。
そう言えばC#はネイティブにもコンパイル出来るようになったんだっけ・・・。
C#については納得。

Javaはまあ、コード資産だろうし。

**デフォルトの名無しさん** · 2020/10/12(月) 18:13:15.12

JITについては正直半分くらいしか信じてないんだけど、あり得なくは無いなと思ってる。
Dや一部のC++みたいにコンパイル時実行での最適化とどっちが速いんだろうとか思う。

**デフォルトの名無しさん** · 2020/10/12(月) 18:27:26.57

>>643
ジェネリクスってコンパイル時に解決するものだと思ってた

**デフォルトの名無しさん** · 2020/10/12(月) 18:58:23.00

TypeScript part3

**デフォルトの名無しさん** · 2020/10/12(月) 20:08:52.47

>>645
コンパイル時の方が多少早いけど、cppのジェネリクスもといテンプレートは型の分関数を用意するって愚直な方法をとってるので、バイナリサイズがデカくなる。
型情報も使えないしね。
あと、分岐命令なんかはどっちのほうが頻度高いかとか見て、動的にプロファイル取りながら最適化しつつ実行してるので、JITの方がより良い形になる事もある。

>>646
コンパイル時に解決はしてるけど、ILレベルでは複数の関数が作られてる訳ではなかったはず。
もちろん実行時には、JITで型ごとに関数が生えることもある。

**デフォルトの名無しさん** · 2020/10/12(月) 20:18:21.71

>>648
そゆことね。なるほど

**デフォルトの名無しさん** · 2020/10/12(月) 21:17:35.13

モダンC++対マネージコード：パフォーマンス対生産性
https://www.infoq.com/jp/news/2012/04/native_vs_jit/

**デフォルトの名無しさん** · 2020/10/12(月) 22:34:15.13

>>625
型はトモダチ…！

**デフォルトの名無しさん** · 2020/10/12(月) 22:37:04.59

質問なのですがTypeScriptでC++みたいに関数引数をconstにするにはどうすれば
良いの？

**デフォルトの名無しさん** · 2020/10/12(月) 22:47:48.13

>>648
>あと、分岐命令なんかはどっちのほうが頻度高いかとか見て、動的にプロファイル取りながら最適化しつつ実行してるので、JITの方がより良い形になる事もある。
ﾃﾞﾏくね…？
プロファイル取る手間はタダじゃないし、

**デフォルトの名無しさん** · 2020/10/12(月) 23:49:02.74

>>652
eslint no-param-reassign

**デフォルトの名無しさん** · 2020/10/13(火) 00:53:50.25

Ruby では、1秒で100万回ループすると、

JIT されて、1秒で1,000万回ループされる

**デフォルトの名無しさん** · 2020/10/13(火) 06:14:03.47

>>651
型はトモダチ！(ﾟ∀ﾟ)

**デフォルトの名無しさん** · 2020/10/13(火) 07:33:03.58

>>653
どっかで読んだけどな。
というか、AOTの制限事項として、JITより効率が悪い可能性の一つとして挙げられてるよ。

**デフォルトの名無しさん** · 2020/10/13(火) 17:57:10.11

(´･ω･`) webpack v5 ……

**デフォルトの名無しさん** · 2020/10/13(火) 21:41:54.07

>>654
「Invalid option '--param-reassign'」って言われたつ∀`；)
ESLint: 6.5.1.

ていうかできたとして無差別にconnstというのもそれはそれでC++と違う希ガスorz

**デフォルトの名無しさん** · 2020/10/15(木) 17:16:37.21

webpack@5、めっちゃ破壊的やん…

**デフォルトの名無しさん** · 2020/10/15(木) 17:39:38.69

>>659
お前の目はフシアナか？
https://eslint.org/docs/rules/no-param-reassign

ていうか引数に再代入するガイジなんて必要ないから無差別にエラーで構わんやろ

**デフォルトの名無しさん** · 2020/10/31(土) 19:19:55.76

JavaScriptからTypeScriptへの書き換えｵﾜﾀ＼(^o^)／
JavaScrpit最初に知って一ヶ月で全部書いたから3000行ぐらいだろうと思っていたら
あとでちゃんと数えたら8790行やったorz
実作業4日かかった
ここで4日というのは4日×8Hではなくて4日×24Hの意m（ｒｙ

**デフォルトの名無しさん** · 2020/10/31(土) 19:27:20.93

乙
TypeScriptやってない頃に書いたコードってTypeScriptのこと意識してなくてオブジェクトの形を動的に変えたりしない？
自分がやったときはそのせいでだいぶ時間かかったわ

**デフォルトの名無しさん** · 2020/10/31(土) 19:31:22.31

prototype文で無理矢理classにしていたやつを
さらに基底クラス（にあたるﾌﾞﾂ）の所有でもって継承を表現していたやつの普通のclassと継承への書き換えが苦痛やった、
機械的とはいえ自動化できるほど単純には行かず苦痛やった、
手製イベントのインターフェースが実際何になるのかがぐちゃらけていたので3種類のインターフェースのORで
表現できるとﾜｶﾙまで試行錯誤を要した、
あとはだいたいうまいぐあいに逝けた
とわいえVSCodeの強力なインテリセンスとリアルタイムエラー報告（スクロールバーのところが赤くなるやつ）が無かったら
到底完遂不可能なところやった、、、
webpack使用

**デフォルトの名無しさん** · 2020/10/31(土) 19:34:13.19

おめでとう

**デフォルトの名無しさん** · 2020/10/31(土) 21:54:44.53

ウンコードなJSをTSに変えることで人は強くなるのだ
おまえはまた強くなった

**デフォルトの名無しさん** · 2020/11/01(日) 08:10:24.39

委譲から継承に切り替えたらそりゃ辛いっしょ。
乙～

**デフォルトの名無しさん** · 2020/11/02(月) 00:59:20.76

delegation over inheritance って言うしな

**デフォルトの名無しさん** · 2020/11/06(金) 22:00:05.98

GithubでもTsは定義箇所にジャンプできたりするんだな
強い

**デフォルトの名無しさん** · 2020/11/09(月) 19:43:09.64

今からTypeScriptやるならDenoでいーの？
あっギャグじゃないです真面目な質問

**デフォルトの名無しさん** · 2020/11/09(月) 21:13:08.03

作った本人はデノって発音してるように聞こえる

**デフォルトの名無しさん** · 2020/11/09(月) 21:43:52.92

Denoあんまり詳しくないけど、何やりたいかにもよると思う
Web開発をする分にはまだNodeなんじゃないかな
周辺のツールやライブラリが揃ってるので
CLIツールとかならDenoでいーんでの？

**デフォルトの名無しさん** · 2020/11/11(水) 11:00:58.08

>>669
jsx/tsx でもイケるようになったね

**デフォルトの名無しさん** · 2020/11/17(火) 22:53:14.47

https://ncjamieson.com/prefer-interfaces/
https://github.com/microsoft/TypeScript/wiki/Performance

以前 type 推しの人がいたけどやっぱり interface か…

**デフォルトの名無しさん** · 2020/11/20(金) 14:22:41.76

Announcing TypeScript 4.1
https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/

**デフォルトの名無しさん** · 2020/11/20(金) 21:01:29.75

どんどん複雑になるなぁ
ついていけまへんわ

**デフォルトの名無しさん** · 2020/11/20(金) 21:22:14.83

逆にバージョンアップでシンプルになっていく言語ってあるの？
互換を完全に切るような言語なら可能だろうけど

**デフォルトの名無しさん** · 2020/11/20(金) 21:41:42.91

>>677
Schemeが小さくはなったな
ま、大規模に使われてる言語じゃないから出来る芸当だ

**デフォルトの名無しさん** · 2020/11/20(金) 21:44:46.30

言語機能が増えたからと言って全部使う必要はないしな
たまにどこかで使われてるのを見てあれってなったら調べるくらいで良い

**デフォルトの名無しさん** · 2020/11/20(金) 21:50:47.55

JavaScriptは動的型だけど、動的型は意識しなくても複雑な事が出来てしまう
TypeScriptはそれらに対して何としてでも型を付けたいんだよ
それだけの事
JavaScript自体は何も変わってない

**デフォルトの名無しさん** · 2020/11/20(金) 23:06:21.09

もうaltJS風WebAssemblyコンパイラにして

**デフォルトの名無しさん** · 2020/11/20(金) 23:26:29.58

>>681
つ AssemblyScript

**デフォルトの名無しさん** · 2020/11/21(土) 01:50:51.61

コンパイラ型ほ生産性低いよ。

**デフォルトの名無しさん** · 2020/11/21(土) 04:03:36.16

template literal typesなんていれるから
型レベルSQLとかおかしな事やり始めてるし
https://github.com/codemix/ts-sql

**デフォルトの名無しさん** · 2020/11/21(土) 09:57:45.60

くっそ遅くなりそう

**デフォルトの名無しさん** · 2020/11/21(土) 10:46:50.16

C++並にコンパイル遅くなったりしてね。
実質マクロだから実行時は速いんちゃう？

**デフォルトの名無しさん** · 2020/11/21(土) 10:54:34.52

>>678
あれ小さくなったって言えんの？
r7rs なんて common lispよりでかいじゃん。
コアだけなら小さいだろうけどコアだけじゃなんもできんだろ。

**デフォルトの名無しさん** · 2020/11/21(土) 12:06:56.10

うちのtsプロジェクト、tslintも入れてビルドに10分くらいかかってる。
前に -incremental 試してみてなんかの理由で断念したんだよな。
もう一度トライしてみるか。

**デフォルトの名無しさん** · 2020/11/21(土) 12:34:04.91

スクリプトのメリット完全に失っててワロタ
スクリプトはビルドしちゃいけないんだよ
IDEでパラレルLintするぐらいならいいけどな
ビルドしないと動きませんじゃ本末転倒でなにがなんだか
ビルドするならC#とかGoでやりゃいい

**デフォルトの名無しさん** · 2020/11/21(土) 13:16:27.04

ts-nodeならビルド不要だけど、それとは違う話か
TypeScriptを直に実行できる処理系は今後も現れないだろうな

**デフォルトの名無しさん** · 2020/11/21(土) 13:30:05.02

>>689
＞ビルドするならC#とかGoでやりゃいい
ブラウザで使うのが現実的じゃない

**デフォルトの名無しさん** · 2020/11/21(土) 13:42:58.96

Dart始めました

**デフォルトの名無しさん** · 2020/11/21(土) 14:02:54.86

そもそもスクリプト言語でスクリプト言語向きじゃない大規模なことをやろうとしてるからこれができたわけで、言語のせいにするのは違う
そもそも今のWeb（アプリ）はTS使ってなくてもビルドしてるものばっかりだし

**デフォルトの名無しさん** · 2020/11/21(土) 14:35:34.39

まあ、べつに「スクリプトのメリット」を期待してtsを使ってるわけじゃないしな。
とはいえビルド時間が短縮できるならそれに越したことはないが。

**デフォルトの名無しさん** · 2020/11/21(土) 15:32:21.74

watch使うからビルド速度そんなに気にならないなぁ

**デフォルトの名無しさん** · 2020/11/21(土) 18:31:06.90

>>687
RSR7-smallは5をベースにしてるから、それでなんも出来ないとか言ったら、それまでのSchemeを全否定じゃんw

**デフォルトの名無しさん** · 2020/11/21(土) 18:58:48.16

いっそガチでマクロ入れてくれたら色々捗るなぁ。凄く読みにくくなるだろうけど。
そこまで行かなくとも、（内部的に複数の関数を持つ）関数オーバーロードとか欲しいかも

**デフォルトの名無しさん** · 2020/12/18(金) 05:11:45.78

ブラウザ使っててよく Webページが固まることがあるから、ちゃんとUIスレッド以外で処理しろよとよく思ってたが
JavaScript 自体がシングルスレッドだったのね

WebWoker とかいうのもあるみたいだが、MDN見るに、
言語側でがっつり管理するからスレッドセーフあんまり考慮しなくてもいいみたいだし、これは楽でいいわ

Java やってて、クリティカルセクションの処理が一番嫌いだった
デッドロックの原因探すの大変すぎた

**デフォルトの名無しさん** · 2020/12/18(金) 05:52:13.96

そもそもIO待ちにスレッドを使うのがナンセンスだったんだよな

**デフォルトの名無しさん** · 2020/12/18(金) 07:23:19.35

まぁでも、

JavaScript のソースコード内に書いたものが全部同じスレッドで走ってる

ってだけで、setTimeout とかの実装内では普通に別スレッド走ってるのか。
そりゃそうだよな、そうしないと非同期処理なんてどうあがいても不可能だものね。

**デフォルトの名無しさん** · 2020/12/18(金) 09:04:21.16

非同期処理はスレッドの場合とそうでない場合の2種類ある
そうでない場合は基本的にハードウェア割り込みで実装されてる
タイマーとか通信処理とか
ファイルアクセスもOS毎に非同期APIが有るけど、libuvは互換性の為に敢えて同期APIを使う処理をスレッドプールに投げているようだ

**デフォルトの名無しさん** · 2020/12/18(金) 09:10:54.87

setTimeoutはスレッドを使ってない様に思うけど、結局の所ユーザー側でそれを知る術が無い

**デフォルトの名無しさん** · 2020/12/18(金) 12:01:30.61

>>698の問題はスレッドがどうとか関係なくて、html中のある個所の内容が決まらないと
全体のレンダリングができない構造になっていたとか、jsをダウンロードしないと
レンダリングされないのにその取得に時間がかかっているとかそんなところだろうな。

**デフォルトの名無しさん** · 2020/12/18(金) 13:13:24.97

最近ないように思うけど、１つのページがブラウザ全体をストールさせることが多かったのよ
そんでブラウザを起動し直さなければいけない

その原因が、JS のスレッドとブラウザのレンダリングスレッド（UIスレッド）が同じスレッドを共有してることにある

DOM 書き換えてる最中にレンダリングされちゃうと、ページレイアウトがぐちゃぐちゃになるから、全部同じスレッドで処理してるんだけど、
JSの処理でUIが固まるのを防ぐには、JS の DOM 書き換え「以外」の操作を別スレッドでやって、レンダリングスレッドと同期処理すればいい
（Java の synchronize とかの要領）

DOM 自体がレンダリングスレッドに属してるのは、しょうがないと思う
昔、マルチスレッドで動作する UI ライブラリの多くがデッドロックその他のバグでどうにもならなくなって廃棄された（Java でいう AWT）

ということで、UI が固まるのにはスレッドは関係あると思うのよ
まぁ書き方が悪かったのかもしれんが

あと、JS がシングルスレッドなのはとても良いことだと思ってるからね、自分は
マルチスレッド化したら、どのみち同期化処理に失敗して、デッドロックで今よりも固まること多くなるだろうから

参考にした：
https://stackoverflow.com/questions/30932870/why-doesnt-javascript-get-its-own-thread-in-common-browsers

**デフォルトの名無しさん** · 2020/12/18(金) 13:18:46.36

JS で重めの処理をしたりバグがあっても、レンダリングスレッドと分離されてれば、
少なくとも UIが固まることはないということね（デッドロックがなければ）

あと、上で最初に書いた、ブラウザ全体が固まるって話は語弊あったかもしれない

ブラウザの各タブのレンダリングスレッドと、ブラウザ全体のUIスレッドは、多分分けられてるんだよね？
後でちゃんと調べます

**デフォルトの名無しさん** · 2020/12/18(金) 13:30:26.86

firefoxがフリーズすることは最近ちょくちょくあったな
edgeに乗り換えたらきれいさっぱり直った
ffはもうだめかもわからんね

**デフォルトの名無しさん** · 2020/12/18(金) 16:42:31.82

https://gimhana-ds.medium.com/how-firefox-and-chrome-use-process-and-threads-f58f478561f0

ブラウザのスレッドの話ココに載ってた
いろいろとたどってって疲れたので、全部は見てない

Chrome が Tab ごとにプロセスで、Firefox が Tab にマルチスレッド

Firefox もいっぱいプロセス作ってるけどね、ちゃんと読んだ人教えて

**デフォルトの名無しさん** · 2020/12/18(金) 16:44:48.76

「Firefox が Tab ごとにスレッド」って書きたかった

そのスレッドも Main Thread = UI Thread （DOM 操作と JS 実行）が１個って意味で、
Raster Thread とか、Composer Thread とか多分他にもいろいろスレッド作る

**デフォルトの名無しさん** · 2020/12/18(金) 17:50:47.93

すみません、TypeScriptって開発中はコンパイルなしでブラウザですぐに変更の動作確認をできますか？

**デフォルトの名無しさん** · 2020/12/18(金) 19:33:24.14

そういう時代が来るといいね

**デフォルトの名無しさん** · 2020/12/18(金) 19:42:28.67

Chromium Edge で、YouTube を見て、

動画を、5秒先へ進めたりすると、フリーズする

**デフォルトの名無しさん** · 2020/12/18(金) 21:47:42.98

WebWorkerは完全にスレッドだぞ
更にAtomicsを使えばスレッド間でatomicなデータ更新が出来る

**デフォルトの名無しさん** · 2020/12/18(金) 21:53:39.89

WebWorker使いやすくて好き。並列処理面倒くさいからたまにしか使わないけど

**デフォルトの名無しさん** · 2020/12/18(金) 22:14:36.51

しかし、SharedArrayBufferはSpectreのせいでほぼ使えない状態だけどね
Spectreに対応したCPUが普及しきらない限り有効にされる事は無い
Webではもはや余計な機能追加はセキュリティーホールの元という認識でこれ以上進化することも無いだろう
ただ、ストアからインストールするPWAはネイティブアプリの代わりだから、機能追加していくと思われる

**デフォルトの名無しさん** · 2020/12/18(金) 23:02:27.28

ストアの収益減らすの絶対許さないマンのアップル
ｖｓ
Webから情報吸いたいマンのグーグル

**デフォルトの名無しさん** · 2020/12/19(土) 13:35:36.37

promise（もしくはasync/await）が使えたらシングルスレッドでも実質別段困らない
希ガス

**デフォルトの名無しさん** · 2020/12/19(土) 15:04:10.72

WebWorkerとか知らんかった．．．
メインと状態を共有しないのが明確なら便利そうだな
さもなくばAsync/Awaitか

**デフォルトの名無しさん** · 2020/12/19(土) 15:41:20.87

I/O boundはPromiseでいいけど
CPU boundはPromiseじゃだめだからWebWorker使う
マルチコアの有効活用