Web 標準と、その限界
JavaScript、たくさんバックエンドで使われてますよね、あなたも使ったことはありませんか？ そんな バックエンドでも使われている JavaScript。そこに標準で組み込まれている Web 標準な API 。それを考えていきます。 Web 標準 とは何か Web を構成するための技術として、主に HTML/CSS/JavaScript があります。 どのブラウザでサイトを見ても同じ結果が得られるように、その HTML/CSS/JavaScript をまとめている仕様のことです。 例えば、 HTML の仕様は HTML Living Standard が主流で、 WHATWG という団体が決めています。 JavaScript では、構文や基本的な機能 (Arrayなどの言語使用) は ECMA という団体が ECMAScript を策定しています。この中にはfetchは含まれていないの
HTMLメールの最近の実装方法を解説、tableは不要になりました
HTMLメールの実装で「tableか、、、」とため息をついていた人に朗報です。 tableを使用しなくてはいけなかった理由はWindows上のOutlookだったのですが、新しいOutlookではレンダリングエンジンがEdgeに切り替わります。これにより、tableによる実装は不要になります。 HTMLメールの最近の実装方法を解説します。 Modern HTML email (tables no longer required) by Ollie Williams 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに HTMLメールの実装でもっとも頭を悩ませている問題 今日、HTMLメールをどのように実装すべきか？ 電子メール用のAMPについて 終わりに はじめに MailChimpによるHTMLメール実装のベストプラクティ
Webの将来はサーバサイドレンダリング（SSR）に回帰していく。Denoが主張するIsomorphic JavaScript（もしくはUniversal JavaScript）とは何か？
Webの将来はサーバサイドレンダリング（SSR）に回帰していく。Denoが主張するIsomorphic JavaScript（もしくはUniversal JavaScript）とは何か？ 静的なHTMLファイルをWebサーバが配信する仕組みから始まったWebは、サーバ側で動的にHTMLを生成するCGIの仕組みや、Webブラウザ上でJavaScriptを実行してインタラクティブな操作を実現するなどの仕組みを得たことでWebアプリケーション基盤へと発展しています。 現在、Webアプリケーションの仕組みとして代表的なものがSPA（Single Page Application）でしょう。 SPAはWebブラウザ上で多くの処理が行われるためユーザーの操作に対する反応が速く、インタラクティブ性の高い快適なWebアプリケーションを実現できる利点があります。 しかし、これからのWebはサーバサイドレンダ
Denoが新フレームワーク「Fresh 1.0」リリース。Just-in-timeレンダリングやランタイムオーバヘッドゼロなどの特徴がもたらす優位性とは？
Denoが新フレームワーク「Fresh 1.0」リリース。Just-in-timeレンダリングやランタイムオーバヘッドゼロなどの特徴がもたらす優位性とは？ JavaScriptやTypeScriptのサーバサイドランタイム「Deno」を開発するDeno Land Inc.は、Deno用のフルスタックフレームワーク「Fresh 1.0」のリリースを発表しました。 バージョン番号の1.0が示すように、安定版としてのリリースです。 Fresh is a new full stack web framework for Deno. It sends zero JavaScript to the client by default and has no build step. Today we are releasing the first stable version of Fresh.https
Next.jsにおけるSSG（静的サイト生成）とISRについて（自分の）限界まで丁寧に説明する - Qiita
この記事では、Web アプリケーションにおけるデータ取得（データフェッチング）やレンダリングに関する各手法について比較・整理することを目的として、特に最近注目度が高まっている Next.js における SSG（静的サイト生成）や ISR（インクリメンタル静的再生成）、それ以外の手法（SSR、CSR 等）を具体的なテーマとしてお話しします。 Twitter もやっているのでよかったらフォローおねがいします！ @_thesugar_ 記事内の解説は正確性を期すよう注意を払っておりますが、誤っている部分などがございましたらコメント欄や Twitter 等でご指摘ください はじめに Web アプリケーションを作るとき、レスポンスの速さをはじめとしたパフォーマンスの問題は開発者にとって大きな関心事となります。 たとえば、最近では Google が Core Web Vitals という Web のパ
もう迷わないNext.jsのCSR/SSR/SSG/ISR
はじめに Next.jsで一番最初の詰まりどころと言えば、「CSR/SSR/SSG/ISRとあるけどデータ取得はどのやり方でやれば良いか」という点ではないでしょうか。 自分の中でようやくこの辺りの整理ができたので、この記事ではCSR/SSR/SSG/ISRとは何ぞやというところからそれぞれの使い分けについて書いていこうと思います。 CSR/SSR/SSG/ISRとは CSRとは CSRはClient Side Renderingの略で、日本語に訳すとクライアント側でのレンダリングです。 CSRではクライアントのリクエストに対して空のHTMLとJSを返し、クライアント側でJSを実行してレンダリング、及びデータ取得を行います。 Reactのみを使ってSPAを作る場合にuseEffectの中でデータをfetchして結果をuseStateに渡して表示するというお馴染みのやり方です。 全てがクライア
POSTDをGatsby.jsベースに変更しました | POSTD
POSTDの運用がリクルートからニジボックスに移管される際に、デザインのリニューアルと同時にコードベースをGatsby.jsに変更しました。 本記事では、運用移管に至るまでの過程を踏まえつつ、現在のPOSTDの構成を紹介します。 移管前のPOSTD 前述の通り、POSTDは株式会社リクルートのインキュベーション部門Media Technology Lab.（現新規事業開発部）で運用されていました。 最後に公開した記事は、2019年3月28日の「PHPはもうダメだ、PHP万歳！」となっています。 もともとはWordPressによる運用が行われていましたが、運用体制の関係で静的HTMLをFirebaseで公開する形式になっていました。 ニジボックスへの引き継ぎに伴い、記事の翻訳を始めとしたサイト運用を再開することになり、改めてCMSの形式に変換する必要が出てきます。 Gatsby.jsを選ぶ
Rails MVCしか知らなかったバックエンド開発者が、最近のフロントエンド開発を学んで得た知見 - スペクトラム
これは、これまでRailsの古き良きMVCな開発体制しか知らなかったバックエンド開発者が、環境が変わってフロントエンド開発を学ばざるをえなくなった者の記録です。 歴史的に正しい事実を書いたものではなく、私個人の理解を整理するための妄想日記です。 私はこれまではWebアプリの開発ばかりやってきて、RailsでHTMLテンプレートエンジン使ってviewを作るスタイルでしか開発してきませんでした。 しかし、ネイティブフロントとWebフロント両方があるアプリケーションが開発されているところを見て、ある事を思いつきました。 「Webフロントもネイティブフロントのように開発できれば、バックエンドエンジニアはバックエンドに、フロントエンドエンジニアはフロントエンドに分業できて、開発しやすくなるのでは？」 この気付きが超重要でした。このイメージを持てたおかげでフロント開発の意義がスルスル入ってきました。
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
9/11とAkamai Technologies社 - 最速配信研究会(@yamaz)
みなさんはAkamai Technologies社をご存知だろうか？ http://www.akamai.com/ http://www.akamai.co.jp/ Akamai社は高速なコンテンツ配信を請け負っている会社で,同社の保有する数万台のサーバリソースを利用しての大量の画像や大規模なストリーム配信を得意としている. アメリカではGoogleやYahoo!やMicrosoft,日本ではYahoo!Japanやmixiなどたくさんの会社が利用をしていて,インターネットを陰で支える縁の下の力持ちといった会社だ. 同社が提供するFreeFlowやFirstPointと呼ばれる配信サービスはまさにAkamai(ハワイ語でCoolの意味)というにふさわしく,初めてそのバックのテクノロジーを教えてもらったときは目から鱗が落ちる思いだった. ところで9/11は言うまでもなく米同時多発テロが起きた
クロスドメイン制約 を document.domain の 変更 で 回避
クロスドメイン制約 を 回避 する クライアント実装 を document.domain を利用して実現します。 クロスドメイン通信 を実現するには "サーバー側" と "クライアント側" の2カ所に対して手を入れる必要があるかどうか考えます。 ここでは、"クライアント側" に手を加えて クロスドメイン通信 を実現する方法を載せます。 具体的には、document.domain を変更することで信頼する範囲を広げて クロスドメイン通信 を行えるようにします。 想定する クロスドメイン通信 環境 サーバーA から HTML & JavaScript を受信し、足りない リソース を サーバーB から取得する環境を想定します。 今回の方法は、サーバーA と サーバーB の 上位ドメインが同一であること が条件になります。 信頼する ドメイン ( サーバー ) を広げる実装 サーバーA から配信
Chrome DevToolsを用いたメルカリWebのパフォーマンス計測 - Mercari Engineering Blog
フロントエンドチームの @urahiroshi です。Mercari Advent Calendar 2018 12日目を担当します。 今年の8月から12月にかけて，メルカリ・メルペイのフロントエンドチーム有志で「超速！Webページ速度改善ガイド」の社内輪読会を行いました。 この本の中で，「推測するな，計測せよ」という言葉が紹介されていますが，今回の記事は，輪読会で学んだことのまとめとして，Chrome DevToolsを用いてメルカリWebのパフォーマンス計測と簡単な分析を行ったものです。 なお，現在メルカリWebのアーキテクチャを刷新するための開発が進んでいるため，ここで計測したパフォーマンスの値は大幅に変化していく可能性が高いです。アーキテクチャの刷新後に振り返って見られる楽しみが増えることも、この記事を書いた目的の一つです。 計測方法，環境 計測はGoogle Chrome 71.
Optimized Server-Side Web Application In 2018 | CyberAgent Developers Blog
こんにちは、フロントエンドエンジニアの原(@herablog)です。今日はアメーバニュースモバイル版(モバイル端末でご覧ください)のリニューアルをご紹介したいと思います。 労力と効果 Webがサービスとして利用されるようになってから、長い月日を経てさまざまな構成パターンやライブラリ・フレームワークが生み出されました。今では作りたいものはなんでも作れるといっても過言ではないでしょう(いや、やっぱり大げさかもしれません)。そんな中で我々は労力に対して効果がより得られるポイントを探り出す必要があります。今回のアメーバニュースモバイル版のリニューアルでは、そのような考えから始めてみました。 エンジニアを褒めるネコ、いつもありがたく使わせていただいております。 サイトの前提条件 どのような構成のWebサイトにするかを選択する上では、前提条件を確認・定義することが大切です。それによって選択される結果は
メルカリのフロントエンドチームが、どんな開発体制で技術選定しているのか聞いてきた！
日米通算1億ダウンロードで日本最大フリマアプリ「メルカリ」。今回はメルカリの小嶋仁司さん、坂本結衣さんにメルカリのフロントエンドエンジニアたちがどんな技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！ メルカリで重要な役割を果たしているWebView 白石：お二人は、メルカリでどんなお仕事をされているんですか？ 小嶋：私は2015年10月に入社して、アプリケーション内のWebViewページの開発を担当してきました。具体的には大規模なトラフィックがある取引画面や、配送サービス「メルカリ便」に新たな運送会社を追加したり、「大型らくらくメルカリ便」の配送機能を拡大したり、集荷サービスなどの開発も行いました。 白石：ビジネス的に重要な部分を作っていらしたんですね。 小嶋：技術としてはいわゆるHTML5、CSS3、JavaScriptを使った
Documentation Driven Contractsについて調べてみた - mookjp.io
Documentation Driven Contractsについて調べてみた May 15, 2017 ( May 15, 2017 更新 ) モチベーション 最近業務で、社内の他のチームに提供するAPIを開発している。 関わっている人が少なければ、みんなで近くに座って都度仕様について相談していけばいい。（感覚的には〜7人くらい？） しかし、会社全体の人数が多く、関わるチームも複数いるため（サービスのモバイルアプリ担当、Webフロント担当、バックエンド担当…など）包括的で都度更新されるドキュメントがないと開発効率が悪い。 とはいえ、API提供チームとしては、実装になるべく多くの時間を使いたい。具体的には以下の条件を満たす手法があればよい: ドキュメント作成にかける時間を短くできる 作成したドキュメントの内容が正確（最新であることが必須） 一番原始的な手法として、ドキュメントをちまちま人手
[GAS] Google Apps Script のHtmlServiceまとめ - dackdive's blog
とりあえず、公式リファレンスであるこのあたりを読んでみた。 Create and Serve HTML Communicate with Server Functions Templated HTML 以下、要点まとめ。 Create and Serve HTML スクリプトの作成からWebアプリとして公開するまで 新規 > Google Apps スクリプト でスタンドアロンなスクリプトファイルを作成。 新規作成 > HTMLファイル で index.html を作成。 コード.gs と index.html にそれぞれ以下を記述。 コード.gs function doGet() { return HtmlService.createHtmlOutputFromFile('index') .setSandboxMode(HtmlService.SandboxMode.IFRAME); }
![[GAS] Google Apps Script のHtmlServiceまとめ - dackdive's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/c51f9e18c10610b213fcdac177c29b8a1dd9f36f/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815712615374%2F8454420450081470813%2F1645799892)
Isomorphic JSで作られたWebサイトの脆弱性検査 | Recruit Tech Blog
サイバーセキュリティエンジニアリング部の西村です。 Recruit Engineers Advent Calendar 2016の12月6日の記事を担当します。 先日、あるWebサイトの脆弱性検査を業務で担当しました。対象のサイトは、Node.js + React + Reduxを用いてIsomorphic JSを実現しており、検査でもこのアーキテクチャに特有の脆弱性が見つかりました。 この記事では、検査で発見した脆弱性をもとに、Isomorphic JSのWebサイトを構築する際に気をつけるべきポイントを紹介します。 Isomorphic JSとは Isomorphic JSは、近年、注目されているWebのパラダイムで、サーバとクライアントで同一のJSのソースコードを利用することが特徴です。これにより、サーバとクライアントの双方でHTMLを生成できるようになり、従来のSPAに見られたSE
Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3)
Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3) 川田寛（ピクシブ株式会社） いよいよHTMLドキュメントのダウンロードと、画面上への表示です。この動作の仕組みから、TATの「終了」がいつなのかを追ってみましょう。「終了」についてはかなり奥が深く、Web標準でもそのプロセスを「The End」として定義はしていますが、それだけでは語りきれない難しさがあります。 4. TCP接続、5. HTTPリクエスト/レスポンス 名前解決で得られたIPアドレスを使って、HTMLドキュメントが置かれたサーバへ「4. TCP接続」します。いわゆる、3ウェイハンドシェークというものです。サーバとの接続交渉が終わると、HTTPリクエストをサーバへ送信し、HTTPレスポンスを受け取ります。 HTTPレスポンスの結果からリダイレクトであることが発覚した場合、「2.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
地に足をつけたフロントエンドの改善