Node.js にプロセスレベルの Permission が入りそうな話 - from scratch
Node.js の Permission についての解説を行います。 Node.js に Permission 機能が入りそう。 すでに PR が出されており、 land も間近です。おそらく次かその次くらいのリリースで入ることになるでしょう。 github.com おそらく初期リリースでは experimental flag を付けた上で、 fs, child_process, worker のパーミッションを許可するかどうかに留まり、 net, env などのパーミッションは今後になるでしょう。 以下の方法で利用します。 // filesystemの読み書きを許可する $ node --experimental-permission --allow-fs foo.mjs --allow-fs ファイルシステムの読み書きを行えるようにする --allow-fs-read= に記載のファイ
Node.js fetch の内部の話 - from scratch
前置き この記事は リクルートエンジニアアドベントカレンダーの3日目の記事です。 Recruit Engineers Advent Calendar 2022 - Adventar ちなみにココで書いたやつを一部抜粋させていただいております（ネタ切れにより過去投稿を利用してしまっております。。。すいません。。。） www.codegrid.net fetch が Node v18 から試験的にサポートされた ブラウザでは数年前から採用されていた HTTP リクエストを行う関数の fetch が global 空間に関数として作成されました。使うだけなら特に何のフラグもいりません、その代わり使うと Experimental であることを知らせる Warnings が出ます。 // fetch.mjs const response = await fetch('https://api.gith
Unhandled Rejection の考え方 - from scratch
はじめに twitter 上で議論になっていたネタを本人の許可を得て記載しています。 Node.js でだけ発生する非同期関連の謎現象を発見した🤔 複数回連続で、非同期処理を挟んだ関数から返した非同期関数を、非同期に実行すると allSettled で待ち受けされずにその場で例外が発生する。 これはバグなのかな...https://t.co/w5C9wKEAOA pic.twitter.com/y3pz4ajndF— shqld🦭 (@shqld) January 4, 2022 実はこの話は会社の中でも一回議論になったネタなんですよね。僕も microtask と呼ばれる Promise キューイングの仕組みとイベントループでタスクをハンドリングする仕組みの両方が組み合わさった時に Unhandled Rejection が起きる理由がわかりにくくなるなーと思っています。誤解していた
Node.js の assert の小話 - from scratch
Node.js Advent Calendar の4日目の記事 です。 Node.js の assert は結構歴史が深いです。あまり直接使ってる人は少ないかもしれません。使うとしたら test で使ったりするケースでしょうか。 それも最近は jest に生えてる便利ライブラリを使うほうが多いのかもしれないですね。 unassert なんかで開発中に埋め込んでいるケースもあるかもしれません。このようにたまに使うこともあると思うので、覚えておくと良いでしょう。 assert には 4 年ほど前から strict assertion mode というのが追加されています。 nodejs.org 今日はそんな小話を。 require("assert") は直接使ってはいけなかった。 もう昔の話ですが、 require("assert") が deprecated になっていた時期がありました。知
Node.js コアモジュールの import/require には `node` schemeがつけられる - from scratch
Node.js アドベントカレンダーの 3 日目の記事です。空きを埋める形で始めました。 qiita.com www.codegrid.net CodeGrid でも書かせていただきましたが、 Node.js で ES Module / CommonJS を使ってコアライブラリのロードをする際、 node から始まる scheme を付けることが可能になっています。 nodejs.org // ESM import fs from "node:fs/promises"; // CJS const http = require("node:http"); これにはいくつかのメリットがあります。基本的につけておくことが望ましいです。 今回はメリットをいくつか紹介します。まだこれがデファクト・スタンダードになっている訳ではありませんが、これから付けてもらうように推奨していきたいと思います。 メリ
Node.js や deno に Web Standard な API をなんでも取り入れるのが良いことなのかについて - from scratch
この記事は Node.js Advent Calendar の 11 日目の記事です。 qiita.com Web API と Node.js ES2015 以前の Node.js は Web Standard な API の中で足りないものを自分で補う形で進化を続けてきた。 Callback や Event 主体での非同期処理や Common JS な形でロードできる独自のモジュールの仕組みがその筆頭だと思う。ただ逆に Web Standard な API が流行ると今度はそれに追従していかないといけなくなってきた。 ES2015 以後に流行ったものといえば、 Promise 主体での非同期処理であり、 async-await での処理だと思う。また、 ES Modules の台頭もあり、今日では Node.js でも普通に呼び出すことが可能になった。 今ではどちらも Node.js で
Node.js で最近変わりそうな Permission Policy について - from scratch
さてさて、 25日目の Node.js アドベントカレンダーです。もう年の瀬ですね。振り返りシーズンなんで色々書きたかったんですが、ネタを見つけているうちにこの日になってしまいました。 Permission Policy とは Node.js に新しく Permission を提供しようという試みです。元々 Node.js では同じプロセス内で動いてしまえば どんなモジュールであろうと同じ権限で色々できますね。外部ネットワークにアクセスしたり、ファイルを読み書きしたり。 プロセスに元から許可されている権限は全てできてしまいます。これが今まででは普通でしたが、今後はもしかしたら変わるかも？という話です。 権限に関して制限をかけて、拒否させることが可能です。 以下のような要領で拒絶させることができるようになります。 $ node --policy-deny=net 上のオプションでプロセス内の
【翻訳】Date and Times in JavaScript - from scratch
この記事は littledan から依頼を受けて、翻訳しています。広く Date and Times の JS プロポーザルについて意見がほしいとのことです。 意見は以下の場所にポストできます。 docs.google.com 原文: blogs.igalia.com tl;dr: Temporal のプロポーザルについてフィードバックを求めています。 Polyfill を試したら、サーベイの回答を送ってください、ただしまだ本番環境では使わないでもらいたいです。 JavaScript の Date クラスは壊れています、しかし Breaking the Web を起こさずに修正する方法はありません。風のうわさでは、 Date クラスは 10 日で作られた JS Engine のhackに含まれたもので、 java.util.Date に基づいたものと言われています。しかも java.uti
web.dev live 2020 を聴講した - from scratch
今年はコロナの影響でいろんなイベントがオンラインになったり、中止になったりしてますが、 web.dev live 2020 が7月初頭にやっていたので、聴講してきました。 web.dev その中でも面白かったものについていくつか紹介します。 Day 1 ほぼ Core Web Vitals についての話でした。 以下のトークが面白かったです。 What's new in speed tooling Optimize for Core Web Vitals Core Web Vitals についてはもう既にたくさん資料があると思いますが、一応解説しておきます。 Core Web Vitals 初期表示の新しい指標です。去年くらいからずっと Chrome Dev Summit とかでは言われていて、既にLighthouse をはじめとして、色々なツールでサポートされています。Largest C
2020年の JSConf.jp は中止にします - from scratch
表題の通り、 2020年の JSConf.jp は中止にします。2021年の開催を目指します。 TC39とのコラボレーションとかも検討していたのですが、楽しみにしていた方々、大変申し訳ございません。 いろいろな葛藤はありましたが、 JSConf.jp の前身になった Node 学園祭のときから「豪華なスピーカーに会えること」「Node.jsやTC39の中にいる人と直接交流できること」「知見が共有できる場所」というのを大事にしてきたのですが、オンライン開催ではその意味が半分以上失われてしまうと思っており、 JSConf.jp は開催しません。 ただし、少し形を変えて、オンラインで開催する小さなカンファレンスは開催するかもしれません（名前は TBD です、 JSHome とかにするかも？）。 よろしくおねがいいたします。
実践 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
Dual Package Hazard - from scratch
この記事は Node.js Advent Calendar 2019 の 11 日目の記事です。 qiita.com 今回は全 Node.js で ES Modules を利用するユーザーが知っておくべき Dual Package Hazard について紹介します。 ESModules がフラグ無しでサポートに。 これまでは ES Modules は --experimental-modules フラグが無いと使えませんでしたが、 フラグ無しで Node.js v13.2.0 から使えるようになりました。ES Modules については CodeGrid の記事で詳しく書いているのでそれを一読していただけると理解がスムーズになると思います。逆に読んだ方は Conditional Exports / Dual Package Hazard の節まで飛ばしてもらって構いません。 www.cod
JavaScript Registryの今後 - from scratch
さて、前回は tink と yarn v2 における CLI 戦略の話でした。次は JavaScript Registry についてです。 ちなみにこの内容が今回 JSConf.EU 2019 で一番盛り上がったトピックです。 JavaScript Registry とは JavaScript Package をバックエンドで管理しているサービスです。 npm が管理しているものがいちばん有名です。他にも GitHub が管理する Registry が公開される予定です。 The economics of Package Management the economics of package management slide: github.com video: www.youtube.com 「Package Managementの経済」というタイトルです。 聴講者からすると、何話すのか
npm, yarn による zero install 戦略 - from scratch
jsconf.eu 2019 に行ってきました。 特に npm や yarn の今後の話とそもそも Registry をどうしていくか、の話があったのでお知らせします。 そもそも Registry をどうしていくかについては次のエントリで話します。 tink: A Next Generation Package Manager npm の次のコマンドラインツールである tink が紹介されていました。 github.com presentation: github.com video: www.youtube.com そもそも npm の仕組み ローカル依存ファイルを読む (package.json, package-lock.json, shrinkwrap.json) 存在しないパッケージのメタデータをfetchする 木構造を計算して、実行する（npm v3 以降だとflattenする
JavaScript が読み込まれる前でもWeb Applicationを動かす - from scratch
今回は最近取り組んでいる、 JavaScript が読み込まれる前であっても「ちゃんと」 Web Application が動作するように作る話をします。 Server Side Rendering における注意点と対策 BFFを使ってServer Side Rendering をすることに数年前から取り組んでいます。 まずはSSRをやる上での注意点と対策について紹介します。 SSRをすることはSEOのためだと思われがちですが、個人的にはSEOのためにしているわけではなく、 First View を向上するため（特に First Meaningful Paint を向上するため）にやっています。 First View SEOとSSRに関しては Google が最近出したこの記事の SEO Considerations 節が詳しいです。ここでは説明しません。 SSRをしない、Client S
Chrome Dev Summitに参加しました！ - from scratch
Chrome Dev Summit に初参加しました！色々トピックとして気になったものを紹介してます。後直接 Addy Osmani とか Paul Irish とかに聞く機会があったので、色々ついでに聞いてきました。 Chrome DevRel teams create a Chrome cake #ChromeDevSummit [pic.twitter.com/5u6VPZ0oHb](http://pic.twitter.com/5u6VPZ0oHb)— Yosuke FURUKAWA (@yosuke_furukawa) November 12, 2018 Chrome も 10 周年なんですよねー。感慨深い。 1日目は「現在のChromeでできること、やってること」という感じで、ケーススタディやツールチェインの話が多めでした。 2日目は「未来のChromeでできること、今後やるべ
Node.js における設計ミス By Ryan Dahl - from scratch
Ryan Dahl は Node.js の original author ですが、彼の作ったプロダクト deno に関するトークが jsconf.eu 2018 でありました。 Node.js にずっと関わってきた僕が見て非常に興奮するような話だったので、しばらくぶりにブログに書き起こすことにしました。 背景 Ryan Dahl は2009年に Node.js の話を初めて公の場に公開しました。その時の「公の場」というのが「jsconf.eu 2009」です。 www.youtube.com Video: Node.js by Ryan Dahl - JSConf.eu - 2009 この発表から Node.js が広まり、今やサーバのみならず、IoTデバイス、デスクトップアプリなど、様々なところで動作しています。 で、今回はその発表から9年の歳月が経過し、Node.jsに対しての設計不
NaN === NaN が false な理由とutil.isDeepStrictEqual - from scratch
NaN === NaN は false NaN、つまりは Not a Number 同士の同値比較が false になるのは、よく JavaScript とかで罠だと言われていますが、罠でもなんでもないです。 false が返るという仕様です。仕様の経緯を追うとすぐに『 IEEE754 という浮動小数点の標準規格で決められているから』、という理由がヒットします。 では IEEE754 ではなんで NaN == NaN を false にしようという話になったのか、というのを調べてみました。 今回はそういう歴史の話です。 IEEE754 現在のプログラミング言語の処理系の多くが採用している浮動小数点の標準規格です。 この標準規格は以下のことを定義している。 - 基本形式: 二進および十進の浮動小数点数データの集合。有限な数（符号付ゼロと非正規化数を含む）、無限、特殊な「数ではない」値（NaN
【書評】『超速！ Webページ速度改善ガイド 』を読みました。 - from scratch
ご恵贈頂いた本である『超速！ Webページ速度改善ガイド 』を読み終わったので紹介します。 gihyo.jp あほむさんと SSR Panel Talk した時の話 いきなり関係ない話をしますが、 著者のあほむさんとPixel Gridのりぃさんと一度 Node 学園でパネルトークをやらせていただきました。その時の話で印象的だったのが、下記の話でした。 セキュリティやパフォーマンスも非機能要件だが、セキュリティは『実施しなかったら会社に与えるダメージが大きい』のに対してパフォーマンスは『実施しなくても会社に与えるダメージは見えにくい』 ただだからといって疎かにしていいわけではない、セキュリティは損害が会社のリスクとして見えやすいが、パフォーマンスはユーザビリティといった売上部分の根幹に関わる 幸い、あほむさんの会社にはたまたまパフォーマンスに気をつけてる人が多く、そういう人を育てる土壌もあ
Ayo.js について - from scratch
Ayo.js とは 「Node.js の fork です。」と言ってもまだできたばかりで正直このタイミングで記事にしてもまだ語ることはそんなに多くないです。 ただし、JavaScript界隈が騒ぎになりかけていることは確かです。日本でも発言が増えてきたので自分なりにまとめて今時点での話をしようと思います。 ちなみに読み方は好きに読んでくれ、と言われてます。 「アイ・オー」でもいいし、「エイ・ヨー」でも良いとのことです。ネーミング的には昔あった io.js fork騒動を想起させるネーミングになってます。もしも io.js についてご存じない方もいるのであれば、こちらをご参照ください。 yosuke-furukawa.hatenablog.com Ayo.js の目的 https://github.com/ayojs/ayo/blob/zkat/values/VALUES.md ここを見ると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
