Published: May 19, 2026 The web has long since moved on from the static, document-driven medium that it started as. Modern, rich web apps are used by everyone for many reasons, from communicating, purchasing, consuming rich content, to managing our complex lives. HTML, despite all its advances, is still delivered in-order in a top-to-bottom fashion with little regard for when content is ready or w
Browsers nowadays have built-in form validation (or “constraint validation”) features that are super helpful for highlighting when the entered data satisfies the necessary criteria. Some of us have relied on JavaScript-only solutions to handle client-side form validation in the past (/me slowly raises hand…), but as it turns out, most of these built-in features have been around for over a decade!
宣言型 Shadow DOM は `<template>` 要素を使用して Shadow DOM を構築する方法です。宣言型 Shadow DOM を使用することで、従来の JavaScript を使用した Shadow DOM の構築方法と比較して、サーバーサイドレンダリング（SSR）に対応しているため、パフォーマンスの向上や SEO 対策に期待されます。 Shadow DOM は Web Components を構成する 3 つの技術の 1 つです。Shadow DOM はコンポーネントのカプセル化を実現します。Shadow DOM で定義されたスタイルは Shadow DOM の外部に影響を与えず、また外部のスタイルの影響を受けません。 Shadow DOM は再利用可能なコンポーネントを構築するために重要な技術ですが、従来は JavaScript を使用しなければ Shadow D
=>htmz> a low power tool for html htmz is a minimalist HTML microframework for creating interactive and modular web user interfaces with the familiar simplicity of plain HTML. [GitHub] plain🍦 Use straight up HTML. No supersets. No hz- ng- hx- v- w- x-; no special attributes. No DSLs. No <custom-elements>. Just vanilla HTML. lightweight🪶 166 bytes in total. Zero dependencies. Zero JS bundles to l
はじめに こんにちは。Repro で Booster の開発をしている杉浦と申します。 最近は JavaScript の盛り上がりが凄いですね。今ではブラウザ内にとどまらず、サーバサイドでも活用される様になりました。 これには、言語仕様が整理されたり機能が強化されたり、非常に大きな発展があったという点が大きいです。 実は、言語としての JavaScript だけではなく、最近 HTML との境界インタフェースとしての JavaScript の仕様も最近かなり明確化されてきています。 自分も HTML5 の最初のあたりまでは把握していたのですが、Booster の開発に携わる中で久しぶりに確認したところ、随分と仕様が進化し複雑になっていました。 今回はそんな HTML 規格の変化部分の紹介と、過去からの HTML と JavaScript の流れを振り返る簡単なまとめです。 HTML 仕様と
Frontend engineer @lapras_inc / TypeScript / Vue.js / Firebase / 元消防士
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
LIFULLの中島です。 近頃、LIFULL HOME'Sのフロントエンド(ここではJavaScriptのみを焦点とします)もようやく進む道を見出し、そろそろ設計方針を一新しようと試みています。 今回はそれについて話したいと思います。 現在の私たちの課題感 私たちの管理する多くのレガシーコードはDOM操作ライブラリとしてjQueryを、UI設計の格子としてBackbone.Viewのような設計方式を導入しています。 (もちろんそうでないマイクロサービスも多くありますが) 具体的なコード例を示すことこんな感じになります let Slider = Backbone.View({ events: { '.next click': 'next', '.prev click': 'prev' }, next() { this.$(...).css({left: '111px'}); }, ... }
ES modules are now available in browsers! They're in… Safari 10.1. Chrome 61. Firefox 60. Edge 16. <script type="module"> import { addTextToBody } from './utils.mjs'; addTextToBody('Modules are pretty cool.'); </script> // utils.mjs export function addTextToBody(text) { const div = document.createElement('div'); div.textContent = text; document.body.appendChild(div); } Live demo. All you need is t
フロントエンドチームの @urahiroshi です。Mercari Advent Calendar 2018 12日目を担当します。 今年の8月から12月にかけて，メルカリ・メルペイのフロントエンドチーム有志で「超速！Webページ速度改善ガイド」の社内輪読会を行いました。 この本の中で，「推測するな，計測せよ」という言葉が紹介されていますが，今回の記事は，輪読会で学んだことのまとめとして，Chrome DevToolsを用いてメルカリWebのパフォーマンス計測と簡単な分析を行ったものです。 なお，現在メルカリWebのアーキテクチャを刷新するための開発が進んでいるため，ここで計測したパフォーマンスの値は大幅に変化していく可能性が高いです。アーキテクチャの刷新後に振り返って見られる楽しみが増えることも、この記事を書いた目的の一つです。 計測方法，環境 計測はGoogle Chrome 71.
Background: CSS pixels, canvas pixels, and physical pixels While we often work with abstract units of length like em, % or vh, it all boils down to pixels. Whenever we specify the size or position of an element in CSS, the browser's layout engine will eventually convert that value to pixels (px). These are "CSS Pixels", which have a lot of history and only have a loose relationship with the pixels
WPTとは WPT (web-platform-tests)という、ブラウザを作っている人のためのテストスイートがある。これは、ブラウザがどう動くべきかを定義している様々なWeb標準を、各ブラウザが満たしていてるかを確認するためのテストなのだが、Webサイトを作っているWebデベロッパーが新しいWebのAPIをどう使ったらいいかを調べるときにも役立つと思う。 という話を、電車で横に座っていたとある人に話したら「じゃあ、やり方を(日本語で)紹介してくださいよ。」と言われたので、簡単に紹介したい。 手軽に試す 手軽に試したければ、https://w3c-test.org 以下にある目的のテストファイルを開くといい。 例えば、Service Worker Navigation Preloadのテストであれば https://w3c-test.org/service-workers/service
ブラウザがページを表示する際にサーバーからHTMLのレスポンスを受け取ると、スクリーンにピクセルが描画されるまでに多くのステップが必要になります。ブラウザがページの最初のペイントを実行するために必要とするこのシーケンスは「クリティカル レンダリング パス(Critical Rendering Path)」と呼ばれます。 クリティカル レンダリング パスを理解することで、サイトのパフォーマンスを改善するのに役立ちます。 Understanding the Critical Rendering Path 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 クリティカル レンダリング パス(Critical Rendering Path)には、6つの段階があります。 クリティカル レンダリング パスの6つの段階 01. DOMツリーの構築
Goals and guidelines In the context of RAIL, the terms goals and guidelines have specific meanings: Goals. Key performance metrics related to user experience. For example, tap to paint in under 100 milliseconds. Since human perception is relatively constant, these goals are unlikely to change any time soon. Guidelines. Recommendations that help you achieve goals. These may be specific to current h
近年ではウェブに対する要求が肥大化しており、それに対応してHTMLも複雑化してきています。しかし、もともとHTMLはウェブアプリを記述するための言語ではありません。大規模なウェブアプリを作成するとなると、様々な点で不都合が出てきてしまいます。特に、まとまった部品をコンポーネント化して扱う機能に欠けていました。このことが私たちを悩ませ、今まで多くの苦労を引き起こしていました。 でも、もう悩まなくてもよくなるかもしれません。HTMLをコンポーネント化する規格が生まれました。それがWeb Componentsです。 Web ComponentsとShadow DOM Web Componentsは次の4つの部分からなる規格です。 Templates Shadow DOM Custom Elements HTML Imports 今回は、このうちのShadow DOMに焦点を当てていきたいと思いま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
