2023/9/9「~ 秋のエンジニア大交流会 & LT会!!~」発表資料
![近代フロントエンドの歴史とKuma UIの登場意義](https://cdn-ak-scissors.b.st-hatena.com/image/square/eba326d850e66af05ab42d4037fa34a14541ec4b/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F6fbb088876444762b7f89e9463539f53%2Fslide_0.jpg%3F26963655)
最近の流れを見ていての感想文なので、ideaとして投稿します。筆者のバックグラウンドとしては、Remixの商業記事を書いたり、App Routerの商業記事を書いたりしている人です。 さて、筆者は2022年の秋から、社内システムではありますがRemixをプロダクション運用しています。また、Next.jsのApp Routerについても、パラダイムとしてはRemixにインスパイアされた部分が多い[1]おかげで、順調にキャッチアップできています。 RemixとApp Routerは、ルーティングとデータフェッチを高度に統合しており、Progressively Enhanced SPA(PESPA)と呼ばれることもあるそうです。PESPAについては、次の記事が話題になりましたね。 このPESPAであるRemixを実運用する中で、フレームワークの手触りが近年触ってきたものと大きく違っている点があっ
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日 この主張、界隈(少なくとも自分の観測範囲)では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
Recently Tom MacWright has written a few posts on Single Page Applications and their discontents: Second-guessing the modern web If not SPAs, What? The emerging norm for web development is to build a React single-page application, with server rendering. The two key elements of this architecture are something like: The main UI is built & updated in JavaScript using React or something similar. The b
A few months ago, I wrote an article about how the SPA pattern has failed to simplify web development. The SPA pattern (Single-Page Apps), I tried to define, was about the React model, which also covers, to a large extent, the model of Vue, Angular, and other frontend frameworks. Like any critique, it begs for a prescription and I didn’t give one, other than gesturing toward server-side frameworks
Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This makes for fast first-load pages, keeps template rendering on the server, and allows for a simpler, more productive development experience in any programming language, without sacrificing any of the speed or responsiveness associated with a traditi
こんにちは、小林(@koba04)です。 本記事では、シングルページアプリケーション(以下、SPA)における状態管理について解説します。 GmailやTwitterは、SPAとして構築されている代表的なWebアプリケーションであり、スムーズなページ遷移をSPAによって実現しています。またElectronやPWA(Progressive Web Apps)の登場により、複雑なアプリケーションをWebの技術を使って構築する場面も増えてきました。 これらの複雑なアプリケーションにおいては、既存のページ単位での状態管理の考え方では対応が難しくなります。 そこで今回は、具体的なフレームワークも取り上げながら、Webフロントエンドにおける状態管理のアプローチについて紹介します。 フロントエンドでの状態管理の複雑化 ページの単位を超えた状態の保持 モデルとビューによる処理の分割 イベントの管理が複雑にな
ご無沙汰しております。ウェブボウズを立ち上げて 1 年が経ちました。皆さま如何お過ごしでしょうか。私は、この 1 年間ひとつもブログポストできていません。さらには私の坊主頭(スキンヘッド)にちなんでウェブボウズという名前をつけた個人ブログでありましたが、5 年間共にしたこの Hair-less style から心機一転して 2019 年は髪を育んでいく方針を固めましたので、もはやボウズでもなくなってます。変わり続けることだけが普遍であると胸に刻んで今年も強く生きていきたいと考えております。 さて、最近 Signed HTTP Exchanges やら Performance Budget やらさまざまな面白いことに関わらせていただいて忙殺と幸せを噛み締めている中でも、Chrome Dev Summit 2019 でも大きくフィーチャーされました Portals という新しい HTML 要素
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
一休.com レストランは今年の 7 月 18 日、スマートフォン向け検索ページのリニューアルを行いました。このエントリーでは、その中身について少し紹介させていただきます。 検索ページの課題 一休.com レストランではスマートフォン向け検索ページに対して「遅い」という課題意識がありました。これは技術面で少しブレイクダウンすると; パーソナライズドを含む複雑な処理を行っているため、サーバーサイド処理が重い。 UI 上無駄な遅延処理を行っているため、クライアントサイドの描画が遅い。 というサーバー側とクライアント側両方の課題がありました。クライアントサイドの「無駄な遅延処理」というのは; 検索結果取得が REST API 化されているにも関わず、再検索の度にページリロードを行い、サーバーサイドの描画からやり直している。 という実装に問題がありました。下図がリニューアル前のページ描画の様子です
ちょっと意識高そうなタイトルを付けてしまいましたが、皆さんどのような開発でお過ごしでしょうか。 Nagisa では現在フロントエンドエンジニアは1人です。長きに渡って1人で開発してきましたが、最近は iOS エンジニアやデザイナーも開発に参加することでスピードとクオリティを担保しています。 そこで今回はスキルや役割の違うメンバーで効率よく開発を進める。そしてコードをカオスに落とさず秩序を保つために行ったワークフローの改善や、取り入れたデザインパターンなどを紹介したいと思います。 複数人でチームを組んで開発をするのは、1人のときよりも難しいです。雰囲気で開発を進めていけばコードはカオスに陥り、スピードも品質も担保できなくなります。 他人のソースコードを引き継いだ時や3ヶ月前の自分 (殆ど他人) のコードを改修している時も似たようなことが起こります。 逆に、1人で開発して1人で継続的にメンテし
こんにちは、フロントエンドを中心に開発しています、原 (@herablog)です。 昨年10月にアメブロ2016 ~ React/ReduxでつくるIsomorphic web app ~という記事で、アメブロのJavaベースアプリから、Node.js・Reactベースアプリへのリニューアルについてお伝えしました。今回は、より進化した2017年版のWebアプリケーション開発に向けて、その後おこなわれた改善についてお伝えします。 https化 2016年4月に、ameblo.jpのhttps化をおこないました。セキュリティ観点としては当然のこと、SEO効果やブラウザの新しい機能の利用など、https化はWebアプリケーションのクオリティアップには必須といってよいでしょう。 まず、サブドメイン化されたサブシステムのhttps化をおこない、その後アメブロ本体のドメインをhttps化しました。ht
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング(SSR)が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい() 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
本連載「モダンなフロントエンド開発者になるためのSPA超入門」では、フロントエンド開発のアーキテクチャである「SPA(Single Page Application)」について、開発に必要となる各種フレームワークの特徴や、サンプルアプリ開発を通じたSPA開発の流れ、フレームワークによる作り方の違いなどを紹介します。 サンプルアプリ開発では、SPA開発において人気がある「React」「Angular2」の使用を予定しています。第1回目である今回は、SPAの特徴と取り巻く環境、フレームワークを紹介します。 SPAとは SPAはAdobe FlashやMicrosoft SilverlightといったリッチなUIを提供できるRIA(Rich Internet Application)に代わるフロントエンド開発の技術として、ブラウザの進化やHTML5の登場などによって誕生したアーキテクチャです。H
Transitions between pages can enhance the experience by retaining the user’s context, maintaining their attention, and providing visual continuity and positive feedback, while also being aesthetically pleasing and fun and can reinforce branding when done well. In this article, Luigi De Rosa will create, step by step, a transition between pages. He will also talk about the pros and cons of this tec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く