フロントエンドの技術選定 ~2023を振り返る~ Lunch LT での発表資料です https://findy.connpass.com/event/306714/
![RemixでWeb標準を学んだ1年間 / First year with Remix](https://cdn-ak-scissors.b.st-hatena.com/image/square/1a7ced3ba25630b45c897b0d89b8fc838dbb8711/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Faaad30dceaf54845b44459ec85326ba6%2Fslide_0.jpg%3F28639180)
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
🔥 2022年にサイトの作りを変えまして、もう現状はこの記事の限りではありません。もしこちらの記事の実装を参照されるのであれば こちらのブランチ を参照ください。 これで何度目の挑戦でしょうか。記憶する限り、2年ぶり10度目くらいのブログでございます。会社のパイセンの@ymotongpooさんは12年もご自身のブログを継続されており、日々コンテンツとその作業に耐えうるだけの筋肉を増やし続けられているのを横目に、私はといえば過去に1年以上続いた書きものは日記も含めて一切なく、ブログはというと思い返してみれば2004年ごろのライブドアブログから始まり、辞めては乗り換え辞めては乗り換えを繰り返してきた挙句、最終的にはJekyllいじったあたりでさっぱり音信不通になったのが2年前。並びに、筋肉事情に関して申し上げると、最後にジムに行ったのも気づけば1年半が経っており、会員権が腐り始めている小太り
All slide content and descriptions are owned by their creators.
WebアプリにしろWebサイトにしろパフォーマンスはとても重要です。どんなに高機能であっても、どんなにデザインが良くても、パフォーマンスが悪ければユーザーは離れてしまいます。 とは言え現場はキツキツのスケジュールで、パフォーマンスにまでこだわる余裕がないよ!パフォーマンスはひとまずできる限りのところまで頑張るよ!となってしまうこともあるかと…。 この問題の解決の糸口はパフォーマンスを良くする手段をどれだけ知っているかです。仕様を決めるとき、デザインを決めるとき、実装するとき、それぞれのフェーズでパフォーマンスを常に意識していると自ずとハイパフォーマンスに近づきます。 というわけで今回はフロントエンドの観点から、イマドキのパフォーマンス改善手法をまとめてみました。イマドキと謳っておきながら2年前くらいの技術が出てきたりして最新の話題でもないのですが。 ちなみに、本題に入る前にWebパフォーマ
第68回HTML5とか勉強会の資料です。
前書き このエントリーは Recruit Engineers Advent Calendar の 1日目の記事です。 www.adventar.org リクルートテクノロジーズのフロントエンド開発 リクルートテクノロジーズではいくつもの並行するタスクが走っていて、プラットフォーム基盤と呼ばれる基盤技術開発とインフラソリューションと呼ばれるインフラ開発、後はアプリケーション開発支援などのタスクが存在します。 アプリケーション開発支援の中でもウェブフロントエンド開発は目下のところ重要タスクとされており、色んなやり方をトライアルしています。 基本的には、 React Redux Node.js という組み合わせでフロントエンド開発をしています。 主には以前 ubb.jp というイベントで発表したこの資料に記載されている内容でやっていますが、諸々補足します。 リッチなウェブアプリケーションを作るた
jQueryのその先へ〜Webフロントエンドの全体感をつかもう〜 from Kazuyoshi Tsuchiya ペパボでは、新卒エンジニア向けにメインとなる研修とは別に、週2回に1時間ほどエンジニアでも、デザイナでも、ディレクターでも誰でもいいから、自分が教えたいものを教える。という時間があります。そこで、Webフロントエンドの話をしたので、その資料を公開します。 GoogleMapが登場したときの衝撃(本当に当時は感動したなぁ…)から始まり、jQueryの登場。そして、その後の複雑化していくフロントエンドについて 言語(ES, AltJS) ツール(タスクランナー, パッケージマネージャ) アーキテクチャ(MVC/MVVM/Component指向) の3つにわけて、登場する背景や進化していく過程を伝えるようにしました。それぞれを詳しく。というよりは、ざっくりと全体感を伝える気持ちで。
ブログ以外での活動をみていただければ理解いただけるかと思うが、私は普段はフロントエンドの界隈にいる。 そのなかで、ちかごろ界隈のインターネットが非常につらいと感じることが多々ある。 他の界隈でもそれなりは見られるが、特にフロントエンドで顕著にみられるその「つらい」傾向を完結にまとめてみた。 フロントエンド地獄インターネットのメカニズム 現状のフロントエンドをみていて複雑な気持ちになるパターンはおおよそ以下である。 全体的な地獄フロー 何かしら新しい技術が出てくる Qiitaはてブロ辺りでイケハヤみたいなタイトルの技術系エントリが投稿される バズる 使ってもいない人間がニコニコ動画のコメントみたいな発言をする 地獄になる 誰しもこういう流れをみたことはあるだろう。本当に複雑な気持ちになる人間が多いであろうと思っているため、この「気持ち悪さ」の何が悪いか、どうして起きるのかを自分なりにまとめて
これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記
この記事は JavaScript Advent Calendar 2015 10日目の記事です。 去年は主に gulp にフォーカスした内容でしたが、今回はJSのビルドとテストにフォーカスした入門記事です。 やること ES2015で書いたコードをWebpackでビルドする babel@6系を使う Mocha + power-assert + jsdom でテストを書く やらないこと gulpまわり React.js CSSビルドまわり 最終的なコードはこちらに上げておきました(すごく簡素な出来です)。 GitHub - sskyu/webpack-power-assert-jsdom-skeleton はじめに 今年はReact.jsがJSerの中で定着した感がありました。 Fluxの考え方を昇華させたReduxがFlux系フレームワークでデファクトになりそうな雰囲気を出しつつ、React
フレームワーク対決!Angular VS React仮想パネルディスカッション 吉川 徹 特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、今話題のAngularJSなどのJavaScript MVCフレームワークの台頭と進化、そして新しいアーキテクチャであるFluxとそのフレームワークであるReactなどについて、既に先行して学んでいるエキスパートたちにその知見を聞いてみました。 今回はフレームワーク対決ということで、エキスパートたちがAngularとReactという陣営に分かれ、それぞれのフレームワークについて疑問点をぶつけたり、議論したりする仮想パネルディスカッションという形式でお伝えします。単なるパネルディスカッションとは違って、キーワードは「プロレス」です。まさかりの投げ合い、di
4 ヶ月あまり続いた新規開発案件がようやく落ち着きを見せたので、ここらで振り返りをしてみたいとします1)リリースまでに巻き取れなかった不具合や未実装箇所が幾つか残っているので、まだ気持ち的には終われていないのですが…。 サービスのおおまかなアウトライン コンシューマ ( 一般ユーザー ) 向けサービス ブラウザで動く Web アプリケーション ワンソースによるレスポンシブレイアウト サポートするブラウザは IE9 以降や Android4.x 以降のモダンブラウザのみ Ruby on Rails 多言語対応あり SEO 対策はそれなりに必要 わりとフワッとしか要件が決まっていないままスタートしたので、TRY & ERROR を繰り返しながらの開発 すごく大雑把ですが、だいたいこんな感じの Web アプリケーションです。これを踏まえてフロントエンドをどのように開発していくかを設計していきまし
理解しておきたい、CSSによるインラインレイアウトの仕組み(font-size/line-height編)Inline Layout─Frontrend Conference 高津戸壮(株式会社ピクセルグリッド) この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事(全4回)として書き起こしたものです。今回は第1回目です。 はじめに Frontrend Conferenceでは、皆さんが新しい技術について話していた中、私からはCSS2.1のお話をさせていただきました。私が解説したのは、CSSを書く上で欠かせない、以下の4つについてです。 font-size line-height vertical-align inline-block トレンドとはほど遠い内容ではありますが、多くの人にとって、なんとなく感覚
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く