GitHub - chenglou/pretext
Pure JavaScript/TypeScript library for multiline text measurement & layout. Fast, accurate & supports all the languages you didn't even know about. Allows rendering to DOM, Canvas, SVG and soon, server-side. Pretext side-steps the need for DOM measurements (e.g. getBoundingClientRect, offsetHeight), which trigger layout reflow, one of the most expensive operations in the browser. It implements its
【海外記事紹介】HTMLは死んだ — 問題だらけのWeb技術をどう未来につなげるか
8月6日、acko.netが「HTML is Dead, Long Live HTML」と題した記事を公開し、話題を呼んでいる。この記事では、HTMLとDOMの現在の構造的問題点を検証し、現代的なUI開発との乖離、そして将来に向けた再構築の必要性について詳しく紹介されている。 8月6日、acko.netが「HTML is Dead, Long Live HTML」と題した記事を公開し、話題を呼んでいる。この記事では、HTMLとDOMの現在の構造的問題点を検証し、現代的なUI開発との乖離、そして将来に向けた再構築の必要性について詳しく紹介されている。 以下に、その内容を紹介する。 DOMとHTMLの現状：終焉と限界 記事は、Web開発の現場において、HTMLやDOMが肥大化し、今や誰も全容を把握できないほど複雑化しているという問題意識から始まる。 たとえば、Chromeにおけるdocumen
過激派が教える！ useEffectの正しい使い方
ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則 技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理
Playwrightを参考にブラウザ内テキスト検索を高速化する (事例紹介:サードパーティスクリプト提供会社)
ブラウザ内テキスト探索の高速化というテーマで改善を行いました。公開許可は頂いていますが、先方の希望で社名は伏せさせていただきます。 技術的には「再現性がある木構造のノード探索の条件の生成、その実行の高速化」という少しR&Dっぽいタスクでした。Playwright のコードを参考にしつつ、個別により速いパーツで置き換えていく、というもので非常に興味深いものでした。こういう仕事は楽しいので、いくらでも歓迎です。 今回は最初はドメイン理解に時間をあてて、その後十分にドメイン理解が進んだら計測しつつ改善する、という流れです。 以下、敬称略。 相談内容 ブラウザを自動操作する技術を開発している。技術的には一種のE2Eテストの応用技術で、サーバーに要素の探索条件と、その操作を登録する。 今回の相談では、その要素探索が重くなってしまうケースがあり、これを改善してほしい、という依頼。とくにテキストを条件に
HTML だけで Shadow DOM を構築するための宣言型 Shadow DOM
宣言型 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
「デザイナー向けCursor」を実現するOnlookのアーキテクチャ - laiso
Onlookとは 「Onlook」は、ReactおよびTailwind CSSを使ったWebサイトやWebアプリを、Electron製デスクトップアプリ上でFigmaのように直接デザイン編集し、その内容を即時にコードへ反映させることを目指すツールです。 onlook.com 類似の“サイトコーディング自動化”ツールが数多く存在する中で、筆者がOnlookに注目した理由は、多くのロジックがクライアントサイドで動作し、その内部構造がオープンソースであることです。内部の動きを追いやすく、自分のプロジェクトへカスタマイズを施すうえでも学びが多い点が魅力といえるでしょう。 反面、Onlookはまだまだ完成度が高くないという点があります。まだ作り途中のプロダクトという印象です（スクリーンキャストをRPして大袈裟に宣伝している人がいたらたしなめておきましょう）。いくつかの機能は開発中のまま動作しません。
リッチテキストエディター（RTE）のJSライブラリ色々試してみた
リッチテキストエディタ(RTE)って？ リッチテキストエディタ（以下RTE）とは、文字を入力できるだけでなく、文字に装飾を加えたり、段落を設定できたりと複雑な機能を持つエディタのことです。 弊社プロダクトであるkintone内にも以下のようなエディタが存在します。 また、似たものを指すWYSIWYG(読み方:ウィジウィグ)という用語もありますが、これはWhat You See Is What You Get（見たままが得られる）の略であり、編集時と出力時の見た目が同じエディタのことを指します。 Zennやesaのように、Markdown記法で編集したものが変換されて表示されるようなエディタは含みません。 このようにWYSIWYGはRTEより狭義の意味になっています。 WYSIWYGエディタ(Google Docs) WYSIWYGではないエディタ（esa） 独自データモデル VS DOMツ
React 19 で変わるアクセシビリティ周りの技術 - SmartHR Tech Blog
こんにちは。アクセシビリティ本部のアクセシビリティエンジニアの五十嵐です。SmartHRでは主にアクセシビリティテスターが見つけた課題を技術的な観点から改善したり、根本的な問題を解決するための仕組みづくりを担当しています。 さて、Meta が開発する UI ライブラリとして長い間人気を博している React ですが、2024年4月に最新版であるバージョン 19 のRC版が公開されており、注目を集めています。 バージョン 19 では "use client" や "use server" でも知られる Server Components を含む様々な機能が含まれる予定ですが、この記事では、そんな React バージョン 19 をアクセシビリティの観点からキャッチアップし、特に便利になりそうな点や、注意が必要になりそうな点などを見ていきます。 forwardRef が不要になった 仮想 DOM
ページ内のテキストを読めなくするChrome拡張を作った - 詩と創作・思索のひろば
世はまさにハイパーメディア時代。何をするにも視覚的なキャッチがないとやっていけない時代です。ブラウザのスクリーンショットを撮ることも多いでしょう。しかしプライベートな内容もそこに映り込んでしまうこともありがち。かといって画像をいちいち加工するのも面倒……というわけで、DOM操作によってテキストを隠す拡張を作りました。 GitHub - motemen/webextension-obfuscate-texts 2022-07-20 追記: Chrome Web Store に出ました Obfuscate texts - Chrome ウェブストア Manifest V3 で作ったせいでほかのブラウザは未対応。 スクリーンキャスト Chrome extension: Obfuscate texts - YouTube ページ内の要素を選択し、「Obfuscate」することで▗▝▌▏▇
モダンな自動E2Eテストサービスを調べてみた(2023年クリスマス版)
これからわかる通り、ステップの追加購入が必要です。 「CI/CD ツールと連携してたくさん回せますよ」というテストサービスも多いですが、計算したらステップ数足りないことに気づくことも同じくらい多いです。 どうせステップ数で制限がかけられているので、テストサービスは日次実行さえできれば良いのでは、とさえ思っています。 MagicPod 検討したプラン: ブラウザテストプラン・スタンダード Autify と BugBug は Chrome のシークレットモードで、 mabl はネイティブアプリでテストを作成するツールですが、 MagicPod は違います。 MagicPod でテスト作成をするときはリモートの VM を立ち上げ、その GUI をブラウザの iframe に映して操作します。 そのため、テストしたい自社のウェブアプリがブラウザの中に小さく表示されます。超独特です。 SALESCO
Intl.Segmenter で和文の改行をいい感じにしてみる
tl;dr ブラウザで文字列を表示する場合画面幅に応じて自動で改行されることがあります。英文などは分かち書きされているためブラウザは単語の区切りなどで改行することができますが、和文は文節が明確ではなく単語の途中で改行されてしまうことがあります。 この記事では、ECMA402 の Intl.Segmenter を用いて和文を分かち書きし、ブラウザに改行可能箇所を教えることでより読みやすいレイアウトを目指します。 (2023/04/14 追記) NPM package として公開しました 🚀 背景 ラテン文字を使用する多くの言語では語と語が空白で区切られていますが(以降分かち書き)、通常、日本語や中国語は分かち書きされていません。 一般的なブラウザでは表示領域(横幅)に対して表示させたい文字列が一行に収まらない場合自動で改行するような挙動になっています。英語のように既に分かち書きされた文の場
a11yとテストを同時に改善する話
これまで、a11y 改善・テスト拡充にあたり「どのように改善すべきか？どのように書くべきか？」という点がハードルだと感じていました。Chrome で a11y tree を確認するには、dev tools の隅の隅をつつく必要があり、あまり体験の良いものではなく、気に入ったエクステンションもありませんでした。 Testing Library は「誰もがアクセスできるクエリー」を優先的に使用することを推奨していますが、アプリケーションがはじめから a11y に考慮された作りになっているとは限りません。これらの背景から「data-testid」のような、テスト向け属性に頼るワークアラウンドで乗り切ることも少なくありませんでした。 Full page accessibility tree 今年 1 月にリリースされたChrome98 の新機能として「Full page accessibility
React Server Components 総まとめ
先日、React Server Componentsについてまとめる機会がありました。 この記事では、React Server Componentsの概要と、デモを触る中で感じたことについてご紹介します。 React Server Componentsとは React Server Componentsは、Reactコンポーネントをサーバーサイドでレンダーする新しい技術です。 一部のコンポーネントをサーバーサイドでレンダーしてしまうことで、アプリケーションのパフォーマンスを上げることを目的とします。 図は、デモの画面のうち、サーバーでレンダーされる部分を青で、クライアントでレンダーされる部分を赤で示したものです。 ページ全体をサーバーでレンダーするのではなく、一部のコンポーネントはクライアントにレンダーさせていることがわかります。 また、React Server ComponentsはCo
あたらしいテストフレームワークVitestをReactで試してみた | DevelopersIO
はじめに こんにちは、CX事業本部MAD事業部の森茂です。 今回まだ開発版ではありますが、昨年末に公開されたVue.jsやViteの作者Anthony Fu氏@antfu7、Patak氏@patak_devが開発しているJestに代わるあたらしい高速テストフレームワークVitestをReactで試してみました。 VitestはVite環境で動作する高速なテストフレームワークで、VueやReact、Svelte、litなどなどさまざまなフレームワークで動作します。ChaiやJestのアサーション、スナップショットが互換的に動作するので既存のテストコードをほぼ同じ書き方で利用することができます。またc8を利用したcoverageの作成にも対応しています。 Jestでは環境の構築にそれなりの手間がかかりますが、Vitestはライブラリのインストールと簡単な設定を追記するだけで利用することが可能で
Webフロントエンドのリプレースを支えるテストの考え方 / JSConf JP 2021
JSConf JP 2021 でトークしたスライドです。 このスライドの内容を文字にしているブログ記事はこちら https://blog.nnn.dev/entry/2021/12/03/123000 トークのアー…
1,000,000件どんとこい！大量のデータ表示に適したチャートライブラリ3選 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
1,000,000件の散布図を表示できたライブラリ データ数1,000,000件の散布図表示に耐え、最終候補として残ったライブラリは以下の3点でした。 Plotly D3FC Apache ECharts Apache ECharts 出典：https://echarts.apache.org/ Apache ECharts GitHub 散布図（1,000,000件） 実現できるチャートの種類が圧倒的に多く、GitHubのスター数も47.3kと群を抜いています。サンプルも豊富で、ドキュメントは詳細です。中国のBaidu社から提供されています。 Plotly 出典：https://plotly.com/javascript/ Plotly JavaScript Graphing Library GitHub 散布図（1,000,000件） Apache EChartsに次いで多機能なライブ
HTML Centricで行きたい私たち - LIFULL Creators Blog
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'}); }, ... }
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React大好き侍が、「もうSolidJSでいいじゃん...//」ってなったワケ。 - Qiita
GitHub - capricorn86/happy-dom: A JavaScript implementation of a web browser without its graphical user interface
Svelte • Web development for the rest of us
