caffeine
Caffeine is a livecoding environment for web browsers, Deno, and WebAssembly. After adding it to a webpage, you can use it to make live persistent changes to that page and other pages running Caffeine, without reloading. You can interact with Caffeine from JavaScript in several ways: as a headless Web Worker, with which you post and receive messages (you are responsible for all DOM manipulation).
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
JavaScript で WebAssembly のバイナリを直接書き出してみた - Qiita
はじめに 趣味の自作言語で WebAssembly を吐いてみようかなと思いました。が、WebAssembly の仕様書を読むだけで理解するのは困難です。そこで手を動かしながら仕様書を少しずつ追いかけていくことで理解しようと思いました。せっかくなので誰か（主に数週間後の自分）の役に立てばなあ、と思い思考の記録を取った次第です。 参考文献 WebAssembly Specification 仕様書です WASM のバイナリの構造 WASM のバイナリは module です(これは正確な言い回しではないかもしれません。Overview の Modulesをよんで)。module の binary encoding はModulesに書いてあります。 ごちゃっとしていて圧倒されますが、以下の3点を押さえると読みやすくなると思います。 module は magic -- version -- se
ブラウザで何が起こっているのかを知る Reporting API と ReportingObserver | blog.jxck.io
Intro Web サービスにおいては通常、Web サーバから取得できるアクセスログやエラーログを取得し解析する基盤を保有するだろう。 しかし、Web サーバから取得できる情報だけでは、ブラウザで何が起こったのかを知るのは限界がある。 今回は、ブラウザ内で起こったことを知るための Reporting API と、その Report の収集について解説する。 Notice 本記事の大半は 1 年以上前に書いたものだが、そのころは仕様も実装もまだまだ落ち着きが無かった。 仕様 report-uri から report-to への移行期 JFV の採用への不安 実装 ディレクティブの実装がバラバラ ReportingObserver では取れるが default group に自動では飛ばない(未実装) ReportingObserver で取った report が JSON Serialize
最新のWeb技術でIoTをする - Qiita
この記事の内容はJSConf JPで話した内容です. 資料全体はこちらにあります。 アジェンダ IoTのはじめかた とりあえずIoTをやりたい人へ IoTとはインターネットとThingsがつながることです。 ざっくりと書くとこんな構成ですね。 この右側のアイコンは皆さんよく知ってるサービスだったりシステムだったりするのではないでしょうか。 メールもslackもよく使いますよね。 逆に左側のセンサ／アクチュエーターはほとんど知らないのではないでしょうか。 直線距離を図る距離センサや、人の有無がわかる人感センサ、物を動かすことができるモーターなどがあります。 IoTをやろう！(というか何かしらハードウェアを作って物理世界に関わろう)とすると、ここのThingsの知識がなくてなかなか難しいことが多いと思います でもじつは**とっても身近なThingsがあります** というわけで、JavaScri
実装して理解する遅延評価の仕組み 〜 thunkを絵に描いて理解しよう・JavaScriptでHaskellを実装！？ - プログラムモグモグ
この記事では, Haskellに用いられる「遅延評価」の仕組みを, 図に描いて説明します. 更に, 遅延評価版のフィボナッチ数の無限列を, JavaScriptで実装します. 遅延評価とはどのように動くのか, 考えて行きましょう. HaskellのコードとJavaScriptのコードの比較 Haskellでの x = y y = 10 と, JavaScriptの var x = y; var y = 10; というコードを考えてください. Haskellのコードは, これだけでは何も起こりません. print xとすると, x = y = 10 となって 10 が表示されます. 一方, JavaScriptのコードは var x = y; を評価した瞬間, ｢ReferenceError: y is not defined｣というエラーが出ます. 更に, main = let x = 1
x-img-diff-js demonstration
x-img-diff-js is a JavaScript(Web Assembly) porting project for x-img-diff, which extracts structual information of a bit different 2 images. Click the following "Calculate" button, then rectangle markers are displayed over the images. Each rectangle stands for: Cyan: Matching region Red: Different parts in the matching region Purple: Keypoints region not included in any matching regions
実践 Off the main thread - from scratch
実践 Off the main thread 実際に Off the main thread をやりつつ、パフォーマンスチューニングをする際にどこに気をつけるべきかを今やっているので、それについて話します。 Off the main thread とは JavaScript の処理は基本的にメインスレッドで実施します。JavaScriptの実行処理以外にも記述された内容を解釈するためのパース処理やGC処理もメインスレッドをブロックします。メインスレッドの処理が多いとUI jankと呼ばれるガタツキ、チラツキ、画面の固まりの原因になります。 UI jankが発生していると、ユーザーがクリックしたり、text入力をしようとしてから反応するまでの時間（Input Latency）が即時ではなくなります。 このUI jankを無くすために、なるべくメインスレッドを阻害する要因を減らすことが Off
Custom Elements を正しく実装するのはとても難しい - ジンジャー研究室
React みたいなコンポーネント作る系フレームワークだと思って Custom Elements を使おうとすると、たちまち死んでしまう。まだ色々試している最中なのでアウトプットはないんだけど、とりあえず今考えてることを書いておく。役立たないし刺されたら困るからポエム宣言しとこうか。ポエムです。 Custom Elements やっていきたい Custom Elements の良さは特定のフレームワークに依存しないところだと思う。例えば React とか Vue とかだとそれぞれのフレームワークの世界にどっぷり浸かってしまい互換性がないが、 Custom Elements ならば普通の要素の延長線上でどこに持って行っても使える。 npm とか使わなくても script タグで CDN とかから持ってくればすぐに動く。夢のよう。もちろん、データフローはアプリケーション固有のものになるだろうか
その月のx番目のy曜日の日付を求める式を1行で書く - Qiita
function getDate(ordinalNumber, weekDay, date = new Date) { return ((7 * (ordinalNumber - 1) + 1) + (weekDay - new Date(date.getFullYear(), date.getMonth(), 1).getDay()) + (-(Math.sign(Math.sign(weekDay - new Date(date.getFullYear(), date.getMonth(), 1).getDay()) + 1) - 1) * 7)) * Math.sign(Math.sign(new Date(date.getFullYear(), date.getMonth() + 1, 0).getDate() - ((7 * (ordinalNumber - 1) + 1) +
3000人に聞いた、2019年最先端のフロントエンド開発者が使ってるツールはこれだ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Ashley Nolanは、CSSとJavaScriptの機能やフレームワークをどれだけ使っているかというアンケートを毎年行っています。 以下では2019年版である、The Front-End Tooling Survey 2019というアンケート結果の概要を紹介してみます。 回答者数が昨年から4割も減ってるのだが一体何があったのだろう。 The Front-End Tooling Survey 2019 - Results 3005人の開発者が、27の質問に回答してくれました。 私の家族に女の子が増えたので集計結果を出すのが遅れました
2019 Javascript engine 俯瞰 - abcdefGets
2019 Javascriptエンジン俯瞰 こんにちは 2019 Javascript Advent Calendarの11日目です 2019はJSエンジンが新たに2つもリリースされた まずFacebook産のhermes もう一つがFFMPEG作者のbellardが実装したquickjs この2つを見ていこうと思う ちなみにhermesは以前にも書いたので正直あまり書くことは無い http://abcdef.gets.b6n.ch/entry/2019/07/22/142510 特徴 hermes C++ FacebookがReact Nativeの高速化用に実装したエンジン レジスタマシンのバイトコードインタプリタを搭載 flowを解釈できる commonjsを解釈して実行できる バイトコードのexportとimportも可能でスタートアップタイムを高速化することが可能 JITはx86
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chrome v83 enables JS module support for SharedWorkers → Starting a new era for multi Browser…
GitHub - GoogleChrome/lighthouse-ci: Automate running Lighthouse for every commit, viewing the changes, and preventing regressions
WebdriverIO - WebDriver bindings for Node.js
GitHub - radekstepan/burnchart: GitHub Burndown Chart as a Service
ジェネレーターで関数モナドとStateモナドを模倣してみた - Qiita
JavaScript + generator で Maybe、 Either、 Promise、 継続モナドと do 構文を実装し async-await と比べてみる - Qiita
GitHub - m4riuz/wasm-collector: Collects all WebAssembly modules from a given website
GitHub - GoogleChromeLabs/comlink: Comlink makes WebWorkers enjoyable.
