タグ

関連タグで絞り込む (203)

タグの絞り込みを解除

*Javascriptに関するAkinekoのブックマーク (2,080)

  • QwikとPartytownでJavaScriptを99%削減する方法 | POSTD

    うれしいことに、builder.ioのホームページは今やモバイル端末でもPageSpeed Insightsで100点中100点をとれるようになりました。 これはQwikを導入したおかげです。 Qwikはアプリケーションの規模に関係なく高いパフォーマンスを実現します。 上記のスコアは、以下の優れた技術によって達成されました。 Qwikで提供されるページの起動に必要なJavaScriptは1KB未満 ホームページは画面上の領域のコンテンツに必要なHTMLのみを送信 Partytownを利用し、すべてのサードパーティスクリプトをWeb Workerに移動 builder.ioの視覚的なノーコードエディタを利用してサイトを作成 Qwikは、数百のコンポーネントや数MBのコンテンツを有する大規模なサイトでも高速なパフォーマンスを実現します。 また、クライアントコンポーネントに移動できるインタラクテ

    QwikとPartytownでJavaScriptを99%削減する方法 | POSTD
  • フロントエンドにおけるテスト駆動開発の実践と概説

    はじめに 自動テストが叫ばれて10数年以上の時を経ていますが、今なお開発者の興味を惹くトピックの1つであります。 実際、Developers Summit 2023ではテストを主題とした講演が多く、また人気も博したと耳にします。 さて自動テストと共に話題になるトピックの1つと言えばテスト駆動開発でしょう。 ただテスト駆動開発は、設計・開発手法のため自動テストとは厳密にはジャンル違いであり、誤解を受けがちなトピックでもあります。 またテスト駆動開発を解説する書籍の多くが、Java等のオブジェクト指向言語のスタイルで書かれているためフロントエンドエンジニアのコードスタイルとは若干差異があリます。 当記事ではフロントエンドエンジニアのためにテスト駆動開発の技法の数々をTypeScriptReactを用いて実践します。 フレームワークとしてReactを採用しましたが、記事内のコードはモダンフロン

    フロントエンドにおけるテスト駆動開発の実践と概説
  • JestとVitestのisolateについて

    現状 Vitest が Jest など他のテスティングフレームワークに比べて遅くなる場合があることがわかっています。 (確実に遅くなるとはいえない。が、私自身もテストの速度が遅くなったことを経験しています。) また Vitest を実行する場合、poolOptions.threads.singleThread: trueにすると速くなるということもわかっています。 (1.0.0以前は--single-thred、0.29.0以前は--no-threads) 公式 Docs にも最大3倍速くなることが記載されています。 WARNING Even though this option will force tests to run one after another, this option is different from Jest's --runInBand. Vitest uses w

    JestとVitestのisolateについて
  • Honoのv3が出ました

    僕がCreatorのHonoの新しいメジャーバージョンである「v3.0.0」が出ました。 このリリースノートに全て書いたのですが、補足を含めてこちらにも残しておきます。 Honoのステータス v3の説明の前に現在のHonoのステータスです。 GitHubスターは3.5Kです。 Cloudflare WorkersのSDK、DenoBun、それぞれのプロジェクトにHonoの文字が入ってます。 プロダクションやライブラリでも使われています。 cdnjsのAPIサーバー Polyfill.io repeat.dev Drivly substats Ultra(DenoReact SSRフレームワーク) Cloudflare 公式のブログ記事 などなど いい感じです。 v3のスローガン v3へのバージョンアップにあたってのスローガンはズバリこれでした。 Do Everything, Run A

    Honoのv3が出ました
  • フロントエンドテストにおける知見の宝庫を発見!「javascript-testing-best-practices」

    はじめに JavaScriptにおけるテストのベストプラクティスをまとめた「javascript-testing-best-practices」というGitHubレポジトリが大変勉強になったため、特に参考になった内容をまとめて共有したいと思います。 (補足)レポジトリにはfrontendのみならずbackendのテストに関する情報もありますが、今回はfrontendに焦点を当てて共有します。そのため扱うSectionは以下の4つです。 Section 0: The Golden Rule Section 1: The Test Anatomy Section 3: Frontend Section 4: Measuring Tests Effectiveness 想定読者 フロントエンドの実装はできるが、テスト経験はない方 テストに対して解像度が低い方 これからテストを学びたいと思ってい

    フロントエンドテストにおける知見の宝庫を発見!「javascript-testing-best-practices」
  • 逆引き 型ファースト Zod

    1-3. 作成したスキーマから型を取り出したい (infer / shape / element / keyof)

    逆引き 型ファースト Zod
  • eslint-cjs-to-esm: CJSをESMへとマイグレーションするツールを書いた

    最近、色々なライブラリをCommonJS(CJS)からECMAScript Module(ESM)へとマイグレーションしています。 その際に、ESMでは__dirnameやrequireなどCommonJS特有の機能は使えなくなっています。 また、TypeScriptやBabelなど多くのツールはCJSではimport時に拡張子はなくても大丈夫ですが、ESMの場合はimport時に拡張子が必要になります。 import url from "node:url"; - import { mdEscape } from "./mdEscape"; + import { mdEscape } from "./mdEscape.js"; // ESMでは相対パスに拡張子は省略できない + const __filename = url.fileURLToPath(import.meta.url); /

    eslint-cjs-to-esm: CJSをESMへとマイグレーションするツールを書いた
  • JavaScript / TypeScript の豆知識 10 選 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    JavaScript / TypeScript の豆知識 10 選 - Qiita
  • 私が愛するフロントエンドのツールたち2023

    自分がチームでフロントエンドの開発をするときの技術選定について書きます。 ログインしてユーザーごとに個別の情報を扱うことがメインのサービスを前提に書きます。 考え方 メンテナンス性の優れたものを選ぶ 制限が少ないものを選ぶ 余計なことに気を使わない 一気にいろんなことに挑戦しすぎない フレームワーク 正直に書くと最近は問答無用でNext.jsを選択しています。 慎重な性格なので、自分が責任を持って開発、運用するプロダクトであれば自分の経験値が高く、多くの課題をクリアできるNext.jsを選びます。 一部インフラの制約があるものの、ページごとにSSGやSSR、On-demand ISRなどができること、Reactの大きなエコシステムの恩恵を受けられることは非常に大きいです。 採用面でも現状Reactを扱える人は他のフレームワークを扱える人より多く感じます。 次点でCloudflare Wor

    私が愛するフロントエンドのツールたち2023
  • ブログをAstro に移行しました - As a Futurist...

    式年遷宮の様な感じですが、数年おきにブログを作り直してます(前回)。今回は Gatsby でデザインした UI をほぼそのままに、フレームワークを Astro に移行しました。静的サイトの作成では Astro の開発者体験が最高に優れているので、2 年間ほぼ塩漬けにしてしまっていた Gatsby のコードを無事に移行できてよかったです。 Astro とは? Astro は 一言で言うと、Better HTML です。Astro というフォーマットでサイトが記述できるのですが、普通の(素の)HTML も Astro としてそのまま使えます。厳密には違いますが、HTML のスーパーセットみたいな感じです。その HTML の要素群を component としてまとめることで関心を分離できて(この辺は Web Components でも実現できます)、必要に応じてビルド時にロジックも走らせることが

    ブログをAstro に移行しました - As a Futurist...
  • Astroのいいところ(個人的まとめ)

    fan-of-astro.md Astroのいいところ islands architecture によって初期で読み込まれるJSサイズが少ない ほぼ0にすることも可能 https://docs.astro.build/en/concepts/islands/ 元々、Webサイト(静的サイト)に特化したフレームワークなので、他のフレームワークと違い使い勝手がいい 言葉では伝えづらいのですが、「これだよこれ!」感がとても強いのです。 https://docs.astro.build/en/concepts/why-astro/ Astroは、コンテンツに特化した 高速な Webサイトを構築するためのオールインワン Webフレームワークです。 Integrationという統合機能によってプラグインを利用するように開発できる 公式統合も豊富で、中でも @astro/image という画像統合は最高

    Astroのいいところ(個人的まとめ)
  • AstroとmicroCMSでつくるブログサイト

    === 更新履歴 2024/11/28: src/library/microcms.tsをアップデートしました。 2024/1/10: MicroCMSQueriesのインポートに関して、Type-Only Imports and Exportを使用するように変更しました。 === こんにちは、microCMSの松田です。 今回は2022年8月に1.0バージョンを公開したAstroを使ったチュートリアルをお届けいたします。 【2025/10/9 追記】💡Astro 5以降で利用できるコンテンツローダー(Content Loader)に対応したチュートリアルは、以下の記事をご参照ください: AstroとmicroCMSでブログサイトを作ってみよう(Astro 5以降のコンテンツローダー対応版) | microCMSブログ Astroとは?Astroは多機能で効率的な静的サイトジェネレーター

    AstroとmicroCMSでつくるブログサイト
  • LiteFS+SQLiteでフルスタックNext.jsアプリケーションを作る

    なぜLiteFS+SQLiteか 「個人開発のコストはDB次第」でサーバーレス環境でコンピューティングリソースを節約できたけどマネージドDBはまだ高いよ(要約)ということを言っていたら「番環境でSQLiteを使うといいよ」と何人かの人に教えてもらってLitestreamのことを知った。 LitestreamはDBを読み書きするプロセスを1つにして利用するので、サーバーレス環境でsqliteファイルをパスで参照できて、複数箇所から掴まないように構築すれば条件は整えることができる(Cloud Runのように並行に呼び出してもインスタンスが共有されるサービス+最大サイズを1にしておく、とか)。 Litestreamのみでも便利に使えていたんだけど、プロジェクトをウォッチしていたらその後サーバーを複数台にしてそれぞれのインスタンスで同じ結果を得られたり、書き込み先を適切にハンドリングするデザイン

    LiteFS+SQLiteでフルスタックNext.jsアプリケーションを作る
  • daxはいいぞ

    Deno Advent Calendar 2022の16日目の記事です! Denoでこんな感じのコードを書いていました。内容的には大量(2000個以上)のSVGファイルをゴリゴリとTSXファイルに変換していくなんてことをやっています。 変換部分の体はsvgrというライブラリを使っています。内容的にはよくわかっていませんが、babelでパースしてastでどうのみたいな感じのようです。 SVGファイルをバッチ的にTSXに変換していくんですが、最後に deno fmt は手作業でかけなければならずそれが微妙でした。ここはDeno.Commandの出番かな〜とも思ったんですが、前から作者に激推しされていたdaxを使うことにしてみました。 利用方法 というわけでdaxをimportしてきます。

    daxはいいぞ
  • 具体例で学ぶZodの使い方

    はじめに 基的な使い方は公式ページがわかりやすいのでサラッと書いてます。 具体例は実際に Zod を使ってみて気になった部分を書きました。 基的な使い方 import { z } from "zod"; // 文字列のスキーマを作成する const mySchema = z.string(); // スキーマから型を生成する type MySchema = z.infer<typeof mySchema> /* 生成される型の中身 type MySchema = string */ const input: MySchema = 100; // TypeError (型 'number' を型 'string' に割り当てることはできません!) const input: MySchema = "hello!"; // OK! z.infer<typeof T> とすることでスキーマから

    具体例で学ぶZodの使い方
  • WebAssembly と JavaScript との間で自在にデータをやりとりする

    はじめに 引き続き Rust + WebAssembly + SolidJS で遊んでいます。前回は、Rust 側で作成した文字列を JavaScript 側で console.log に出力することを考えましたが、今回は JavaScript 側から何らかのデータを Rust 側へ渡すことを考えたいと思います。今回も、wasm-bindgen[1] に頼らずにやっていきましょう。 メモリの確保と管理 WebAssembly のメモリ空間は、シンプルな Linear Memory(線形メモリ)になっています。RustJavaScript との間で、「プリミティブな数値型」より大きなデータをやりとりするためには、この Linear Memory 上にデータを配置するのが良さそうです[2]。 単一のメモリバッファの確保 メモリの確保は Rust 側で実施します。線形メモリ上には WebA

    WebAssembly と JavaScript との間で自在にデータをやりとりする
  • Next.jsで戻る厨を満たすrecoil-sync-next

    以前、Next.jsのスクロール位置復元について記事を書きました。 上記記事でSPAとMPA(Multi Page Application)における、ブラウザバック/フォワード時のスクロール位置復元について言及しました。 MPAではスクロール位置がブラウザによって復元されることがある(ブラウザの実装に依存) SPAではこれらが軽視されがち Next.jsにおいても、デフォルトでは復元されない(ChromeでSSGページなど一部条件下では復元される) Next.jsではexperimental.scrollRestorationを有効にするとスクロール位置をsession storageに保存し復元する これらと同様に、ブラウザバック/フォワード時のUI復元についても軽視されがちなものの1つです。最近もこの手のUI体験の悪さについて、問題提起がされ話題になりました。 ブラウザバック/フォワー

    Next.jsで戻る厨を満たすrecoil-sync-next
  • Astroを選ぶ理由 🚀 Astroドキュメント

    ようこそ! Astroを選ぶ理由 アイランドアーキテクチャ コース 新規プロジェクトの作成 インストール ディレクトリ構成 開発とビルド 設定ファイルの構成 設定の概要 エディタのセットアップ TypeScript Environment variables Working with integrations AIで構築 開発ツールバー ルーティングとナビゲーション ページ Routing Endpoints Middleware Internationalization (i18n) Prefetch View transitions UIの構築 コンポーネント レイアウト Styles and CSS Fonts シンタックスハイライト Scripts and event handling フロントエンドフレームワーク コンテンツの追加 Markdown Content collect

    Astroを選ぶ理由 🚀 Astroドキュメント
  • Official Tailwind UI Components & Templates - Tailwind Plus

    By the makers of Tailwind CSS Build your next idea even faster. Beautifully designed, expertly crafted components and templates, built by the makers of Tailwind CSS. The perfect starting point for your next project.

    Official Tailwind UI Components & Templates - Tailwind Plus
  • プロトタイピングツールとしての RedwoodJS

    稿は、Webアプリのプロトタイプを作るための道具として RedwoodJS を紹介する記事です。 前説:プロトタイピングにおける技術選定 シンプルなWebアプリのプロトタイプを作るとき、みなさんはどのような技術選定を行うでしょうか。 プロトタイプと言えど UI の検証もある程度は含んでいる場合がほとんどなので、筆者としては UI の構築には React を利用したい[1]ところです。テンプレートエンジンでは著しく開発効率が落ちるので、フルスタックフレームワークとしての Rails や Django はこの時点で選べないことになります。 しかし、React を選んだとしても大半のアプリケーションでは永続層が必要ですし、フロントエンドで計算させたくないロジックも多々あります。バックエンドを別で作る場合に直面するのは、クライアント側とのAPIスキーマの整合性をどう取るかという問題です。できれば

    プロトタイピングツールとしての RedwoodJS