Next.js のページ遷移を全力で止めるLX Web Frontend Night: Unleash Next.js 録画 https://www.youtube.com/watch?v=uc-GgjE_G4g&t=216s https://github.com/LayerXcom/next-navigation-guard …
あなたのプロダクトに Apollo Client は必要ないかもしれない - 一休.com Developers Blog
Apollo Client は複雑 Apollo Client が向いているケース 一休.com に Apollo Client は必要ないかもしれない では何を使えばいいの？ 複雑なアプリケーションには Apollo を使えばいい？ もう一つのリッチなクライアント、Relay の話 結局、何を使えばいいのか この記事は一休 × 出前館 Frontend Meetup でお話した内容をブログにまとめたものです。 user-first.ikyu.co.jp speakerdeck.com GraphQL クライアントと聞いて一番に思い浮かぶライブラリは何でしょうか？ 多くの方にとっては Apollo Client ではないかと思います。npm trends を見ても Apollo Client のダウンロード数は urql や relay などほかのクライアントと比べ圧倒的です。 実際、一休
Remix という 考え方
こんにちは、@kaa_a_zu です。今日(11/23)の日本時間早朝に React Router の制作者である @Ryan氏 と @Michael が着想した Remix V1.0 が正式リリースされました🎉 RemixがWebの世界に及ぼす影響は大きいと思っており、実際のコードやドキュメントを見ながら既存のフレームワークと何が異なっているのかを中心に書いた紹介記事です。(正直、魂が震えています) より具体的な使い方はドキュメントを見て、手を動かしていただくのが良いかと思います。また、既に国内でも使ってみた系の記事がいくつかあるようです。 Remixの機能には様々なものがありますが、当記事では筆者がより注目しているものについて書いていきます。Remixに興味があるけど、あまり追えていないという方に読んでいただけると嬉しいです。 ※この記事はGatsbyやNext.jsよりもRemix
なんでもSPAにするんじゃねぇ！という主張のその先 - console.lealog();
Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
FrontendOps
I had recently the privilege to speak about FrontendOps at the last Thoughtworks XConf EU in UK, Germany and Spain. You can find my presentation slides here and at some point soon a video of the talk will be made available. For now if you are interested to the topic what follows is essentially my talk transcript. Update 14.11.18: a video of my talk is now available here. This article describes the
フロントエンドを100倍速くした（ ＾ω＾） - Qiita
おはようございます、なのくろです。年の瀬ですね。 この記事は ABEJA Advent Calendar 2020 の最終日です。 追記：おかげさまで Qiita LGTM賞 を受賞いたしました、ありがとうございます！ 私は2020年01月にABEJAへ入社しました。チームではフロントエンド開発全般を任されています。 参入してちょうど１年が経過しましたので、今年取り組んだことをまとめました。 「フロントエンドを100倍速く」というタイトルは誇張気味なのですが、難しいことはせず、基本的なパフォーマンス改善を素直に実践したという話を書きます。 本稿では事例とやったことを紹介するのみですが、何かしらの知見や改善のきっかけに役立てば幸いです。 サービスについて 話をする前に、どんなサービスを開発しているかについて少しだけ触れます。 ABEJA社では「Insight for Retail」という、小
webpackのbundle後のJavaScriptのサイズを減らしている話 | リクルートテクノロジーズ メンバーズブログ
はじめに リクルートテクノロジーズに4月に新卒入社した 辻 健人です．GitHubではmaxmellonで活動しています． 7月より，やりとりも作成もラクになるシフト管理サービス「Airシフト」 のエンハンス開発を担当しています． 以前は，React製SPAのパフォーマンスチューニング実例という内容で記事を書きました． 今回は同じSPAにおいて，いかにwebpackが生成するJavaScriptのバンドルサイズを減らすかについて紹介していきます． webpackが，そもそも何のためのツールか，バンドルする理由などについては割愛させていただきます． そういった話は，こちらの記事 (Webpack の考え方について – mizchi’s blog) がわかりやすいと思います． Airシフトのアーキテクチャ Airシフトは，React-Reduxで開発されており，かつSSRを行っておりコードの大
[Web フロントエンド] 状態更新ロジックをフレームワークから独立させる - 株式会社カブク
はじめに はじめまして。 null です。最近の悩みは 2 歳半の息子が言うことを聞いてくださらないことです。 2 歳児もそうなのですが、 ソフトウェアフレームワークに振り回されてるって感じること、稀によくありませんか？？ ある程度の学習コストがかかるのは当然としても、冗長な書き方を要求されるわ、かゆいところに手が届かないわ、実データ投入したらパフォーマンス問題だらけだわ、バージョンアップしたら動かなくなるわで、あぁ私いま振り回されてるなぁ、みたいな。 「じゃあ使わなければいい」「じゃあ自分で作ればいい」という話ではなく、「必要以上には依存しない方が無難だよね」「フレームワークの外へ切り出せるところは切り出してみよう」という話をします。 続きを 3 行で 状態更新ロジックってフレームワーク非依存にできそうだよね でもフレームワークによって状態をイミュータブル（状態更新=状態オブジェクト生成
![[Web フロントエンド] 状態更新ロジックをフレームワークから独立させる - 株式会社カブク](https://cdn-ak-scissors.b.st-hatena.com/image/square/897d9c48832ba7e3a66c89a7941ffe151d3d8705/height=288;version=1;width=512/https%3A%2F%2Fwww.kabuku.co.jp%2Fwp%2Fwp-content%2Fuploads%2F2019%2F05%2Fcut20_bunsin-1200x801.jpg)
#AMPConf 2019で発表された検索関連の最新AMPニュース――amp-scriptやSXG、AMPストーリーなど
[レベル: 上級] 東京の六本木で 4 月 17 〜 18 日に開催されている AMP Conf 2019 に参加しています。 1 日目の基調講演から検索に関係する部分をピックアップします。 <amp-script> コンポーネント [05:34] AMP ドキュメントで、独自の JavaScript を実行可能になりました。 現状では、AMP が定義した JavaScript しか AMP では利用できません。 サイズが 150KB以内（圧縮前）などの制限はありますが、AMP JS 以外の JavaScript が使えるようになるのは大きな変革です。 詳細は公式ドキュメントを参照してください。 Next.js [06:33] Next.js が AMP を正式にサポートしました。 React の SSR が AMP で利用可能になります。 詳細は Next.js の公式アナウンスを参照し
Ikyu Frontend Meetupを開催しました - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの14日目の記事です。 qiita.com こんにちは。 id:kentana20 です。一休で宿泊サービスの開発をしています。 今日は一昨日の夜に実施したイベント「Ikyu Frontend Meetup」の様子をレポートしたいと思います。イベントページはこちら。 ikyu.connpass.com 年末の忙しい時期にもかかわらず、多くの方にご応募・ご参加いただきました。 今回のイベントのきっかけ 過去に2度、一休ではテック系イベントをやっていましたが、「ぼちぼちまたイベントやりたいな〜」と思っていたときに、 id:supercalifragilisticexpiali が書いた user-first.ikyu.co.jp を見た他社のエンジニアの方から「情報交換しましょう」と複数問い合わせや依頼があったので、イベントにしてしまおう、と思って今
Redirecting…
Redirecting… Click here if you are not redirected.
「フロントエンド初学者のためのNuxt.jsの歩き方」というタイトルで発表をしてきました｜福井 烈 / note inc.｜note
先日、三沢市で開催された名無し勉強会で、 「フロントエンド初学者のためのNuxt.jsの歩き方」 というタイトルで発表をしてきました。 スライドを作り始めたらボリュームが大きくなってしまい、10分に収まらずすいませんでした🙇時間オーバーしてしまったにも関わらず全てを伝えることはできませんでしたが、興味を持って頂いて学習のきっかけとしていただけたら嬉しいなと。 かく言う自分もフロントエンドを本格的に触り始めて5ヶ月弱の弱者なのでまだまだ初学者に毛が生えたレベルなんですが、自分の経験を元にこんな感じで勉強していけば効率的に学べるんじゃないかな？という情報をまとめたつもりですので少しでも参考にして頂ければ幸いです。 また、間違いなどのご指摘やアドバイスなどがあれば是非お願いします🙏 (スライドは公開用に少しリライトしました) 資料内の紹介コンテンツ・Nuxt.js ・noteのフロントエンド
ちゃんと理解するCode Splitting - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Code Splitting、サボってきたのですが、必要になりそうだったので真面目に調べてみました。 これからCode Splittingやりたい方の入口的な役割になれれば幸いです。 Code Splittingとはなにか Code Splittingはその名の通り「コードを分割すること」を指します。分割されたコードはユーザのアクションに応じて非同期に読み込まれます。 ちなみにWebpackでentry point分けることとかもCode Splittingと言えばそうなのですが、本記事では触れません。また、別にSPAでなくともCode
ChatWork Liveの刷新とScala.jsについて - kubell Creator's Note
こんにちは。クライアントアプリケーション開発部の田中です。 好きな麻雀の役は七対子です。 先日、ChatWork LiveのUIが変更されました。 詳細は下記を御覧ください。 blog-ja.chatwork.com UIについては今後デザイン部の方がブログを書くと思うので、今回私の方では技術的なところの紹介をしたいと思います。 （尚、この記事にはWebRTCやビデオ会議システムの話は全く出てきませんので、ご了承ください。） ChatWork Liveのフロントエンド技術について 実は今月のUI更新とは別に、JavaScript部分の大幅な変更を4月末に実施しています。 大まかな設計はすべて@kyo_ago氏がやってくれて、 私は敷かれたレールをただただ歩くだけだったので割と楽させてもらいました。 ChatWork LiveのWebクライアント側は主に以下の技術を使って実装されています。
フロントエンドの未来の話 - Qiita
const fsbx = require('fuse-box'); const fuseBox = fsbx.FuseBox.init({ homeDir: 'src/', sourcemaps : true, outFile: './dist/app.js', plugins: [ [ fsbx.SassPlugin({ outputStyle: 'compressed' }), fsbx.CSSPlugin({}) ], fsbx.TypeScriptHelpers(), fsbx.JSONPlugin(), fsbx.HTMLPlugin({ useDefault: false }) ] }); fuseBox.devServer('>main.ts **/*.html', { port: 4445 }); シンプル！！ fuse-boxの特徴として ・TypeScriptはデフォル
SPAにおけるCSSについて、ひとつの解（追記あり） - エンジニアをリングする
SPAにおけるCSSのありかたについてずっと悩んでたけど昨日今日で一筋の光明が見えた— よしこ (@yoshiko_pg) 2017年4月7日 この話を簡単にまとめておこうと思います。 結論を先に書くと「今のところtemplate literal内にCSSを記述する形式のCSS in JSがいい感じ。Reactならstyled-componetnsが良かった」という感じです。 悩んでいたこと コンポーネント指向でSPAを作っていく上で、CSS（というかスタイリング）はどう書いていったらいいんだろう？ということに結構悩んでいました。 HTMLとJSがコンポーネントとしてまとまっていく中でCSSだけは今まで通り別物として扱い、BEMなどでグローバルスコープと戦うのか？はたまたCSSの枠をはみ出てJSコンポーネントの粒度に合わせたコンポーネント化をするのか？ 加えて、見た目も挙動も複雑なアプリケ
React + BrowserifyプロジェクトでJS/CSS/HTMLを圧縮(Minify)する - Umi Uyuraのブログ
ReactとMaterial UIを組み合わせると、それだけでBrowserifyで結合したJavaScriptファイルが1MB超えてしまうので、やっぱり圧縮とかした方が良いのかな―と思い、やり方を調べてみました。 ※2015/08/03更新 Licensifyを開発された @t_wada さんから改良の連絡をいただいたので、Licensifyの最新版1.4.0をもとに内容を更新しました。 Licensify - Nodeモジュールのライセンスコメントを生成する JSファイルを圧縮すると、ライセンスが記載されているコメントが消えてしまうという問題があるということで、本題の前に、Browserifyと組み合わせて、読み込んだNodeモジュールのライセンスコメントを生成してくれる Licensify を試しておくことにしました。 インストールはnpmから。 $ npm install lice
俺のJSライブラリの世界観(2014末版) - Qiita
概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指しているのだけど、コアドメインをTypeScriptで書いて、それをUI層からCoffeeScri
なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita
追記: 情報が色々と古くなったため、2020年に書き直した版へのリンクを張っておきます。 この記事は VirtualDOM Advent Calendar 2014 - Qiita の初日です。 初日ということで、基調講演風に、Virtual DOMとはなにか、なぜ僕はこんな興奮しているのか！という話から。 Virtual DOMとはなにか 既存の概念で当てはめると、JavaScriptのMVC, MVW(Whatever)フレームワークのViewに位置します。が、その程度では終わりません。仮想DOMとは世界を革命する力であり、このjQueryのDOM操作で汚れきったフロントエンドを救う救世主なのです。 現時点で自分が知っている限りは、以下の実装を指します。 facebook/react 最も使われてるFacebookの実装 Matt-Esch/virtual-dom Altenative
browserify をはじめてみる
Browserify を触ってみたメモ。 Browserify とは CommonJS のモジュールの仕組み、つまり Node.js の require をブラウザ上でも使えるようにするもの、ということでいいみたい。Readme を読む限りは、npm にあるモジュールをブラウザ上にもっていくために作られ始めたような印象をうけるが、ちまたのエントリーをみていると AMD に代わりに CommonJS でフロントエンドの依存関係の管理をする (RequireJS ではなく、Node.js 感覚で require 関数をフロントエンドで使う) ためのツールとしても使っていいようだ。 やりたいこと 複数の js ファイルの依存関係を記述したい 最終的に、依存関係を考慮した順番で、ひとつの js ファイルに結合したい 作りたいのは第三者のサイトに埋め込んでもらうスクリプト (サードパーティスクリプト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
