You Don't Need Next.js | ドクセル
[beta] Next.jsクイズ2 • <p>にはなにが表示されるでしょうか？ /app/page.tsx "use client"; import { useCallback, useEffect, useState } from "react"; export default function Home() { const [date, setDate] = useState(); const fetchDate = useCallback(async () => { const response = await fetch("/api"); const data = await response.json(); setDate(data.date); }, []); useEffect(() => { fetchDate(); }, [fetchDate]); return ( <
SSRみたいなフロント用語の使い方改めませんか運動
sumirenです。 背景 フロントエンド界隈はベンダやコミュニティ主導で新しいアーキテクチャや技術的手法がどんどん出ていて素晴らしいです。 一方、そうして量産されてきた用語が、界隈の変化に置いていかれている側面もあるように思います。例えば、SSRという用語を取り上げると、コンポーネントからHTMLへの変換を指すこともあれば、サーバー側でデータを取得することを指すこともあります。 実際、業界のパイオニアであるVercel/Next.jsも、そうした現状に対する懸念を持っているように思われます。実際、Next.js App Routerでは、以下のような変化が見られます。 getXXXPropsが廃止され、fetchに対する引数で表現されるようになった SSRやISRという「レンダリング」という言葉を、フェッチの文脈で使わなくなっている しかし、そっとドキュメントを書き換えた程度では、人々に
Edge Side Frontend という新領域
at #ワインと鍋js なぜフロントエンドに Edge Worker が必要なのか、Cloudflare Workers をどう使っていくかみたいな話をしました
2022年のCSS | gihyo.jp
2022年になりました。矢倉眞隆（@myakura）と申します。昨日に続き、新春特別企画のブラウザとウェブ標準動向について紹介します。 取り上げるトピックの数やそのインパクトから、今回はCSSを独立した記事として取り上げることになりました。「ブラウザとウェブ標準動向」についても寄稿していますので、そちらもお読みいただければうれしいです。 2022年以降のCSSは大きく変化しそうだなと思っています。これまでも、CSS3と呼ばれていた機能による表現力の強化、FlexboxやGridなど強力なレイアウト機能の追加など、大きな変化と言えるだろうものはありました。しかし現在提案・実装されている機能は、CSSの根幹を拡充するものと、これまでと性質が異なるものです。 Compat 2021とInterop 2022で互換性の向上 CSSのつらいところとしてまず取り上げられるのが、ブラウザ実装の挙動の違い
高速で開発者体験も抜群！JavaScriptフレームワークの新星「Svelte」とは何か？
はじめに 本記事では、ユーザーインターフェイスを構築するためのJavaScriptフレームワークのひとつ「Svelte（スベルト）」についてご紹介します。 Webフロントエンドの領域は年々大きくなっており、読者の皆さまの中でもReactやVueといったフレームワークを使ったことがある方が多いものと思います。もしかしたら、Svelteの名前もどこかでご覧になり、気になっている方もいるかもしれません。 Svelteは、そのアプローチの新しさから注目されはじめています。 JavaScript のライブラリに関する大規模調査「State of JS 2020」で「最も愛されているWebフレームワーク」「もっとも開発者の満足度の高いフレームワーク」に選ばれたことでも話題となりました。 そこで本記事では、ReactやVueに少しでも触れたことがある方を想定して、それらと比較する形で、Svelteの特徴
2021年のまとめ・反省 - mizchi's blog
年内に間に合わなかった… 2021年に主にお世話になった言語・ライブラリ TypeScript React chakra-ui dnd-kit Node Vite esbuild Docker(=> lima) とりあえず挙げてみたが、なにか特定のライブラリを使う、という感じではなく、レイヤーが一つ下にいった感じがあり、実際にはなんかもうちょっと下のミドルウェアみたいなものを作っていることが多かった気がする。ASTをいじるコンパイラ周辺ツールを作っていることが多かった。 サクッとなにか作る場合、 React + TypeScript + Vite(esbuild) が鉄板という感じで、 esbuild が異次元に速すぎて、typescript の変換もバンドルも、もはやこれ一本でいい気がしてる。 microsoft/typescript はもはや言語仕様の定義と型検査がメインであって、コン
フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
