TypeScript 10年の歩み - Qiita
TypeScriptは、2022/10/01に10周年を迎えました。 ということで、それを記念してMicrosoftの中の人が振り返りのエントリーを書いていました。 以下は該当の記事、Ten Years of TypeScriptの紹介です。 Ten Years of TypeScript 2022年10月1日は、TypeScript10歳の誕生日です。 10年前の今日、2012年10月1日に、TypeScriptは初めて公にされました。 The Early Days 初めてTypeScriptが表に現れたとき、それももっともなことでしたが、多くの否定的な意見がありました。 一部のJavaScriptユーザにとって、JavaScriptに型を強制する試みは冗談か邪悪な陰謀のように見えたかもしれません。 しかし、その試みには、多くのメリットがありました。 型チェックのおかげで、ファイルを保存
Flat Config導入完了！ 新しいESLintの設定フォーマットを使ってみた
皆さんこんにちは。株式会社バベルでエンジニアをしている uhyo です。バベルが提供しているaileadというプロダクトでは TypeScript が多く使われており、ESLint も活用されています。この記事では、ailead のコードベースにおいて ESLint の新しい設定フォーマットであるFlat Config (eslint.config.js)を導入した事例を紹介します。 Flat Config とは？ Flat Config については、ESlint 公式ブログでも詳しく説明されています。 ファイル名がeslint.config.js固定であり、必ず JavaScript で書かなければいけないのが特徴です。新しいフォーマットでは、従来の設定ファイル（.eslintrc{.yml,.json,.js}）で辛かった部分が解消されています。特に、設定内容の解決にあたって ESLi
JavaScript の undefined と null を完全に理解する
JavaScript で頻出する undefined と null について語ります。 言語仕様上の違い JavaScript (ECMAScript) において、仕様上 undefined と null は当然ながら明確に区別されています。いくつか言語仕様上の扱いについて挙げてみます。 比較 厳密な比較演算子 === において undefined と null は区別されます。ゆるい比較演算子 == においては両者は区別されません（仕様 7.2.14）。 console.log(undefined === null); // false console.log(undefined == null); // true 他の falsy な値（false とみなされる値）との比較は、ゆるい比較演算子であっても区別されます（仕様 同上）。 console.log(undefined == fa
JavaScript/TypeScript の Lint ツールを XO で統一した - ドクターズプライム Official Blog
@1000ch (id:hc0001) です。掲題の通り、少し前にドクターズプライムの Frontend プロジェクトで使う lint ツールとして ESLint ではなく XO を使っていく方針に切り替えました。最近その振り返りを行ったので、その備忘録として文字に起こします。 github.com 経緯と課題 これまでは Create React App に付属する ESLint に加えてルールを少しカスタマイズして、それをいくつかのプロジェクトで使っていました。これにはいくつかの課題が存在していました。 ESLint およびその周辺プラグインの依存関係を含めたバージョンアップをケアし続ける必要がある renovate や dependabot などを用いて（半）自動化できるものの、依存の数や大きさに応じて依然としてコストが高い ESLint のルールを中長期的にメンテナンスする必要があ
CoffeeScript 辞めました - クラウドワークス エンジニアブログ
CoffeeScript 辞めました はじめに こんにちは、CrowdWorks のジャンヌチームのエンジニア bugfire です。 CrowdWorks は歴史のあるサービスで CoffeeScript が利用されている箇所が大量にあります。 具体的には411ファイルありました。1 いまとなっては CoffeeScript を利用したコードを新たに書くことも少なくなり、改善するときに TypeScript で書き直されることも多くなってきました。しかし、個別に変換すると時間が掛かってしまうため、まとめて機械的に変換することにしました！ 3行まとめ CoffeeScript より TypeScript の方に記述を移していきたい。 利用している Sprockets の CoffeeScript 変換コードを借用して全ファイルを変換しました。 確認は変換前後の出力 JavaScript コ
プロを目指す人のためのTypeScript 本の感想 #ブルーベリー本
自分も教える事が多いので、読み手にどういう風に学んでほしいか、自分がどういう風に伝えるべきか、という視点で読んだ。 1章・イントロダクション そもそもTypeScript とはなにかみたいな話。 コンパイルエラーが出ている状態ではプログラムが完成したとは言えません。 力強い コンパイルエラーをただ避けるのではなく、利用する気持ち で TypeScript プログラミングに臨みましょう。 初心者に型違反の向き合い方を諭す話。IDEの補助になるとか。 TS年表で取り上げてるのが特徴的。exactOptionalProperty を取り上げてたり。 TSの型はランタイムに影響しない、という話を何度も解説している。これは初心者の誤解がとても多いので、必要だと思う。何度いっても、伝わって欲しい人に伝わらないのだが… enum や namespace については意図的に解説しない。過去のTS独自路線だ
JestのTips集10選。サーバーサイドでNode.jsのJestを書いたことない人向け
対象 業務レベルでサーバーサイドでJestを書いたことはないけれど、新プロジェクトでは書くことになったみたいな方を想定して記述しています。 Jestについては中々ベストプラクティスが集まりにくいので、経験的にこう書くと「きれいに」・「早く」・「正確に」書けるよというTipsを集めてみました。もし、よろしければお読みください。 前提 TypeScript Node.js Jest DBアクセスありの状態を想定しています 1. it文内では、必ず1回は、expectをつかって検証をする JestのPRをレビューしてるとたまに見受けるのですが、expectを使ってないケースがあります。 // NG it('userを正常に、作成できること', async() => { await createUser({ name: 'Mike' }); }); // OK it('pdfが正常に削除できること
僕らを縛る Node.js という呪いについて
これ僕らの物語であり、僕と君の物語であるかもしれない。 数日前、友人が言った。「久しぶりに Rails を書いたけれど、Node.js の良さに敵わない」と。 その言葉に同意しながらも、他方で少し不思議に思う。 いつから僕らは Node.js しか使わなくなったのか。あれだけ話していた Rails などの多くの Web 技術にときめかなくなったのか。と。 もちろん、使えないというわけではない。寧ろ今現役で十分な活躍をしているフロントエンドの人間は、等しく皆「主役であるバックエンドのサブとして存在するフロントエンド」を経験してきている。 書こうと思えば書ける。だがその中で、敢えてフロントエンドとその技術を選んできた。 だけど今はどうだろう。フロントエンドエンジニアはもはや「JavaScript を扱うソフトウェアエンジニア」となり、一般的なバックエンドは勿論、Node.jsが一級市民として存
どのようにTypeScriptを使うのか - uhyo/blog
現在、TypeScriptの重要性は、フロントエンド開発を中心としてますます増すばかりであります。それだけに、TypeScriptをどのように使うべきかという問題については多様な意見が見られます。 これまで筆者はTypeScriptの使い方に、特にコンパイラオプションの使い方について意見を散発的に発信してきましたが、このたび記事にまとめました。この記事では、特に次のような意見に対しての反対意見を述べます。 厳しいコンパイラオプションは型パズル愛好者のためのものであり、普通の人は細かいことを気にせず緩い設定でよい。熟練のJavaScript使いにはTypeScriptは必要ない。例え話最近はTypeScriptを補助輪に例えたりするのが流行っていますので、この記事でも例え話をしてみます。筆者の考えでは、TypeScriptというのは例えるならば料理人が使う包丁のようなものです。コンパイラオプ
アンサー: named exportは有害なのか - uhyo/blog
こんにちは。ここ数日は、以下の記事が話題になりました。 named exportは有害だと考えられます「named exportは有害」という主張はこれまで常識と思われていたこととは異なるため、界隈のエンジニアからは否定的・懐疑的な意見が見られます。実際、筆者もnamed exportが有害であるとは1ミリグラムも思っていません。 しかし、自分と異なる意見は当然に下等・幼稚なものであるというのは筆者が最も嫌う考え方ですから、このような異なる意見を分析・理解する必要があると思い、アンサー記事という形でまとめました。具体的には、異なる意見に達する理由としては前提が異なることと論理が異なることが主に挙げられます。前提が異なることが分かれば、自分と異なる意見に至った理由を理解でき、場合によっては取り入れることもできます。論理が違うのであれば、それは瑕疵であり指摘しなければいけません。 なお、そもそ
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
JSフレームワーク事情2020年始め｜erukiti
この記事では面倒なので名前に .js が付いているものは省きます。例えばNext.js は Next と表記します。 まず結論から日本ではVueはReactと二分する人気があるように観測されますが、世界的な数字で人気・シェアを見るとReactが圧倒的です。 シェアだけで見るとAngularとAngularJS（Angular系の1.x系）の合計値はVueよりも高いですが、「今後はもう採用したくない」と考える率が高く、Angular/AngularJSの人気が低下しているということは間違いありません。 ※追記: Angularのシェア、人気度に関しては、Angular及びAngularJS両方を含む数値であり、AngularJSとAngularは別物であるものが混ざってカウントされているため、Angularのシェア及び人気度はあやふやかもしれません。他の数値に関して信頼性を疑うべきかどうかは
YYTypeScript#1「JavaScriptを知らない人がTypeScriptを学ぶ方法を知りたい」「TypeScript初心者がどうやって勉強すると効率がいいか？」「なぜTSが選ばれるのか？」「PHPと比べて、サーバサイドをTSで書くメリットは？」「TypeScriptのバックエンドのオススメフレームワークって？」「定義をinterfaceとtypeどっちで書いてる？」「JSで書かれたプロダクトのTS化ってどうしてる？ 」 - Qiita
YYTypeScript#1「JavaScriptを知らない人がTypeScriptを学ぶ方法を知りたい」「TypeScript初心者がどうやって勉強すると効率がいいか？」「なぜTSが選ばれるのか？」「PHPと比べて、サーバサイドをTSで書くメリットは？」「TypeScriptのバックエンドのオススメフレームワークって？」「定義をinterfaceとtypeどっちで書いてる？」「JSで書かれたプロダクトのTS化ってどうしてる？ 」PHPJavaScriptTypeScriptYYTypeScriptイベントレポート これは2019年9月20日に開催したTypeScriptイベントYYTypeScript#1のイベントレポートです。 YYTypeScriptは一言で「TypeScripterの部室」です。発表者の話を聞く「一方向的な勉強会」とは真逆で、TypeScriptについて、雑に・ゆる
型チェックは TypeScript や Flow じゃなくて JavaScript にやらせる。 - Qiita
TypeScript不要論：型チェックは TypeScript や Flow じゃなくて JavaScript にやらせる。JavaScriptflowTypeScriptflowtype 開発効率のために型チェックを望む JavaScript が動的型言語なので、静的型言語にしてしまえば開発効率があがる、というアイデアがあって、それは確かなことかとも思います。プログラムを書いていて、ある変数の型がよくわからなければ正確な処理を行わせるのって、難しいですよね。 確かに開発効率、あがると思います。 実際に自分も開発効率をあげています。しかし、型チェックは行っていますが、TypeScript や Flow とかは使っていません。 TypeScript や Flow が人気を得てきていますが、そこで行う型チェックは、素のJavaScriptにやらせてしまうこともできるので、導入前に検討してみるの
TypeScript教育用コンテンツ公開のお知らせ | フューチャー技術ブログ
2019年頭より少しずつ書いていたTypeScriptの教育コンテンツをクリエイティブ・コモンズ4.0の表示 - 継承 （CC BY-SA 4.0）で公開します。といっても完成版ではなく、アーリーアクセス版のような品質であることをご了承ください。 仕事ですぐに使えるTypeScript Web版に加えてPDF版もダウンロード可能です。 そもそもこの資料を書き始めたきっかけですが、フューチャーのようなB2Bな会社であっても、最近はフロントエンドの比重が高まっているところから出発しています。僕もフューチャーに転職後からReactでがっつり1年以上の案件をやったり、半年ぐらいのAngular案件をやったりしています。会社としてはVue.jsを推しています。グループ会社の東京カレンダーはReactを使っていたりもします。要件に合わせていろいろですね。B2B2Cな案件も多いですし、お客様の求めるUX
JavaScript/TypeScript で Promise を直列実行できるが、結局どう実装すればよいのか？（可読性・実行速度） - Qiita
単位は byte es2016以下の場合 async/await を使用した場合、トランスパイルで polyfill が挿入される よって、 async/await を使用しなければ、polyfill 分のサイズを削減できる ただし、その他の実装でも一切 async/await 使ってない場合に限る src全体で見て、他の実装で async/await を使っている場合、その実装のために polyfill が挿入される そのため、直列実行の実装を工夫しても polyfill 分のサイズは必ず増える es2017以上の場合 いずれの実装も、polyfillは挿入されない よって、書いたコード分のファイルサイズになる 所感 まぁ、妥当な結果 ベンチマーク 各 target の出力結果の JavaScript を実行 1 スレッド、100 Promise の直列処理 * 5 回計測の平均 es5
JavaScript/TypeScript で Promise を直列実行する - Qiita
2019/05/19 追記 パフォーマンス測定した JavaScript/TypeScript で Promise を直列実行できるが、結局どう実装すればよいのか？（可読性・実行速度） 目的 複数の Promise を直列実行したい 同期的実行・シーケンシャル・シリアルなど呼び方色々あるが、とにかく Not 並列に Promise[] を実行したい Promise.all のような書き心地がいい 技術的な正しさを追求した記事ではなく、雰囲気で使いこなせることを優先した記事である 動作イメージ この記事に出てくるサンプルコードについて Promise, async/await はなんとなくわかってる人向け axios で書いている 標準の fetch は、ボイラープレートコードが読みづらい・この記事の本質から外れそうなのでやめた よって、試す場合は jsfiddle などで実行のこと やりす
@typescript-eslint ことはじめ - teppeis blog
追記: 2019/05/01 最近の@typescript-eslint/eslint-plugin, Prettierのアップデートによって、正式にTypeScript 3.4対応されました。一通り普通に動いてる感じ。 これまで自分で使っていて問題になったのがパフォーマンス。ESLint単体やTSLintに比べて、プロジェクトによるだろうけど2倍以上遅い。体感で結構辛い。 Poor performance on some projects · Issue #389 · typescript-eslint/typescript-eslint これはTypeScriptのパーサーを通す部分の構造上の問題が原因なので、簡単には直せなそうな気配。 とりあえず、個人的には型を必要とするルールにそこまでの価値を感じていないので、該当ルールを無効にしてparserOptions > projectを削
なぜTypeScriptに失望してしまうのか - Islands in the byte stream
追記: この件に関してエンジニアHubにもTypeScriptの記事を書きました: TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に - エンジニアHub｜Webエンジニアのキャリアを考える！ TypeScriptに対する失望は2パターンあって、その理由は理解できるのですが、いずれにせよそこでTypeScriptを捨てる判断をするのはもったいないと思っています。この2つの失望を感じたとしてもなお、TypeScriptには導入する価値があると思っています。 パターン1: 実はJavaScriptに対する失望である そこらのブログやTwitterで観測していると、理由の7割くらいこれです。これは、TypeScriptが独立した言語ではなくJavaScriptへのトランスパイラ（言語変換ツール）であり、独立したランタイムを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScriptのCollection操作をする時はお願いがある、一呼吸置いてから操作をしてくれ
