少し前、何気なくTwitterを見てたらこんなツイートを発見。 Googleの内部のWebフレームワーク…？ 起動時はアプリのJSを読み込まない…？ インタラクティブになったときにコードをダウンロード…？ ツイートしてるのはGoogleでLitを開発しているJustinさん。この技術をLitに活かせないか模索するとツイートしてる。 Litの開発をされている方なので、Litを違う名前で読んで遊ぶアイロニーとかユーモアみたいなものかな、フロントエンドはピュアなJavaScriptをvanillaって言うしな、なーんて思ってたら・・・ AngularのIgor MinarさんもWizが存在しているかのように話している？！ そして… Igorさんが「QwikはWizのOSSとしての再実装」と書くと、そこにAngularJSの作者であり、現在Builder.ioでPartyTownやQwikなどを開
TL;DR: Closure Library will be sunset over the next 9 months, from November 1, 2023, to August 1, 2024. We no longer see it as meeting the needs of modern JavaScript development, and we recommend that users look for alternative solutions. Feel free to skip the background and go straight to the FAQ. In the nearly 14 years since Closure Library was first made public, it's broken a lot of ground and
Interesting read. I wrote the original compiler back in 2002/2003, but a lot changed by the time it was open sourced (including the confusing name -- I just called it a javascript compiler).One detail this story gets wrong though is the claim that, "The Gmail team found that runtime JavaScript performance was almost irrelevant compared to download times." Runtime performance was actually way more
Here's something that makes me feel old: in just six months, Gmail will celebrate its 20th anniversary. If you weren't actively developing web sites at the time, it's hard to capture just how revolutionary it was. This was a time when JavaScript was held in almost universally low regard. The idea that you could build a sophisticated web app using it was mind-boggling. But it clearly worked and it
TypeScriptの型定義ファイルから積極的な圧縮を行うための @mizchi/optools をリリースした。まだ実験中だが、結構動くはず。使う場合は自己責任で。 追記: optools を packelyze に rename した。これは optools という CLI 名が ImageMagick の提供するコマンドとぶつかったため。 試行錯誤の過程は https://zenn.dev/mizchi/scraps/1bdf01f5efb147 にある。 このライブラリは、自分の所属する Plaid の業務時間中に作成した。 想定ユーザー ライブラリ作者 ビルドサイズ厳しいフロントエンド開発者(サードパーティスクリプト等。自分が業務で作った理由がここ) リスクとってでもビルドサイズを縮めたいフロントエンド作者 動機 世の中な TypeScript で書かれたコードは、その型情報を使
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
TypeScriptの主要な入力ファイルは .ts, .tsx, .mts, .cts ですが、JavaScriptファイル (.js, .jsx, .mjs, .cjs) も読み込んで処理することができます。JSDocによる型アノテーションを認識するため、生のJavaScriptでもそれなりに型をつけることができます。 本稿ではタイトル通り、TypeScriptのJSDocサポートでできることとできないこと (.ts でしかできないこと) をまとめます。 おことわり 本記事はTypeScript 4.4時点での実装状況に基づいています。なるべくソースコード中の関係する箇所を参照するようにしたので、今後の変更はご自分で検証してください。 (TypeScript Playgroundで試すだけでも有用です JavaScriptモードで開始できるリンク) JSDocの機能一覧・TypeScri
普段から TypeScript で開発されているほうならば、TypeScript の恩恵を十分に堪能されていることと思います。 特に私は VS Code のインテリセンスには頼りっぱなしでこれがなければまともにコーディングができない体になってしまいました。 しかし時には、TypeScript という概念が存在しない退屈な世界で開発を行わなけらばならない状況はあるでしょう。私はもはやキーボードでタイピングすることすらままなりません。 そんな JavaScript しか利用できない状況で代替手段となるのが、JSDoc です。JSDoc のアノテーションによって型を付与することによって最低限の支援を受けることができます。 @Type @Type タグを使用すると、TypeScript で型をつけるときと同じように型を宣言できます。
In our introductory blog post, we covered how we've learned a lot while building and using frameworks and tools to develop and maintain large scale web applications such as Google Search, Maps, Photos, and so on. By safeguarding developers from writing code that can negatively affect user experience, we proved that frameworks can play a key role in shifting outcomes for performance and application
This post is part of a series of blog posts describing the changes we are making to DevTools' architecture and how it is built. Following up on our migration to JavaScript modules and migration to Web Components, today we are continuing our blog post series on the changes we are making to Devtools' architecture and how it is built. (If you have not seen it already, we posted a video on our work of
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く