The Bun Shell | Bun Blog
JavaScript is the world's most popular scripting language. So why is it hard to run shell scripts in JavaScript? import { spawnSync } from "child_process"; // this is a lot more work than it could be const { status, stdout, stderr } = spawnSync("ls", ["-l", "*.js"], { encoding: "utf8", });
Why I Won't Use Next.js
You’ve got a new project to work on. Or you’ve got an existing project you’re motivated to upgrade to a more modern approach. Or perhaps you’re dissatisfied with your current modern framework or second-guessing yourself and you’re investigating alternatives. In any case, you’ve got a decision to make. There are lots of “modern” frameworks to choose from. Even if you’re not facing this choice right
SvelteはなぜReactよりも優れているのか
Svelte は比較的新しいフレームワークです。主に、仮想 DOM の課題が浮き彫りになってきた後で、それを解消しようというモチベーションで開発されています。なぜ Svelte が React や Vue などのように仮想 DOM を採用していにないのかについて、この記事でまとめてみようと思います。 読み書きしやすい：リアクティブなコンポーネントを実装するための"高級言語" 高速：仮想 DOM を利用しない 1. 読み書きしやすい：リアクティブなコンポーネントを実装するための"高級言語[1]" Svelte はリアクティブなコンポーネントを実装するためのコードを記述する上で一般的な UI フレームワークよりも人間が扱いやすい設計になっています。具体的に言うと、記述量が少なく、理解しやすい構文を実現しています。 例えば、React で以下のようなコンポーネントがあった場合を想定します。 im
node_modulesの問題点とその歴史 npm, yarnとpnpm
皆さんnpmパッケージのバージョンを上げるときにハマって依存地獄から抜けられなかったことはありませんか？ 私はあります。 複雑怪奇な依存関係を調べてみようとnode_modulesを覗いてみて、そのカオスっぷりに臭いものに蓋をしたことはありませんか？ 私はあります。 そこでnode_modules以下について調べてみたのですが、node_modulesにどんな問題点があって、npmやyarn, pnpmは何を目指していたのか時系列順に紐解いた方がわかりやすいことに気づきました。 ここでは初期のnpmが抱えていた問題から今に至るまでを順を追って説明します。 するとnode_modulesの仕組みの他に、各パッケージマネージャの方針の違いが見えてくるはずです。 初期の頃のnpm (~2015年以前) この頃はシンプルで、依存関係はそのままnode_modulesのディレクトリ構造に反映されてい
Web フロントエンドの実装において本来の機能を損なってはいけない
Web フロントエンドの実装において本来の機能を損なってはいけない 2022.12.24 データの取得・ルーティング・フォームの値の管理に至るまで JavaScript で制御するようになった結果、本来備わっていた機能を損なう形で実装されるような間違いが起きるケースも発生してしまいました。見た目上操作に不都合がないのですが、修飾キーが有効でなかったりと、とある要素が当然に持っているべき機能が失われていることがよくあります。 昨今の Web フロントエンドの開発においては、React や Vue.js などを利用した SPA を採用することが多くなりました。従来の MPA と比較して、リンククリック時やフォーム送信時にページリロードを挟まないので、高速な画面遷移を実現できるため、快適な操作を実現できます。 一方データの取得・ルーティング・フォームの値の管理に至るまで JavaScript で
React ステート管理 比較考察 - uhyo/blog
こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント（使用者）で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子
末尾呼び出し最適化とJavaScript
著者情報 : kota-yata.com プレゼン動画 : https://www.youtube.com/watch?v=BcaPCnWZuvY
I don't want to do front-end anymore
I started coding when I was 14, around 2007 or so. The very first thing I wrote was HTML, then CSS. I liked making stupid little web pages containing youtube embeds and guest books (anyone remembers those?) full of marquees, blinks and gifs. Lots of gifs. The pages were very simple, but joyful to make and also to use. At the time I had no idea that you could make any money with making web pages, I
WASMとRustはVue.js/React.jsを打倒するのか？ - JSへの侵略の歴史
はじめに 「Typescriptの次はRustかもしれない」という記事がバズってるのを見かけました。 なかなか面白くて、PAとしてのWASMとRustを比較している記事です。ちょうど最近「レガシーおじさん、SPAを始めてみた。そして限界を知る」でも書いた通り最近SPAに手を出してみたのですが、いろいろやろうとするとSSRのためのBackend for Frontend (BFF)等が必要になるとわかり「これJSでやる必要なくない？」とも感じていたのでちょうど良かったです。 こういうのを見るとRIAやGWTのように似たアプローチで廃れた技術や、登場が早すぎたMeteor、今も頑張ってるMSのBlazorなど色々頭をよぎります。といわけで歴史を俯瞰する意味でHTML + JavaScriptとそれ以外の技術のせめぎ合いの歴史やMSのBlazorやRustのyewなどWebassemblyを使う
そろそろJavaScriptに採用されそうなOptional Chainingを今さら徹底解説 - Qiita
みなさん、Optional Chaining使ってますか？ 私は先日出たTypeScript 3.7 Betaを小さいプロジェクトに導入して使ってみました。これはとても快適ですね。 例によって、Optional ChainingはECMAScriptに対するプロポーザルの一つです。つまり、もうすぐ入りそうなJavaScriptの新機能です。プロポーザルはたくさんの種類がありますが、その中でもOptional Chainingはその高い有用性からこれまで多くの注目を集めてきました。Optional Chainingは2019年6月のTC39ミーティングでStage 3に上昇し、いよいよ正式採用が近く期待も高まってきたところです。TypeScript 3.7にも導入されたため、TypeScriptユーザーの方々は11月上旬に正式リリースが予定されているTypeScript 3.7を今か今かと待
Can (a== 1 && a ==2 && a==3) ever evaluate to true?
Moderator note: Please resist the urge to edit the code or remove this notice. The pattern of whitespace may be part of the question and therefore should not be tampered with unnecessarily. If you are in the "whitespace is insignificant" camp, you should be able to accept the code as is. Is it ever possible that (a== 1 && a ==2 && a==3) could evaluate to true in JavaScript? This is an interview qu
jQueryが必要とされなくなってきたのは, Reactなどの他のフレームワークが登場したせいではなく, 標準DOM APIが進歩したおかげです
jQueryが必要とされなくなってきたのは, Reactなどの他のフレームワークが登場したせいではなく, 標準DOM APIが進歩したおかげです JavaScript Advent Calendar 2017 - Qiitaの2日目の記事です. 何故この記事を書こうと思ったか JavaScriptの定番ライブラリであるjQueryは, 最近以前と比べて必要とされなくなってきました. その理由はよく, Reactなどの他のフレームワークが登場したせいだと勘違いされています. しかし, jQueryが必要とされなくなってきた理由は標準DOM APIの進歩によるものです. この記事ではそれを書いていきます. なお, この記事ではReact Nativeについて触れる必要がないため, React DOMのことも一緒くたにReactと記述します. また, 私がweb開発を開始したのは3年前ぐらいから
やはりHTML/DOMは再発明されるべきじゃないか - mizchi's blog
と思う次第である。以下理由。 JavaScript, GUI設計の今 JSはそのプラットフォーム特性上、あらゆる言語の使用者の、あらゆる不満が集まる場所で、ヘイトを集めやすい環境だと思う。近年は npm というプラットフォームの登場でエコシステムが生まれ、思いつく限りあらゆるメソッドが適用されてきた。貧弱な言語基盤だが、その中で生き残った方法論が、今一番GUIの課題を上手く扱えている、と自分は考えている。 React/Redux や Angular によって、Flux/MVVMという抽象パターンが枯れてきたように思う。(この際、現場はまだ jQuery だぞ、みたいな話は無視する)。要は View は State の写像である、ということに尽きる。State はシリアライズ可能(JSON)で、Flux Action/Rx.Observable の Event Stream を入力とし、それ
Announcing TypeScript 2.1 - TypeScript
We spread ourselves thin, but this is the moment you’ve been awaiting – TypeScript 2.1 is here! For those who are unfamiliar, TypeScript is a language that brings you all the new features of JavaScript, along with optional static types. This gives you an editing experience that can’t be beat, along with stronger checks against typos and bugs in your code. This release comes with features that we t
JavaScript(ES2015)でvarやletを使う必要はほぼ無い - id:anatooのブログ
ES2015でvarやletを使う場面はほとんど無いので、まずconstを使う。constだとダメな場合にはletを使う。 背景 ES2015では、変数を宣言するための文法としてconstとletが導入された。 const foo = 'foo'; let bar = 'bar'; constは再代入できない変数を宣言できる。letは再代入できる変数を宣言できる。 const foo = 'foo'; foo = 'hoge'; // ERROR let bar = 'bar'; bar = 'hoge'; // OK あれ、じゃあvarとletは同じなの？っていうとそうではなく、letやconstはvarとは違って、関数スコープよりも細かなブロック単位のスコープを提供する。例えばconstやletを使うと、if文やfor文などのブロック中でのみ有効な変数を宣言できる。 で、プロジェクトに
Microsoft Edge’s JavaScript engine to go open-source
Updated on 1/13/16: The ChakraCore GitHub repository is now open Today at JSConf US Last Call in Florida, we announced that we will open-source the core components of Chakra as ChakraCore, which will include all the key components of the JavaScript engine powering Microsoft Edge. The ChakraCore sources will be made available on GitHub under the MIT license next month. Gaurav Seth on stage at JSCon
今一番JSで熱いゲームエンジン、RPGツクールMVのランタイムコードを読んでみた - Qiita
一昔前にCanvasが実用段階になった頃、JSのゲームエンジンが大量に出てきたことがありました。それらは大抵DOM/CanvasのFallbackを持っていたのですが、今現在の状況は、実際には非効率なメモリ消費やモバイルのブラウザのフラグメント化で実用に足るものがなかった、という辛い現状があります。 そんな中pixi.jsという描画ライブラリが台頭してきました。このエンジンは webglとcanvasの fallbackを持ち、(いくらかのバグはありつつも)DOMを切ったことで現実的なパフォーマンスの課題をクリアできるのでは？という期待感が高まっています。 Pixi.js - 2D webGL renderer with canvas fallback http://www.pixijs.com/ そして 2015年、RPGツクールMVが発表され、ブラウザ吐き出し対応がアナウンスされました
socket.io(SIOSocket)をネタにJavascriptCoreに入門してみる with Swift - Qiita
こんなふうに書けていました。 こういうのを、少しの労力で作れるなら、javascript界(以後jsと書きます)の膨大な資産をios界でも気軽に使いまわせるのでは？と思い興味を持っていました。 ということで、今回はこのSIOSocketをSwiftで換装してみて、時が来たら同様のことができるように前知識を蓄えておこう、というコンテンツになります。 JavaScriptCoreについて 今回のようにjsのコードをベースにしたswiftクライアントを作る上で欠かせないのがJavaScriptCore.framework。 これは端的に言うと、JavascriptとObjective-C(Swift)をブリッジしてくれるObjective-C APIです。2013年からあって、Mac/iOS両方で使えます。 ※ 元々Objective-CのAPIなので、Swiftでは使いにくい部分がままあります
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft、Excelカスタム関数としてJavaScriptのサポートを発表
『JavaScript(ES2015)でvarやletを使う必要はほぼ無い - id:anatooのブログ』へのコメント