はてなブックマーク

はじめに Astro は、コンテンツが豊富なウェブサイトの作成に適したウェブフレームワークです。Islands Architecture のもとで静的なページの上に動的な要素を配置し、パフォーマンスとインタラクティビティの両立を図れることを一つの特徴としていますが、SSR や Middleware、Endpoints などを活用し、サーバーサイドでも動作するようなアプリケーションを作成することも可能です。最近は特に後者のダイナミックなサイトを作るための機能強化にも力を入れており、フルスタックなアプリケーションフレームワークとしての可能性も見え始めてきています。Astro についてより詳しくは、公式ドキュメントの Why Astro? やその日本語訳などを参照してください。 以下では、2024 年の Astro の動向のなかでも特に筆者が重要であると感じたものについてまとめていきます。また

はじめに Hono の売りの一つに「ウェブ標準への準拠」があります。この特徴により、開発者は Hono アプリを様々なプラットフォームへとデプロイすることが可能となっています。これだけでも素晴らしいことですが、Hono 好きの方々はそれでは飽き足らず、Hono がウェブ標準の Request/Response をやり取りするという事実を利用し、おそらくはもともと想定されていなかったであろう場所でも Hono を使い始めているようです。筆者が特に注目するのは、以下の記事のように Hono を Next.js などフロントエンドのメタフレームワークに組み込むような試みです: こうした文章を読み、「これは色々なフロントエンドフレームワークに応用できそうだ」と考え、Next.js だけではなく Astro や Nuxt などでも Hono を動かす実験をおこない、それをまとめた結果がこの記事となり

はじめに 2024 年 12 月 3 日、Astro 5.0 がリリースされましたが、v5 の目玉機能の一つが Server Islands です。この記事では、Next.js の Partial Prerendering などの各レンダリングモデルと比較しながら、Server Islands の概要や仕組みについて解説します。 「基本的に Server Islands は Astro 版の Partial Prerendering といえるが、動的なコンテンツの取得方法という点において両者は決定的に異なっており、そのことの帰結として Server Islands はパフォーマンスにおいてやや劣るがポータビリティにおいて勝る」というのが最終的な結論ですが、その結論へと至るまでのあいだで他のレンダリングモデルについても詳しく説明し、Next.js と Astro 両方のレンダリングについて全

tl;dr はじめに 2024 年の 4 月 24 日に Node.js 22 がリリースされました。ESM を 条件付きで require する機能や、--run フラグによる npm スクリプトのパフォーマンス改善などが v22 で追加され、2009 年に Ryan Dahl が Node.js をリリースしてから 15 年が経つ今も、Node.js は進化を続けています[1]。 こうして Node.js 自身が強化されていくにつれ、以前はサードパーティーのパッケージを使用して実現することが一般的であった機能が Node.js のみで実現可能となり、当該パッケージが不要となるような場合があります。冒頭に引用した Ben Holmes の動画では、そのように不要となったパッケージとして dotenv node-fetch chalk mocha が挙げられていますが、この記事では「これら

はじめに 以前 uhyo さんにより「HTML はプログラミング言語である」と示されたことは記憶に新しいところですが、昨年末の HTML, The Programming Language の登場により、その主張はより強固なものとなりました。現代ではもはや、HTML は立派なプログラミング言語であるということは疑いようがありません。 この記事では、プログラミング言語 HTML, The Programming Language について、その概要と基本的な文法について説明します。そして最後に、HTML プログラミングの応用例として FizzBuzz やフィボナッチ数列の実装例を見ていきます。 HTML, The Programming Language HTML, The Programming Language (以下 HTML と略します) は、HTMX を開発していることで有名な B

8 月 30 日に v3.0 がリリースされ、それから約 3 ヶ月後の 12 月 5 日には v4.0 がリリースされており、メジャーアップデートのペースがやや早かったように感じますね。Astro の co-creator である Matthew Phillips によると、v4.0 における大きな変更の一つに Vite 5 へのアップデートがあり、これはもともと v3.0 に含まれる予定だったのが、Vite 5 のリリースが遅れてしまい、一方で v3.0 の目玉機能である View Transitions を早くリリースしたかったため、まず先に v3.0 をリリースし、その後に v4.0 で Vite 5 を含めるという流れとなり、結果的に v3.0 と v4.0 のリリースが短期間で連続してしまった、という事情があったようです。 GitHub スター数の推移 https://star-

訳者序文 以下の文章は、shadcn/ui の内部構造について解説している The anatomy of shadcn/ui を、原著者である @manupadev 氏の許可のもとに日本語へと翻訳したものです。 shadcn/ui のモチベーションや使い方に関する日本語の解説は少なくありませんが、その実装に焦点を絞って解説した文章は、訳者が知る範囲では存在しませんでした。shadcn/ui は単にコンポーネントライブラリとして優れているだけでなく、同時にコンポーネントの実装パターン集としても学ぶところが多く、そのエッセンスを知ることは多くの開発者にヒントを与えるだろうと訳者は考えていました。そうした折に、まさにドンピシャの内容の記事を発見したため、ここに翻訳して公表することとしました。shadcn/ui をなんとなく使っている状態を脱して一歩深く理解するきっかけが欲しい方や、モダンなコンポ

Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約 はじめに 10 月 26 日に Next.js Conf が開催されましたが、それと前後して Kent C. Dodds (以下 kentcdodds と呼びます) と Lee Robinson (以下 leerob と呼びます) がそれぞれ という記事を公開しました。前者はタイトルの通り、Testing Library の作者であり、Remix の共同創業者の一人でもある開発者兼教育者 kentcdodds が、Next.js を使わない理由について述べたものです。そして後者は、Vercel の VP of Developer Experience である leerob が、主に前者に対する反論を述べたものです。筆者は両方の記事を公開後すぐに面白く読み、そしてどちらにも頷けるところ

はじめに GitHub Actions のワークフローを管理したり、あるいは Pull Request テンプレートを置いたりなど、常日頃からお世話になっている .github ディレクトリですが、最近ふと「このディレクトリでできることを自分は網羅的に把握していない」ということに気付きました。そこで GitHub Docs で .github ディレクトリに関する総合的な解説資料を探してみたのですが、個別の用途に関するページなどはすぐに見つかるものの、.github ディレクトリそのものをターゲットとしたページは存在しないようでした（もしご存知の方がいれば教えていただけるとありがたいです）。 上に書いたような背景のもと、「.github ディレクトリを使ってできることのリスト」をまとめることに一定の価値があるのではないかと考え、この記事を書くに至りました。概要を箇条書き的に並べているため、

はじめに この記事では、フロントエンドのレンダリングパターンの 1 つである Islands Architecture について概略した上で、Astro における Islands Architecture の実現方法をチュートリアル的に解説します。Astro は 2022 年の 8 月に v1 がリリースされたばかりの UI フレームワークであり、ユーザーもまだそれほど多くはないと思われるため、なるべく前提知識がない方でも理解できるように各ステップの説明を細かく噛み砕いておこなうつもりです。また最後に補論として、Astro v2 について本論と絡めて簡単に紹介します。 Astro と Islands Architecture Astro は、高いパフォーマンスを実現するウェブサイトをモダンな DX (Developer Experience) のもとで開発することを目指した UI フレーム

はじめに 2022 年 9 月 22 日、Vercel の DevRel である Steven Tey 氏が dub.sh という短縮 URL 生成サービスを公開しました: 裏側は Vercel の Edge Functions + Upstash Redis という組み合わせらしいのですが、サイトを訪れた際の第一印象が心地よかったため、なんとなく自分も手を動かして URL shortener の簡易版を作りたくなってしまいました。ただ、まったく同じ構成で作成しても面白くないため、自分があまり触ったことがない技術を使うという縛りを設け、Edge 環境として Cloudflare Workers を、データストアとして Workers からアクセス可能なキーバリューストアである KV を、そしてルーティングを手軽におこなうために Hono を使用して実装しました。以下では、その実装の概要をチ

{ "runtime": "nodejs14.x", "handler": "index.js", "launcherType": "Nodejs", "shouldAddHelpers": true } 詳しくは後述しますが、ここでのポイントは、 .vercel/output/functions というディレクトリ構造が存在する その直下に index.func というディレクトリが存在する index.func の内部に .vc-config.json という関数の設定ファイルが存在し、ランタイムなどが定義されている index.func の内部に関数の実体である index.js というファイルが存在する などです。こうした要件を備えた .vercel ディレクトリは、vercel deploy --prebuilt コマンドによって Vercel へと直接デプロイすることができます

はじめに 仕事で使用することになった NestJS について、公式の NestJS Fundamentals Course やドキュメントなどで勉強を進めているのですが、新しい概念が次々と現れるため消化しきれなくなってきました。そこで、まず全体の俯瞰図をしっかりと頭に入れるために、公式ドキュメントの Overview に出てくる範囲の概念を図解して整理し、また各々の役割やプロジェクト内のどこにどのように設定していくかについてまとめることにしました (逆に、大枠とは関係ない部分については大胆に省きました)。 対象読者としては、簡単な CRUD アプリケーションなどを NestJS によって作成したことがあり、基礎的な概念や構成要素について何となくは把握したものの、どうもスッキリとは理解できていない気がする、というような方を想定しています。 この記事が自分のような NestJS 入門者のお役に