話題の Portals を使った画面遷移 UX の未来 | ウェブボウズ
ご無沙汰しております。ウェブボウズを立ち上げて 1 年が経ちました。皆さま如何お過ごしでしょうか。私は、この 1 年間ひとつもブログポストできていません。さらには私の坊主頭（スキンヘッド）にちなんでウェブボウズという名前をつけた個人ブログでありましたが、5 年間共にしたこの Hair-less style から心機一転して 2019 年は髪を育んでいく方針を固めましたので、もはやボウズでもなくなってます。変わり続けることだけが普遍であると胸に刻んで今年も強く生きていきたいと考えております。 さて、最近 Signed HTTP Exchanges やら Performance Budget やらさまざまな面白いことに関わらせていただいて忙殺と幸せを噛み締めている中でも、Chrome Dev Summit 2019 でも大きくフィーチャーされました Portals という新しい HTML 要素
SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
CSSレスポンシブデザインをSPAで使うと破滅する - 橋本商会
レスポンシブデザインは あくまで見た目の調整、表示・非表示のコントロールなので 下手に使うと、デバイス毎にインタラクションが違うUIのstateが無茶苦茶複雑になっていく コンポーネントという概念が無かった時代の設計を、SPAに持ってくるのはおかしい 画面サイズ毎にCSSで手軽にを切り替える、というのなら良い しかし、画面サイズ毎にインタラクションが違う部品が出てくると設計が破綻する 画面サイズ毎のがごちゃ混ぜになる コードが追えなくなり、バグの温床になる では、どうするか？ 素直に画面サイズ毎、デバイス毎、あるいはインタラクション毎のReactコンポーネントを書けばいい 使いまわせる部品は、コンポーネントとして切り出して再利用する 歴史を紐解く 2011年頃、レスポンシブデザインが生まれた 当時のwebにはコンポーネントが存在しなかった 単体で複雑な状態遷移をするインタラクティブなパーツ
ReactSPAをRailsに戻している話 - Speaker Deck
All slide content and descriptions are owned by their creators.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
