The npm blog has been discontinued. Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog. Last week, the npmjs.com website received the most ambitious update in its history. We said “cheerio” to the old hapi-and jQuery-based website, and “hello” to a state-of-the-art web application based on Spife and React. Hello, React We decided to replace the old npmjs.com we

昨日 Twitter でこんな記事を発見しました。 PWA が来るって言っているエンジニアは今すぐ辞めろ 「instagram の PWA が最高〜！ネイティブと見分けつかない！！とかほざいているグー○ルのエバンジェリストだかエンジニアが騒いでいたので触ってみたのだが、オワコンであった。」 もしかしてこれのことかな？ Instagram PWA is sooooooo impressive. I probably won't be able to distinguish it with its native app. InstagramのPWAが、デキが良すぎて感動してる。ネイティブアプリと見分けられる自信ない。 pic.twitter.com/DS8TfceBZ6 — Eiji Kitamura / えーじ (@agektmr) 2018年1月26日 確かに、この言い方は若干煽り気味のと

今回は、エンジニア向け読み物サービス「Mybridge」のMybridge AIがランク付けした2016年9月のReactに関する記事の1位だった記事を翻訳して紹介します。Reduxの作者Dan Abramov氏の記事です。内容は、簡単に言うと、「無理してReduxを使わなくてもいいよ」という話です。ただ、使わなくてもいい理由をReduxの特徴を挙げながら述べてくれているので、Reduxについての理解も深まる内容になっています。原文がだいぶフランクな感じで書かれているので、日本語に訳すのが少々難しく、わかりにくい部分もあるかと思いますが、是非読んでみてください。 当記事は、You Might Not Need Redux – Medium　(Sep 20, 2016) by Dan Abramovを日本語に翻訳したものです。 人々はReduxを必要とする前からReduxを使おうとします。「

Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の

JavaScript界隈で最近注目のライブラリ、jQuery[1]⁠。今回のゲストはその作者にして、Mozilla CorporationでJavaScript Evangelistを務めるJohn Resigさん。日本の「JavaScript先進国」ぶりにはかなりのインパクトを受けたようです。 （左）小飼弾氏、（⁠右）John Resig氏（撮影：武田康宏） 米国にはない 弾：JavaScriptに関わったきっかけは？ Resig：大学ではPerlを使っていて、Mozillaの前にいたスタートアップ企業に入ってから使うようになりました。以来、JavaScript一筋です。 弾：JavaScriptコミュニティのShibuya.jsで講演されましたが、日本のJavaScriptersはどうでした？ Resig：非常に楽しかったです。そもそも、JavaScriptのコミュニティが日本に存在し

Before we get into this, allow me to introduce myself — you’re probably going to wonder who I think I am before this is over. I’m Eric Elliott, author of “Programming JavaScript Applications” (O’Reilly) and creator of the “Learn JavaScript with Eric Elliott” series of online JavaScript courses. I have contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ES

1年前の記事 JavaScript フレームワークがデータバインディングを実現する４通りの手法 では、Object.observe() について次のように説明した。 JavaScript オブジェクトが変更されたときにコールバックを呼んでくれる API データバインディングの実装が簡単になる Google Chrome には実装済み ECMAScript 7 に提案中 提案が通れば MV* フレームワークの実装がシンプルになってハッピー 将来を期待されていた Object.observe() であったが、2015 年 11 月頭、ES Discuss メーリングリストへの An update on Object.observe という投稿で、ECMAScript からの提案が取り下げられて、V8 エンジンからも年内に削除される予定であることが表明された。 Object.observe()

Published 04/11/16 by sean Follow @sfioritto Grunt/Gulp npm, require.js, browserify, es6, compilers, transpilers, jasmine mocha chai, react/angular/ember, closures, prototypes. *head explodes* Web development is fun! Javascript is ... daunting. Everything else in web development clicks for you, but when you dig into Javascript it's like you're missing some big, foundational piece of knowledge that

prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5

はじめに Herokuのブロク記事10 Habits of a Happy Node Hacker (2016)を、「洋の東西を問わず、みんな『10のなんとか』って好きなんだな」と思いながら眺めていたら、結構面白かったので内容をピックアップしてみます。 以前、Go言語で幸せになれる10のテクニックというのをあるブログ記事を元にして書いた時には、原題の "Ten Useful Techniques in Go"を意訳して「幸せになれる」としたのだが、今回は原題にシッカリ"Happy"が入っているというおまけ付き。 なお、「2016年版」と言っているのは2013(2014？)年版があるから。これらを読み比べてみるのもまた面白いが、とりあえず今回は最新の2016年版のご紹介。 1. 新しいプロジェクトは npm init で始めろ 新しいプロジェクトはこう始めようよ、と言っている。

JavaScriptのコミュニティがツールやフレームワークを統合する頻度は、ニコラス・ケイジがいい映画を作るのと同じくらいの頻度です。何が言いたいのかというと、 あることはある のですが、あったとしたら注目を集めるぐらい稀だということです。 だから私は、AngularのチームがAngular 2の開発に使用する言語を自社の AtScript から TypeScript に 切り換えるという決断をした のは非常に興味深いことだと思いました。これまでも、AngularのチームはTypeScriptのチームと共に開発を行ってきてはいますが、直接TypeScriptを使用するという決断は、TypeScriptのプロジェクトを強く支持しているということに他なりません。 また、TypeScriptを活用しているプロジェクトはAngularだけではありません。全くの偶然ですが、私たちTelerikはAn

JavaScript とλ式の関係について書こうと思ったのですが、その前にクロージャについてお話しする必要があることに気付きました。 僕が最初にクロージャという言葉を知ったのは、大学の学部生のときです。Lisp の勉強をしていて出てきたのです。でも、まったく理解できませんでした。 これまで僕が主に使ってきた言語は、C や Emacs Lisp です。C では関数の中に関数を定義できないのでクロージャはありませんし、Emacs では動的スコープでクロージャはありませんから、クロージャに関する知識がなくても困りませんでした。それが、クロージャを本気で理解しなかった理由だと思います。 ここでは、JavaScript にとってクロージャが必要である例を示すことにしましょう。必要性が実感できれば、詳しく勉強しようという意欲が湧くはずだからです。 関数に static な変数 C言語には、関数に st

社内向け資料。自分が書いたコードを説明するために資料作る羽目になった。 昔のことはうろ覚えで雰囲気で書いてる部分もあるので、そこらへん勘弁。 古の時代(~2010) 前提としてJavaScriptは名前空間がwindowの一つしかない。 昔Prototype.jsがあった。もうみんな忘れたけどあの時期はプリミティブなオブジェクトのprototypeを生やしまくって、それが衝突しまくってprototype良くない的な雰囲気が生まれたり生まれなかったりした。 その反省があってか(歴史的に若干微妙な気がするが) jQueryは名前空間を一つに集約した。いわゆる jQueryPlugin は、jQueryのプロトタイプにヘルパを生やしまくっていた。グローバルを汚すのは駄目だけどjQueryの名前空間を汚すのはいいよね、ぐらいの考え。 jQuery非依存なライブラリは、「GoodParts」として、

ついぞ最近node.jsなんてのがでて、繁華街のあちこちでチヤホヤされてる。そんなときに、モヒカン族Erlang村(erlang-questions)に「node.jsってどうなの？」的燃料が投下されたわけですよ。これは炎上しそうだ…と追いかけてたら、ネタどころか案外真面目なハナシばっかりだったのですが。まずは真面目に問いかけをする純朴な成年（想像）。 「Erlang好きだし使ってるんだけど、Erlangとnode.jsてそれぞれどういうジャンルがすごいの？RabbitMQとかejabberdみたいなのつくろうとしたらどうなるの？簡単なチャットサーバーつくるくらうならnode.jsのが断然簡単だよね？分散システムで使うなら断然違うとか？ Ulf Wigerによると、ブロックする関数の問題を簡単に解決してくれるとか書いてあるみたいだけど (link)」 おっお。素直な質問。これはみんな釣られ

The Art of UNIX Programming 作者: Eric S.Raymond,長尾高弘出版社/メーカー: アスキー発売日: 2007/06/19メディア: 大型本購入: 4人 クリック: 91回この商品を含むブログ (62件) を見る TL;DR Unix Philosophyにおいては、「一つのことをうまくやり、協調する仕組みを持つ」という事が大事 Node.jsのモジュールにおいても同じで、「一つのことをうまくやる、Stream APIで協調する」と良い 「一つのことをうまくやる」にはどうするのが良いのか、ということで substack のモジュール実装例 Simple と Easyの違い ちょっと今回長くて文字が多いので、最初と最後にまとめを用意しました。時間がない方はこれを読むだけでもいいかと。 Unix Philosophy さてさて、Unix Philosoph

JavaScriptを中心としたWebアプリ開発の栄枯盛衰まとめ――LiveScriptからAngularJS／React.jsまで：15周年記念特別企画 ＠ITが誕生した2000年頃はJavaScriptが不遇だった時代。そこから現在のような人気のプログラミング言語になるまでには、どのような歴史があったのか。15周年を迎えた＠ITの豊富なWeb開発関連記事とともに振り返る。 2015年6月17日に、JavaScriptの最新標準仕様となる、ECMAScript 6（ES6、ECMAScript 2015）が正式に承認されました（参考）。1997年にECMAScriptのバージョン1がリリースされてから6度目のアップデートとなり、これまでの中で一番大きな変更が加えられたことになります。 本稿では、ECMAScript 6が正式に承認されたということもあり、2000年頃の第一次ブラウザー戦争

(注記：7/15、いただいた翻訳フィードバックを元に記事を修正いたしました。) 子供の頃、私の興味は互いに関係性のない様々な分野に及んでいました。数学も歴史も大好きでした。 ルネッサンスマン 、つまり 博学者 と言う、複数の分野に秀でた人になりたいと思っていました。これはとても難しい課題で、私は突如として、器用貧乏な人になってしまう危機に直面したのです。 私は特定の分野に特化しなくては、と考え始めました。そうすればたとえルネッサンスマンにはなれなくても、少なくとも、器用貧乏にならなくても済むと思ったのです。どうしたらソフトウェア開発をするのに必要な広い知識を保ちながら、1つの分野で専門性を高めることができるのでしょうか。 この記事では、過去5年間、私が良いJavaScript開発者になるために使ったテクニックとリソースの概要をお伝えしようと思います。 最近の多くのWeb開発者は、ある共通の

(注記：4/10、いただいた翻訳フィードバックを元に記事を修正いたしました。) ほとんどのプログラミング言語は、評判のよい安定した、ごく少数のアプリケーションフレームワークをサポートしています。Objective-CやSwiftのアプリケーションではAppleの優れたフレームワーク、Cocoaを使用しています。Rubyのアプリケーションは、大抵Railsを使います。Javaには確立されたWebアプリのフレームワークが少数あって、それらは比較的ゆっくりと移り変わっています。 一方でJavaScriptのフレームワークは、およそ16分ごとに、最新で最良のものが誕生しています。 研究によると、（より新しくより優れたフレームワークが発明されない限り）作るのが最も複雑なJavaScriptのアプリはToDoリストだそうです。幸い、ToDoのサンプルプロジェクト経由でJavaScriptのフレームワー

バックエンドエンジニアとフロントエンドエンジニアの違いは、前者は1つの環境で仕事をするのに対し、後者は予期せぬことが起こる可能性のある数多くの環境で仕事をするということにあります。 「複雑なJavaScriptで動くWebサイトやWebアプリが動作する環境は、単一的で一枚岩のものである」――この無意識な思い込みこそが、バックエンド中心に開発されたWebベースプロジェクトにおいてフロントエンドエンジニアが目にする問題の根本的な要因であると私は考えています。 さらに悪いことに、バックエンドエンジニアは、フロントエンドエンジニアよりも複雑なアプリケーションを構築するのに長けていると考えています。実際そうなのかもしれないのですが、好ましくないのは、彼らの中にはフロントエンドについて学ぼうという意識に欠けている人がいることです。 アプリケーションの構築において、数多くの困難な環境に対応するフロントエ