【node.js】サーバサイドjavascript 3【io.js】©5ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2014/12/27(土) 18:40:07.70

pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。
サーバサイドjavascriptについて語りましょう。

node.js - googleが開発したV8エンジン上で実行できる処理系
http://nodejs.org/
io.js - node.js 互換で Joyent の影響からの脱却を目指す処理系
http://iojs.org/
Rhino - JVM上で実行できる処理系
https://developer.mozilla.org/ja/Rhino

io.js の経緯
http://stackoverflow.com/questions/27309412/what-is-the-difference-between-node-js-and-io-js
javascriptはrubyと比較してもかなり速い
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&;lang=v8&lang2=yarv
基礎から学ぶNode.js
http://gihyo.jp/dev/serial/01/nodejs
node.jsの概要とアプリケーション開発の準備
http://gihyo.jp/dev/serial/01/realtimeweb/0002

前スレ
【node.js】サーバサイドjavascript 2【Rhino】
http://peace.2ch.net/test/read.cgi/tech/1358937029/
【node.js】サーバサイドjavascript【Rhino】
http://toro.2ch.net/test/read.cgi/tech/1310087535/

**デフォルトの名無しさん** · 2014/12/27(土) 18:40:56.41

あけおめことよろ

**デフォルトの名無しさん** · 2014/12/27(土) 18:42:30.42

yesde.js

**デフォルトの名無しさん** · 2014/12/27(土) 22:58:41.76

node.jsって流行るの？

**デフォルトの名無しさん** · 2014/12/27(土) 23:02:11.92

流行ってる
流行ってた

**デフォルトの名無しさん** · 2014/12/31(水) 18:23:54.12

gulp 4 って使えるの？

**デフォルトの名無しさん** · 2014/12/31(水) 19:45:43.48

node-webkitやatom-shellはスレチ？
OKなら、今どっち採用するか凄く迷ってるんですけど

**デフォルトの名無しさん** · 2015/01/01(木) 16:37:51.69

「node.js覚えればクライアントもサーバもjavascriptだから他の言語覚えなくてすむぜ！」
と安易に寄ってきたにわかがイベントドリブン周りが頭に入らなくてすごすご退散するケースが多そう

**デフォルトの名無しさん** · 2015/01/02(金) 00:11:15.27

>>8
俺はそれに近い

**デフォルトの名無しさん** · 2015/01/02(金) 00:20:31.87

とりあえずPromiseを理解しないと非同期のメリットを生かせないだろうな

**デフォルトの名無しさん** · 2015/01/02(金) 00:22:52.63

>>8
自己紹介乙

**デフォルトの名無しさん** · 2015/01/02(金) 00:54:28.10

Promise って非同期処理のコールバックを比較的キレイに書ける、
って以外のメリットって何かあるの？

**デフォルトの名無しさん** · 2015/01/02(金) 14:54:02.14

>>12
綺麗っていうのが曖昧な表現だがおおむね以下のメリットがある
・コールバック関数から更にコールバックを呼ぶ時にネストが深くなるのを防げる
　(ソースが三角形になるのを防げる)
・A,B,Cの内ABが終わっててかつCが終了した直後に処理を開始するとかの制御が簡単になる
　(つうか自前でやろうとするとかなり面倒な事になる)
・エラー処理を一纏めにしたりなんかの制御が簡単になる

これを綺麗に書けるの一言でくくってしまったら他のメリットは無い

**デフォルトの名無しさん** · 2015/01/02(金) 16:32:56.94

>>13
レスさんくす。

>>8 に対しては、むしろコールバック関数を使ったやり方のほうが
node.jsの動作を理解できていいんじゃないかと思ったのでね。

**デフォルトの名無しさん** · 2015/01/03(土) 11:31:09.56

>ソースが三角形

漏れはチベット国旗みたいになる

**デフォルトの名無しさん** · 2015/01/03(土) 22:51:09.22

Promiseなんて実際綺麗に書きやすいライブラリの一つってだけだから
「Promiseを理解しないと非同期のメリットを生かせない」ってのは
表層しか理解してないって証だわな
Promiseと非同期をjQueryとDOMにでも置き換えて考えてみるといい

**デフォルトの名無しさん** · 2015/01/03(土) 23:38:28.29

>>16
実際生かせないだろ
> ・A,B,Cの内ABが終わっててかつCが終了した直後に処理を開始するとかの制御が簡単になる
非同期処理をやってると↑こういう事がしょっちゅうあるけど、どうやって自前でやんの？
単にフラグだらけの糞みたいなソースが出来るだけだ

**デフォルトの名無しさん** · 2015/01/04(日) 00:06:14.65

その程度は自前でも並列と逐次の小さなヘルパ関数を用意するだけで十分きれいに書けるだろ
実際はそんなもん自前で書かずにasync使ってたけどな
ECMA標準だから仕事じゃPromise使ってくけどそんなのは所詮表層の話に過ぎないよ
PromiseよりStreamが適することも多いし

**デフォルトの名無しさん** · 2015/01/04(日) 00:10:50.21

>>18
どうせマルチスレッドvs非同期処理の事いってんだろ
そんな事言ってんじゃねーんだよ
スレの流れも読まずに何一人でブチ切れてんだよアホか

**デフォルトの名無しさん** · 2015/01/04(日) 00:18:39.72

>>18
一方俺は、asyncもどきを自前で作った。（趣味でだけど）

非同期処理の中でさらに非同期処理をして、それぞれの終了時に指定された関数を呼び出す
可能性があるようなプログラムだったんで、途中頭がこんがらがったけど何とかできたわ。

**デフォルトの名無しさん** · 2015/01/04(日) 00:26:18.12

>>20
一応だけど、ブラウザ内蔵のPromiseはJavaScriptで実装出来ない事をしてるから
Promise使った方がいいとは思うよ
・渡されたコールバックを確実に非同期で実行する
・飲み込まれた例外をデバッグ出来る
ってのがそう

**デフォルトの名無しさん** · 2015/01/04(日) 00:35:28.28

>>19
どこを誤読するとそうなるんだよwww
並列ってのはPromise.all()やasyncのparallel()のような処理フローのこと
逐次ってのはPromiseのthen()によるチェーンやasyncのseries()・waterfall()のような処理フローのこと
俺の方はスレの流れを読めてると思うぞ

20 · 2015/01/04(日) 00:38:56.49

>>21
ブラウザのJavascriptもシングルスレッドじゃなかったっけ？
であれば、
・渡されたコールバックを確実に非同期で実行する
・飲み込まれた例外をデバッグ出来る
はPromise使わなくてもできるよ。使った方が楽だろうけど。

**デフォルトの名無しさん** · 2015/01/04(日) 00:53:04.50

>>23
> ・渡されたコールバックを確実に非同期で実行する
これはsetTimeout使ったハックがあってほぼ確実なのは可能だけど、
絶対確実な実装はブラウザが内部で実装しないと無理なんだよね

> ・飲み込まれた例外をデバッグ出来る
そりゃ、ライブラリ内部のcatch内にブレークポイントを張って待ちかまえていれば
可能だが毎回そんな事すんのか？いやするわけない
そして例外がスルーされて何も起きない

**デフォルトの名無しさん** · 2015/01/04(日) 00:54:44.21

>>21
サーバサイドJSスレで「ブラウザ内蔵のPromise」ってw
そこはv8のPromise実装って書けよ

>>22
QとかBlurbirdはそれらをJSで実装してるわけだからな
どうしてJSで実装できないと思い込んだのか謎だ

**デフォルトの名無しさん** · 2015/01/04(日) 00:56:26.84

安価ミス、>>25の後半は>>23へのレス
あとBlurbirdじゃなくてBluebird

**デフォルトの名無しさん** · 2015/01/04(日) 01:03:40.55

>>25
ブラウザ内蔵って…ごめんちゃい

QとかBlurbirdはほぼ確実な実装でお茶を濁してる (実用上問題ないけど)
例外の件は>>24の通りだ

**デフォルトの名無しさん** · 2015/01/04(日) 01:21:16.51

>>27
「お茶を濁してる」について詳しく
nodeではprocess.nextTick()かsetImmediate()で確実に非同期にできるが？
v8のPromiseだってマイクロタスクキューに入れられて結局はnodeのイベントループで処理されるのは同じ

例外のデバッグって具体的には？
Promise.catch()にブレークポイント付けれるって話？(それはブラウザ関係ないと思うが…？)
もしそうならライブラリがcatchした例外はコールバックの第1引数に渡されるのがnodeの流儀で同じようにできるが？

**デフォルトの名無しさん** · 2015/01/04(日) 01:41:12.11

で、>>19は>>18を誤読してたってことでいいのか？ >>22を読んだ上での反論は？

**デフォルトの名無しさん** · 2015/01/04(日) 01:57:43.71

>>28
> nodeではprocess.nextTick()かsetImmediate()で確実に非同期にできるが？
Qとかはnode用やIE用じゃないが、場合分けしてる可能性はある
> v8のPromiseだってマイクロタスクキューに入れられて結局はnodeのイベントループで処理されるのは同じ
それがJavaScriptで実装出来ない事をしてることじゃなくて？

> 例外のデバッグって具体的には？
説明が面倒になってきた…
Promiseに限った話しじゃないが、ライブラリ内でtry,catchしちゃってると
呼び出し側に例外が来ないって事だ (当たり前の事だけど)
で、Promiseの場合は呼び出し側がエラー処理もしてない場合でも、
デバッガが気を効かせて例外を上げてくれるってだけだ

ま、薄々感づいてると思うが、俺はずっとブラウザ実装の事を言っていた…
しかしPromiseが満たすべき一般的な動作仕様を言ってるつもりではある

**デフォルトの名無しさん** · 2015/01/04(日) 02:35:21.46

>>30
> それがJavaScriptで実装出来ない事をしてることじゃなくて？

nodeではv8のマイクロタスクキューもsetImmediate()もnodeのイベントループで処理されるのは同じって意味な
つまりJSのsetImmediate()でコールバックを確実に非同期にできるってこと
これはブラウザでも同じはずだ
違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ

> 呼び出し側に例外が来ないって事だ (当たり前の事だけど)

ライブラリの実装依存ではあるが、nodeでは当たり前じゃない
nodeでは例外を第1引数としてコールバックすることで呼び出し側に例外を伝えるのが流儀だ
だからPromiseでnodeのAPIやライブラリをラップしてもPromise.catch()に例外が渡る
(ラッパーはコールバックの第1引数に例外が渡されたらPromise.reject()を呼び出す)

>>21を見てから薄々じゃなく確信していた

**デフォルトの名無しさん** · 2015/01/04(日) 02:54:15.95

>>31
> 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ
setImmediate()がコールバックを確実に非同期に出来るっていう仕様ではないだろ
確実に非同期って意味は
setImmediate(function callback() {
});
a += 1;みたいななんらかの処理 ←これが実行される前にcallbackが絶対実行されない
ことを保証してんの？
そもそも非標準のAPIなんだけど…

> ライブラリの実装依存ではあるが、nodeでは当たり前じゃない
QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか…
Promiseの実装を熱弁してるけど、とりあえずそういう事でいいよ

**デフォルトの名無しさん** · 2015/01/04(日) 03:42:19.87

>>32
> これが実行される前にcallbackが絶対実行されない
ことを保証してんの？

仕様はそうなってる
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html

> そもそも非標準のAPIなんだけど…

そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ
https://github.com/promises-aplus/promises-spec

> QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか…

>>23（これは俺とは別人）からは「それPromise使わなくてもできるよ」って話をしてるな
それは当然JSで書かれたQやBluebirdでもできるってことだから元の話と違ってるわけではない、スコープが広がっただけ
で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？

**デフォルトの名無しさん** · 2015/01/04(日) 04:38:34.06

>>33
> 仕様はそうなってる
Schedules to run handler immediately after user agent events have been flushed.
user agent eventsってなんだ？
a += 1;の実行が終わってからとは言ってないと思うが

> そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ
置き換えて何だよ？
platform code(要するにJavaScriptでないコード)を実行しろとわざわざ書いてる
> 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ
元の質問は↑これ、お前は論点をずらそうとしてるだけだな

> で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？
お前眠いのかw
俺はもうもちそうもないが
>>30の下の方で言ってるよ

**デフォルトの名無しさん** · 2015/01/04(日) 14:15:40.27

https://twitter.com/msdev/status/551558635198099457/photo/1
もし1995年にnode.jsがあったら

**デフォルトの名無しさん** · 2015/01/04(日) 14:59:18.44

入れ替えんのがとてつもないボトルネックやな

**デフォルトの名無しさん** · 2015/01/04(日) 16:12:14.10

こんな難しい議論理解できないと
綺麗なコード書けない時点で人気出ないだろうね

**デフォルトの名無しさん** · 2015/01/04(日) 16:24:29.87

そんな難しい話かぁ？

**デフォルトの名無しさん** · 2015/01/04(日) 16:39:24.09

>>35
そいつがアホなだけ

**デフォルトの名無しさん** · 2015/01/04(日) 16:44:05.85

>>39
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ

**デフォルトの名無しさん** · 2015/01/04(日) 16:57:31.37

その頃にはもうMPC規格が普及して
CD-ROMドライブが標準でついてるというのに(TOWNSユーザー並の感想

**デフォルトの名無しさん** · 2015/01/04(日) 17:40:22.84

>>37-38
技術的に難しい話はしてないが、こういう場で会話を成立させるのは難しいなw
できれば誰か ID:kuXg+7pG の主張を翻訳して欲しい

**デフォルトの名無しさん** · 2015/01/04(日) 18:06:08.86

>>34
> a += 1;の実行が終わってからとは言ってないと思うが

"5 Processing Model"の4に、5以降は非同期に実行すると書いてある

> 置き換えて何だよ？

お前が使ってるブラウザに合わせて読み替えろというだけだ
サーバサイドJSスレとしてはnodeで使えるprocess.nextTick()やsetImmediate()で何の問題もない

> platform code(要するにJavaScriptでないコード)を実行しろとわざわざ書いてる

"paltform code"はプラットフォームごとに異なるコードという意味で
それがJSで実装されてようがされてまいがどうでもいい
実のところnodeのsetImmediate()はJSで実装されている

https://github.com/joyent/node/blob/v0.10/lib/timers.js#L361

> > 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ
> 元の質問は↑これ、お前は論点をずらそうとしてるだけだな

いみふ
「ブラウザが内部で実装しないと無理」の対象はPromiseそのものの実装だ
Promiseの実装が呼び出すAPIの話じゃない
「stringはブラウザで実装されている」を理由に「stringを使うのはブラウザが内部で実装しないと無理」っておかしいだろ？
"platform code"がブラウザやnodeで実装されていても、それを使うコードはJSで書ける
たとえばQはこの辺で"platform code"を呼び分けてる (モダンブラウザだとpostMessage()が使われてるな)

https://github.com/kriskowal/q/blob/v1/q.js#L160

これは「ブラウザが内部で実装しないと無理」ではなく普通のJSのコードだ

**デフォルトの名無しさん** · 2015/01/04(日) 18:08:08.79

>>34
> >>30の下の方で言ってるよ

話がループしてるな… その>>30の以下について

> Promiseに限った話しじゃないが、ライブラリ内でtry,catchしちゃってると
> 呼び出し側に例外が来ないって事だ (当たり前の事だけど)

これはPromiseを実装するQのようなライブラリ側の話だよな？
ライブラリ側がcatchした例外を飲み込んで捨てた場合は確かにそうだが、
QやBluebirdは飲み込まずにPromise.catch()に通知するだろ
Promiseを使わない場合でもnodeの流儀ならコールバックの第1引数で通知する
だからこれは「ブラウザ内蔵のPromiseはJavaScriptで実装出来ない事をしてる」に該当しない
っていうのが>>31で書いたことだ
それに対して>>32で

> QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか…

と返されたわけだが、前述の通り飲み込まずにPromise.catch()で通知されるはずだから
そうじゃないっていうなら

> で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？

と>>33で尋ねたわけだ
その返事が>>34の「>>30の下の方で言ってるよ」だと完全にループ
まずは確認だが、

・QとかBluebirdでは例外が飲まれる

って主張してるんだよな？
それならどういうケースでそうなるのか例を示してくれ
Promise.catch()に伝わらないケースがもしあるなら、おそらくそれはただのバグだ