2022年に起きたフロントエンドの変化Burikaigi 2023 https://burikaigi.dev/ Twitter https://twitter.com/__sakito__
私のフロントエンドディレクトリ構成・テスト観点 2022
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
2022年におけるフロントエンド開発のベースライン
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
Rails 7.0でアセットパイプラインはどう変わるか | Wantedly Engineer Blog
Rails 7.0ではフロントエンドサポートが刷新されます。新たなライブラリが多数導入され、選択肢が増えるため、「Rails公式のものを選べばOK」という戦略が通用しなくなります。 本稿では、Railsでフロントエンドを書くための選択肢について、その歴史と実装を踏まえて比較検討します。 結論から言うと(まだアルファ版なので今後も状況が変わる可能性はありますが、) 新規アプリケーションではSprocketsの役割は無くなりそうです。新しいライブラリとして Propshaft, importmap-rails, jsbundling-rails, cssbundling-rails が登場し、主要な選択肢として以下が提供されます。 (各ライブラリの詳細については後述します) Propshaft + importmap-railsデフォルトの選択肢。Node.jsが不要。トランスパイルを含め、複
React ステート管理 比較考察 - uhyo/blog
こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント（使用者）で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子
2020年代、使う技術はどう選ぶ？
Front-End Study #5 の発表資料です。 https://forkwell.connpass.com/event/205227/ フィードバックはこちら： https://koibu.me/events/14/talks/wQQs0pbvMZHcnZ8TawAi
ESLint, Prettier, VS Code, npm scripts の設定: 2021春
eslint-plugin-prettier 時代の設定をずっと使っていたので、重い腰を上げてアップデートした作業メモ。 背景 Prettier 公式ドキュメントによれば、現在 eslint-plugin-prettier は以下の問題があるとして推奨していない。 エディタが真っ赤になる（人間が気にする必要のない問題なのに！） 直接実行するより遅い（同様に prettier-eslint も遅い） ESLint と Prettier の間に間接レイヤーを追加するので、壊れやすい なるほど正しい。 一方、別々に実行することで以下のような問題も出てくるので、解決していく。 CLI とエディタを個別に設定する必要がある エディタで ESLint と Prettier の協調動作が必要 CLI (npm scripts) で ESLint と Prettier の対象ファイルが別管理になる 上記の
Hotwireとは何なのか？
はじめに HotwireはBasecampが発表した、モダンなWebアプリケーションを作るための新しいアプローチです。名前もHTML OVER THE WIREから来ているように、HotwireではHTMLをサーバーから送ります。「それ普通のWebアプリケーションでは？」と思う方もいるかもしれませんが、SPA + APIサーバでJSONが使われるのに対し、SPAと同様の体験をHTMLを中心に置いて作るアプローチであることを示す表現です。 僕個人は、最初は「ふ〜ん」という感じだったんですが turbo-railsを読みつつHotwireのデモアプリをPhoenixに移植してみたり WebSocketではないTurbo Streamsのsourceを作ってみて遊んだり と、ある程度触ってみて良さが理解できてきたので、Hotwireを使うと何が嬉しいのか、Hotwireの各要素の紹介を記事として
Hotwireの感想 - laiso
Hotwire https://hotwire.dev/ Turboを中心としたウェブアプリケーションのアーキテクチャの要素技術やコンセプトをPRするための名称 Hotwireというライブラリがあるわけではない 役割としてはMicro FrontendsとかReactのlearn once, write anywhereなどに似ている アプリケーション実装言語非依存だけど現状Railsアプリケーションしか実用できる基盤がない Hotwireの思想 アプリケーション開発者の生産性を上げることを目的にしていること サーバーサイド言語でフロントエンドを実装したいアレではなかった プログレッシブ(段階的に利用可能)であること 必要な技術だけを使い無駄なことをしないことで効率化する Hotwireが列挙する技術は1つづつ有効にできる クライアントサイドでViewを差分更新する現在の主流のシングルペー
ウェブの進化とウェブブラウザ開発の最前線
学部 3, 4 年生向けの特別講義で『ウェブの進化とウェブブラウザ開発の最前線』というタイトルで話をしてきました。 ウェブの進化の歴史を知ることで現在のトレンドについて理解し、またウェブブラウザというグローバルで大規模なソフトウェアの開発の一端を垣間見ることで、ウェブやウェブブラウザの開発に少しでも興味を持ってくれたら良いなぁという気持ちで話をしてきました。 なお歴史観については私の事実誤認も含まれると思うので、間違いを見つけたら教えて下さい :-) 追記 (随時) たくさんの反応を頂きありがとうございます！次回同じような資料を作るときの参考にできるよう、ここにメモしていきます。ウェブは無限に話せる話題があって楽しいですね！ ウェブ以前のハイパーテキストの歴史も取り入れるべきでは？ ありがとうございます！おっしゃるとおりで、ウェブの進化史と言いつつウェブが公開されてからの話しかしていないの
ESLint と Prettier の共存設定とその根拠について
注意 この記事は 2020 年 09 月 24 日現在、古い情報となりました。 eslint-plugin-prettier の利用は非推奨であると公式がアナウンスを出しています。 そのことについては Prettier と ESLint の組み合わせの公式推奨が変わった にてまとめましたので、こちらもご覧ください。 また eslint-plugin-prettier は公式推奨ではなくなりましたが、それは Editor などの外部環境の進化によるものでこのプラグイン自体に何か問題が起きたわけではありません。 そして eslint-plugin-prettier を利用した設定方法、特に eslint-plugin-prettier と eslint-config-prettier が何を解決していたかを知らないと、prettier-eslint が何をどう解決したかを理解できないはずなので
現代フロントエンドに欠かせないwebpackとBabelを理解しよう
Transcript ݱϑϩϯτΤϯυʹ͔ܽͤͳ͍ XFCQBDLͱ#BCFMΛཧղ͠Α͏ʂ� CVJMEFSTDPO�UPLZP����� /BNF� ����4BLJUP�.VLBJ� 5XJUUFS ����!@@TBLJUP@@� $PNQBOZ� ����$ZCP[V�JOD� ����'SPOUFOE�&YQFSU�5FBN "CPVU�NF w#BCFMͷલʹݱࡏͷ+BWB4DSJQUʹ͍ͭͯ� w#BCFMʹ͍ͭͯ� wXFCQBDLʹ͍ͭͯ� wXFCQBDL #BCFMͰ෦࣮Λ͍ͬͯ͘ "HFOEB #BCFMͷલʹݱࡏͷ+BWB4DSJQUʹ͍ͭͯ &$."4DSJQUͱ5$�� w+BWB4DSJQUʹ&$."4DSJQUͱ͍͏ݴޠ༷͕͋Δ� w͜ͷݴޠ༷ΛܾΊ͍ͯΔҕһձ͕5$�� 5FDIOJDBM�$PNNJUUFF��� � w&4��
業務システムでこそ使えるPWA - Speaker Deck
FRONTEND CONFERENCE 2018 https://2018.kfug.jp/ での発表資料です。
ぼくのフロントエンド学習
Transcript ΅͘ͷϑϩϯτΤϯυֶश .JY�-FBQ�4UVEZ�ಛผฤ���$50�/JHIU�,"/4"*�7PM�� wTBLJUP !@@TBLJUP@@ � w'SPOU�&OE�&OHJOFFS� w3FBDU XFCQBDL (BUTCZ+4� w&WFOU� w#POpSF�'SPOUFOE� w3FBDU�NFFUVQ� w*OTJEF�'SPOUFOE� ϠϑʔͰͬͯΔ͜ͱ wϑϩϯτΤϯυνʔϜʹॴଐ� w#UP#ͷϑϩϯτΤϯυ� wओʹ3FBDUΛ͍ͬͯΔ� wٕज़બఆɺϨϏϡʔɺ։ൃͳͲ� wશࣾϑϩϯτΤϯυΠϕϯτͷ։࠵� wϥϯνձ� w-5ձ� wࣾ֎͚ษڧձ ϓϥΠϕʔτͰͬͯΔ͜ͱ wϑϩϯτΤϯυؔ࿈ͷهࣄΛॻ͘� wษڧձ� wओ࠵Λ͢Δ� wࢀՃΛ͢Δ� wελοϑʹͳΔ� w෭ۀΛ͢Δ ࠓ͢͜ͱɺ͞ͳ͍͜ͱ ࠓ
PostCSS まとめ - Qiita
僕はPostCSSは開発当初から追いかけていて、GitHubでPostCSSチームのメンバーのひとりだったり、実際にPostCSSを使ってプラグインやツールをいくつか作ったり、ブログや雑誌で記事を書いたり、勉強会等で話したりしています。 本記事では、自分が知っているPostCSSについての事柄を共有します。 PostCSSとは何か PostCSSとは、ロシア人の Andrey Sitnik という人が開発している、Node.js製の「CSSツールを作るためのフレームワーク」です。PostCSS製のツールとして、ベンダープリフィックスを自動で付与する「Autoprefixer」、未来のCSSの構文の一部を今のブラウザで解釈できるようにする「cssnext」、カスタマイズ性に富んでいるCSSリンターである「stylelint」などが有名です。 PostCSSは2018年2月、かなり広く使われて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Vonageにおけるマイクロフロントエンド - Yoav Yanovski氏のVue.JS Amsterdamでの講演より
Hooks時代の設計の話 #agrinoteinside
これからのフロントエンドセキュリティ
BFF and Developer Experience
2019年までに見直しておきたい
CSS・JavaScriptの手法 - Speaker Deck
