BunはNodeより速いのか？ Misskeyで検証 | gihyo.jp
本連載では分散型マイクロブログ用ソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っています。 今回はNode.js互換のJavaScriptランタイム、Bunのパフォーマンスについて、Misskeyのコードベースを用いて検証を行います。 Bunとは Bunは、Node.js（以下Node）互換である後発のJavaScriptランタイムです。 JavaScriptエンジンにNodeで採用されているV8ではなくJavaScriptCoreを採用しているほか、TypeScriptを事前コンパイルなしに実行することもできます。 肉まんのようなマスコットキャラクターが特徴です。 モチベーション そんなBunの公式サイトではNodeよりも大幅に性能上のアドバンテージがあるように紹介されていますが、こうした競合ソフトウェアとの一方的な比較は得てして限られた条件での有利な
Node.js v22 で変わること
2024/04/24 令和トラベルで発表した Node.js v22 で変わることの話です。
JavaScriptパッケージシステム「npm」は巨大なバグを抱えていると指摘し、新たなパッケージシステムを開発する「vlt」。npm作者らの参加を発表
JavaScriptパッケージシステム「npm」は巨大なバグを抱えていると指摘し、新たなパッケージシステムを開発する「vlt」。npm作者らの参加を発表 npmに代わる新しいJavaScriptのパッケージシステム「vlt」（vōlt：ボールト）を開発しているvlt technologyは、同社にnpmの作者であるIsaac Z. Schlueter氏、npmのスタッフエンジニアリングマネージャであったDarcy Clarke氏、npmのCLIチームであったRuy Adornoらが参加すると発表しました。 Node.jsとnpmが作ったJavaScriptのエコシステム サーバサイドでJavaScriptを実行可能にしたNode.jsの登場と、そのNode.jsを基盤にJavaScriptのアプリケーションやモジュールなどをパッケージングして登録し、自由にダウンロード可能にしたレジストリで
Node.js の原罪 - from scratch
Intro ちょうどタコピーの原罪が流行ってるのでこのタイトルにしたけど結構気に入ってる。 d.potato4d.me この話を読んでの感想とここまで大きくなった Node.js の振り返りをしようと思う。 どんなプログラミング言語であってもみんなから使ってもらって開発者をハッピーにしたいと思ってる。ただ最初は良かったと思ってた機能がなんか古臭くなったり、他にクールな機能を持ったものが登場したことによって徐々に飽きられていき、最終的に他の言語に乗り換えられる。 まぁどんな言語も同じだと思う。C言語だって生まれた当初はすごくクールでみんなをハッピーにしてた。今丁度「戦うプログラマー」を読んでるが、C++が出てきて、周りのエンジニアが C++ を使おうとするシーンが出てくる。そこで、「あんなの使って何が良いんだ、Cで十分だろ」とWindows NT 開発リーダーのデーブカトラーが言ってたりする
Denoのフロントエンド開発の動向【2022年春】
半年程前に、以下のような記事を書きました。 Denoでのフロントエンド開発に関して、ここ半年程でまた大きな動きがあったため、改めてまとめていきたいと思います。 Aleph.js v1.0.0のアルファバージョンがリリース Deno製のフレームワークであるAleph.jsのv1.0.0 アルファバージョンが公開されました。 現在、v1.0.0のリリースに向けて積極的に開発が進められています。 Aleph.jsやesm.shなどの作者であるJe Xia氏がDeno社に加わったこともあり、ここ半年で大幅に開発が進んでいる印象です。 また、Aleph.jsは元々はNext.jsに影響を受けたフレームワークという位置づけでしたが、ここ最近ではRemixなどのフレームワークの影響も徐々に受けているような印象を感じています。 ここでは、Aleph.js v1に向けて行われている大きな変更などについて解説
yarn と npm の栄枯盛衰
yarn と npm の栄枯盛衰2021 年 8 月に yarn の v3 がリリースされました。2020 年の同月あたりに yarn v2 がリリースされたので、約 1 年ぶりのメジャーバージョンアップになります。 v1 → v2 のパラダイムシフトは強烈でしたが、 v2 → v3 は berry というパッケージ名は相変わらずで、 v2 の正統なバージョンアップでありちょっとだけ物足りなさを感じてます。 Get Started なにはともあれ、とりあえずは触ってみましょうか。 Node.js ≥ 16.10 であれば、 Corepack を使って以下のコマンドで yarn v3 をインストールできます。 $ corepack enable $ corepack prepare yarn@3.0.0 --activate # yarn.lock や README.md が生成される $
useEffect完全ガイド
あなたは Hooks を使って複数のコンポーネントを書きました。ちょっとしたアプリも作ったことがあるでしょう。満足もしている。API にも慣れて、その過程でコツも掴んできました。しかも重複したロジックを転用できるよう Custom Hooks を作り、同僚に自慢して見たり。 でも useEffect を使う度、いまいちピンときません。class のライフサイクルとは似ているけど、何かが違う。そしていろんな疑問を抱き始めます。 🤔 componentDidMount を useEffect で再現する方法は？ 🤔 useEffect 内で正確に非同期処理を行う方法とは？ []ってなに？ 🤔 関数をエフェクトの依存関係として記すべき？ 🤔 非同期処理の無限ループがたまに起こるのはなぜ？ 🤔 古い state か props がエフェクト内にたまに入るのはなぜ？ 私も Hooks を使
npm trends: Compare NPM package downloads
Sick of boring JavaScript newsletters?Bytes is a JavaScript newsletter you'll actually enjoy reading. Delivered every Monday, for free.
Home
Go beyond crash reporting, error tracking, logging and error monitoring. Get instant and accurate alerts — plus a real-time feed — of all errors, including unhandled exceptions. Our automation-grade grouping uses machine learning to reduce noise and gives you error signals you can trust. A better way to discover errors Instantly see the impact of crashes and errors with metadata — like which custo
GoogleAppsScriptローカル開発用の公式CLI(node-google-apps-script)がついに登場したので試してみる - Qiita
はじめに これまで Google Apps Script を開発する方法として公式に提供されているものは Web 上のスクリプトエディタしかなかったんですが、 先日 Google Developer Japan のブログに GAS についての記事が投稿され、その中で node-google-apps-script という CLI が紹介されていました。 Google Developer Japan のブログ記事：Apps Script による高度な開発プロセス 元記事（英語）：Advanced Development Process with Apps Script GAS のファイルをローカルで管理するツールはこれまでにも gas-manager というCLI があったんですが、どのような違いがあるのか気になったので試してみました。 ※ gas-manager については以前 Qiita
yahoo/fetchrを使う - Qiita
先日参加した、isomorphic tokyo meetupで紹介されていたfetchrが良さそうだったので、使ってみた。 fetchrが解決する課題 React＋Fluxでサーバサイドレンダリング時に、superagentやaxios、isomorphic-fetchなどのIsomorphicなHTTPクライアントを使ってデータをフェッチするが、そのまま使うと下記のような課題にぶつかる。 ブラウザから直接BEのAPIにアクセスできない（またはさせたくない、外部のAPIでキー・シークレットをブラウザ側で持ちたくない）場合、そのAPIとProxyするエントリポイントを作る必要がある。 フェッチ部分のロジックが共有されるので、ブラウザではWeb API経由でフェッチして、サーバサイドレンダリング時は直接DBにクエリを叩きたい、みたいなのを自分で実装すると面倒。 fetchrはBEや外部のAPI
新しいクラスプラットフォームデスクトップアプリケーションライブラリ yue - Qiita
NW.jsやElectronの作者である、zcbenz氏が新しいクロスプラットフォームライブラリyueをつくりはじめました。 え、Electronを使ってるんだけどと思った人は落ち着いて大丈夫、フルタイムでElectronの開発を続けているとのこと。 では、今度のyueは何を目指しているのか。 Uses native widgets; Works on all major desktop platforms; Has a modern and clean C++ interface; Has good support for High DPI; Uses windowless controls on Windows; Generates small executable size; Friendly license for closed source apps. ネイティブウィジェットを扱
2016 JavaScript Rising Stars
The JavaScript community is going full speed on innovation, what was once trendy becomes old-fashioned a few months later. 2016 is over, you may think you missed something important? Don't worry, we are going to review what were the main trends. Let's see by the numbers which projects got traction in 2016, by comparing the numbers of stars added on Github, over the last 12 months. In 2015, React w
プログラミングを勉強するなら広い意味での環境構築は大事だなと感じた話、あるいはN予備校の良さを再確認した話 - 時代と寝た女
2017 - 01 - 09 プログラミングを勉強するなら広い意味での環境構築は大事だなと感じた話、あるいはN予備校の良さを再確認した話 N予備校プログラミング勉強記 N予備校でプログラミングを学び始めて４カ月が過ぎました。 その間に、プログラミングを勉強する上で一番大事なのは環境構築だなと、ものすごく感じました。 直接的な意味で言えば、今N予備校で勉強中のNode.jsを使い始める時に行った環境構築です。 最近のプログラミング学習サイトだと、環境構築無しですぐにプログラミングができます、っていうのを売りにしている運営会社をよく見かけますけど、N予備校の場合はその環境構築にしっかりと時間を割きます。 ここにはカリキュラム作成者の意図が明確に反映されていて、最初に苦労するであろう環境構築ができるようにならないと、現場で使えるプログラマーにはならないという考えのようです。 僕も初心者ながらに色
GIFアニメーションを再生し終えてから次のGIFを表示するElectronアプリを作っていました - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 作っていました。 khsk/electron-gif-loop: Gifyからgifを取得し、最低1ループはアニメを見せるgifビューワー 備忘録。 特徴 最低1ループはアニメーションを見せる、スライドショー的gifビューワーです。 GIPHY からgifを取得しつづけます。 任意のタグを複数登録することで、好きなジャンルのgifを表示できます。(精度はGIPHYAPIに依存します) 可能な限り、ループの終了直後に次の画像を表示します。 画面のリサイズと移動が可能です。 常に前面表示の切り替えが可能です。 デモ 動機 昔からgifアニメ
pixiv Sketchのフロントアーキテクチャ - pixiv inside [archive]
（ピクシブ株式会社 Advent Calendar 2016 12日目の記事です） qiita.com こんにちは、エンジニアの id:geta6 です。普段は主にpixiv Sketchの開発などに携わっています。 さて、先日ISUCON6の本選が開催され、ISUketchというReactを使ったお絵かきサービスが話題になったかと思います。 この問題で採用されたアーキテクチャは『pixiv Sketch』のアーキテクチャを参考にしたものとなっています。 パフォーマンス等に関しましては本選の感想として良質な記事がいくつも執筆されていますのでそちらに譲るとして、今回はこのアーキテクチャの設計意図や利点について話します（2年前のリリース当初からずっとこの構成なので今さら感はありますが）。 どういうアーキテクチャか pixiv SketchのWeb版は、2つのサーバーから構成されています。 1つ
![pixiv Sketchのフロントアーキテクチャ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/cf2ee8d96d203c862e1f96398c70d3fb29a28d8d/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fc238d99d27621a6e29584c8bae22f1e41cf3e575%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fg%252Fgeta6%252F20161212%252F20161212144353.png)
リクルートテクノロジーズのフロントエンド開発 2016 - from scratch
前書き このエントリーは Recruit Engineers Advent Calendar の 1日目の記事です。 www.adventar.org リクルートテクノロジーズのフロントエンド開発 リクルートテクノロジーズではいくつもの並行するタスクが走っていて、プラットフォーム基盤と呼ばれる基盤技術開発とインフラソリューションと呼ばれるインフラ開発、後はアプリケーション開発支援などのタスクが存在します。 アプリケーション開発支援の中でもウェブフロントエンド開発は目下のところ重要タスクとされており、色んなやり方をトライアルしています。 基本的には、 React Redux Node.js という組み合わせでフロントエンド開発をしています。 主には以前 ubb.jp というイベントで発表したこの資料に記載されている内容でやっていますが、諸々補足します。 リッチなウェブアプリケーションを作るた
Node.jsでのJavaScriptメモリリークを発見するための簡単ガイド | POSTD
目次 初めに 極小理論 ステップ1. 問題の再現と確認 ステップ2. 最低3回のヒートダンプ採取 ステップ3. 問題の発見 ステップ4. 問題解決の確認 他のリソースへのリンク まとめ Something you might want to bookmark: Simple Guide to Finding a JavaScript Memory Leak in Node.js by @akras14 https://t.co/oRyQboa8Uw — Node.js (@nodejs) January 6, 2016 注釈：お気に入りに登録してください。 Simple Guide to Finding a JavaScript Memory Leak in Node.js （Node.jsでのJavaScriptメモリリーク発見簡単ガイド） @akras14 http://www.ale
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - OnetapInc/chromy: Chromy is a library for operating headless chrome. 🍺🍺🍺
新横浜密着情報シンヨコのサイト
