React Server Componentsは再びIsormorphicの夢を見るか
室見川“Web フロントエンド”の悲しみと明るい未来という記事を読みました。 これについては全く同感です。 next.js が vercel を提供して CDNからサーバーサイドでの処理までをワンストップに提供しているとか、 firebase がクライアントサイドでの SDK と Cloud Functions をなるべく一貫した体験で提供しようとしていることとか、あるいは今話題の React Server Component とかについて、フロントエンドの最前線がいったいどのような苦しみにあるか、理解できる人は実はあまり多くないのではないか、と僕は思っている。 それは何かといえば、絶望的なまでのサーバーサイド/バックエンドへの忌避感だ。https://anond.hatelabo.jp/20210105164149 というのも、これは私達がvte.cxを提供してからずっと感じていた課題だ
仮想DOMは本当に“速い”のか？ DOM操作の新しい考え方を、フレームワークを実装して理解しよう｜ハイクラス転職・求人情報サイト AMBI（アンビ）
仮想DOMは本当に“速い”のか？ DOM操作の新しい考え方を、フレームワークを実装して理解しよう 最近のJavaScriptフレームワークで利用される「仮想DOM」について、リアルDOMの違い、メリット・デメリット、仮想DOMを使ったフレームワーク開発などを、ダーシノ（bc_rikko）さんが解説します。 はじめまして、ダーシノ（@bc_rikko）です。さくらインターネットでフロントエンドエンジニアをする傍ら、NES.cssというファミコン風CSSフレームワークを開発しています。 さっそくですが、皆さんは、ReactやVue.jsといったJavaScriptフレームワークを使ったことがありますか？ そういったフレームワークで使われている、仮想DOMについて知っていますか？ 「聞いたことない」「聞いたことはあるけど、どう実装されているかは知らない」「熟知している」。いろいろなレベルの方がい
JSフレームワーク事情2020年始め｜erukiti
この記事では面倒なので名前に .js が付いているものは省きます。例えばNext.js は Next と表記します。 まず結論から日本ではVueはReactと二分する人気があるように観測されますが、世界的な数字で人気・シェアを見るとReactが圧倒的です。 シェアだけで見るとAngularとAngularJS（Angular系の1.x系）の合計値はVueよりも高いですが、「今後はもう採用したくない」と考える率が高く、Angular/AngularJSの人気が低下しているということは間違いありません。 ※追記: Angularのシェア、人気度に関しては、Angular及びAngularJS両方を含む数値であり、AngularJSとAngularは別物であるものが混ざってカウントされているため、Angularのシェア及び人気度はあやふやかもしれません。他の数値に関して信頼性を疑うべきかどうかは
歴史から学ぶ現代のフロントエンド
フロントエンドカンファレンス福岡2019 の資料です。 https://frontend-conf.fukuoka.jp/
フロントエンドコーディングにおけるPageSpeed Insights対策 / frontend pagespeed insights-
フロントエンドコーディングにおけるPageSpeed Insights対策 / frontend pagespeed insights-
自作フレームワークをつくって学ぶ 仮想DOM実践入門
昨今の代表的なJavaScriptフレームワーク（React、Vue.jsなど）には「仮想DOM（Virtual DOM）」という概念が採用されているので、フロントエンド界隈の人は一度は耳にしたことがあるだろう。ただ、仮想DOMについて学ぼうと検索してもヒットするのは「フレームワークの使い方」ばかり。踏み込んでいても概念の説明どまりで、仮想DOMがどのように実装されているか解説した記事はすくない。 ということで、当記事では理解を深めるために仮想DOMを使ったフレームワークを自作し、仮想DOMに入門する！ そして、ReactやVue.jsを単なるブラックボックスのフレームワークではなく、中身を理解して使えるようになることを、当記事の目標とする。 フレームワークが完成すると以下のようなWebアプリケーションがつくれるようになる。 TOC 記事が長くなりそうなのでも目次 そもそもDOMとは？ D
Webフロントエンド パフォーマンス改善ハンドブックを公開しました - dwango on GitHub
パフォーマンス改善ハンドブック ウェブページにおけるパフォーマンスに関する問題の見つけ方や考え方の事例をまとめた Webフロントエンド パフォーマンス改善ハンドブックを公開しました。 URL: https://dwango-js.github.io/performance-handbook/ このハンドブックでは過去に行ったWebフロントエンドのパフォーマンス改善の事例を中心に紹介しています。 注意点としてWebフロントエンドは常に変化しているため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを用い、映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのWebフロントエンドを扱います。 具体的にはニコニコ生放送（以下「生放送」）で行った事例を中心に書かれていま
Electronによるアプリケーション開発事情2018 / builderscon2018 - Speaker Deck
builderscon tokyo 2018『Electronによるアプリケーション開発事情2018』
ちゃんと理解するCode Splitting - Qiita
Code Splitting、サボってきたのですが、必要になりそうだったので真面目に調べてみました。 これからCode Splittingやりたい方の入口的な役割になれれば幸いです。 Code Splittingとはなにか Code Splittingはその名の通り「コードを分割すること」を指します。分割されたコードはユーザのアクションに応じて非同期に読み込まれます。 ちなみにWebpackでentry point分けることとかもCode Splittingと言えばそうなのですが、本記事では触れません。また、別にSPAでなくともCode Splittingはパフォーマンス向上に利用できますが、これ以降はSPAを前提に話します。 Code Splittingの目的 Code Splittingの目的は初期表示にかかる時間、及びユーザがインタラクションできるようになるまでの時間の削減です。 S
フロントエンドのコンポーネント設計に立ち向かう - Qiita
ReactやVueなどコンポーネントベースで作っていくViewのライブラリが普及したことで、コンポーネント指向での開発が一般化してきた昨今のフロントエンドですが、このコンポーネントの設計に悩まれる方も多いのではないでしょうか。 コンポーネントをどの粒度、どんな状態で分割するのが良いのか、などなど、特にチームで開発する時に認識が揃っていないとカオスになりがちな部分であると思うので、自分なりの設計をする際の指針を言語化しようというのが本記事の目的です。同じように悩まれている方にも何らか示唆を提供することができたら嬉しいです。 想定読者 「コンポーネント設計？なにそれ？おいしいの？」という方 初めてコンポーネント設計でアプリ作ってみたけど、本当にこれでいいのか自信の無い方 はじめに: "コンポーネント"とは まず最初に"コンポーネント"という言葉についてですが、ここでは「GUIのパーツをモジュー
フロントエンドの「想定外」に対応する考え方とTipsいくつか
とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。 しかし実際は、悪い意味で期待を裏切られることになりました。 Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。 全く動かなくなってしまう原因は単純（後述）だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない！！ と思いました。 フロントエンドの想定外 ウェブサイト
フロントエンドエンジニアに求められるもの多すぎ問題 - フロントエンドの地獄
背景 postd.cc という記事がちょっと前にありました。 github.com Roadmap to becoming a web developer in 2018って最近のWeb技術のまとめみたいなもんもよく引き合いに出されます。 このまとめの中にフロントエンドのものありますが、これはフロントエンド技術自体のロードマップです。 これらの技術すべてに精通していればいいのかと言われるとそんな必要は全く無くて。 でも現場によって実際 フロントエンドエンジニアに求められているものはそれ以外にもたくさんあるんですよね。 会社によってマジでJavascriptプログラミングしかやらない人も、マークアップする人、デザインを作ってそれをCSSに落とす人、本当に一口にフロントエンドエンジニアと言っても幅広すぎ。 担当範囲が広すぎるフロントエンドエンジニアに関していろんな会社が募集してると思うんですが
日経電子版を速くする / nikkei-inside-frontend - Speaker Deck
Inside Frontend #2 の発表資料です https://inside-frontend.com
Real world es201x and future
現場のES201x と未来のアーキテクチャ - インサイドフロントエンド2
1年前に作ったフロントエンド環境を色々新しくした - Qiita
新規立ち上げのチームを異動して、1年前に作った会社のフロントエンド環境（Vue.js + webpack(+Gulp)）をベースに環境を作っていたのですが、 色々古かったので、新しくしました 今回作ったものはGitHubにあげてます https://github.com/kurosame/vuejs-boilerplate この中からやったことをいくつかピックアップして紹介したいと思います パッケージを最新にする npm install -g npm-check-updates npm-check-updates -u // package.jsonのパッケージを全て最新にして上書く npm update // package.jsonに記載してあるバージョンに更新する npm install 今回みたいにバージョンアップするパッケージが多い場合は、これでいいと思う 他のパッケージに依存し
React とGUI 設計論、あるいは新世代のホームページビルダー - Qiita
注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる！というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作
フロントエンド開発の概要について
ここでは、フロントエンド開発の概要について説明していきます。 ＊元記事はこちらです。(英語) この記事でカバーしているものについてSingle-page Apps (SPAs)New-age JavaScriptUser InterfaceState ManagementCoding with StyleTestingLinting JavaScriptLinting CSSTypesBuild SystemPackage ManagementContinuous IntegrationHostingDeploymentSingle-page Apps (SPAs)かつてはサーバーサイドレンダリングという、別のURLを開くごとにページをリフレッシュしてサーバーから新たなHTMLページを送る手法が主流でしたが、最近のSPAsではクライアントサイドレンダリングというものが主流になっています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PuppeteerでいらないCSSを消す
hirata.blog
フロントエンド・バリデーション
