  |
はてなキーワード: DOMとは
ReactはJavaScript界隈の関数型プログラミング化の潮流で登場。
最近、炎上している別の方面で、特にFRPと組み合わせると圧倒的なパワーを発揮すると一部では実例とともに指摘されている。
http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html
Reactは、関数型あるいは宣言型に書けるように用意されている。DOMは、「仮想DOM」として、JS（JSX）上の「値」として統合されていて、それは自由に変形し、組み合わされ、リアクティブにJSX上の仮想DOMから実DOMにリアルタイムでマッピングされ描写される。
JQueryも、実DOMを関数型で操作できるような拡張ではあるが、Reactのように宣言的に書くことは不可能。
coffee scriptは、ES6登場までの過渡期の橋渡しみたいなもので、登場したのも消えたのも合理性がある。
React.jsは、関数型の潮流で登場したものでこれも合理性があり、この延長線上でさらに洗練された代替物が登場する可能性はあれど、このパラダイムが消えることはない。
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか？
https://www.npmjs.com/package/timeengine
IOモナドをDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからはFRPの効力がまざまざと見せつけられている。
荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?
あるよ。
関数がどのパラメータに依存して、何を結果として返すのか明確になる。
グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。
短いプログラムならそれでもいいけどね。
別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数で関数に渡すのか？
グローバルな値を参照したり書き換えたりして
いやだから、定数なんだから書き換わらないんだよ、FRPのストリームはconst 定数なんだから。
オブジェクト指向と対比して考え方をまず学ぶって、岡部路線、住井グループはそれを目の敵にしていて集団的に攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。
いくら仕様がアップデートされたって、生JSでDOM弄るのjQueryで弄るより辛いでしょ?
機械語を人間にわかりやす書くためにアセンブラがあるのと、生JSでDOM弄るの"人間にわかりやすくするためにjQueryがあるのって、似てない?
個人的な考えは以下の通り。
そもそもコンポーネント指向のライブラリだから、チュートリアルからして構造化を基本において書かれてるのが入門用にこそ適していると思う。
だって、初心者の頃jQueryで場当たり的にコード追加していって九龍城みたいになったこと、あるでしょ？
もちろん自分で間違いを犯してその痛みを知るってのも方法論としてはありかもしれんけど、
DOM操作を抽象化したライブラリから入って、徐々に具体的なところに落とし込んでいくのが効率的じゃない?
ライブラリ自体が構造化を念頭に置いてるから、自然とパーツごとに作るようになって、
その次の段階として自分の作ったパーツの再利用を考えられると思う。
jQueryってホントに何でも出来るからキチンと扱える技術を既に持ってる人には良いだろうけど
しかもその振れ幅が広くて、どの方法論もそれなりに意味がある場合が多い。
正解が沢山ある問題をいきなり解かせるんじゃなくて、
まずは答えがある程度決まってる問題から入って、徐々に馴らしていくべき。
ある程度経験を積んだプログラマーこそが手を出すべきと言うか。
どんなに抽象化が高度になっても、裏でやってるのはDOMの直接操作なんだから。
でも、大事な基礎技術だからといって、それだけで済ませて技術の革新を放棄するべきではないでしょ
むしろ、抽象化の高いところから入門して、基礎技術に触れる必要が出来てから触った方が理解が早いと思う。
と、私は考えます。
http://anond.hatelabo.jp/20160522003506
ども。
この辺りの一連の発言（特に後二者）を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAやWeb APIといったフロントエンドの世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます。
ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊な世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データの配信とDB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリのレベルに追いつき、同じやり方ができるようになった、というだけの話です。
とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。
具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドとリアルタイム集計が登場する勤務予定表的なものを、1人でjQueryのSPAで作った際、数百行のHTMLと数千行のJSがスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代のベスト」として自信を持って残せます。JSXの局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません（私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います）。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。
「変な独自拡張を入れてまでJSを使い続ける理由がわからん」についても、まるでJSが生来の嫌われ者で、クライアント側でもPythonやRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね？ たぶんES6は人々から積極的に愛されています。現状、クライアント側にPythonが進出するのではなく、逆にデスクトップやモバイルやサーバ側にどんどんJavaScriptが進出する流れが起きています。
速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね（mustache使うよりは速いよね）ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXはシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通のJS技術者が普通に触れる程度の成熟はしています（枯れたとまでは言いませんが）。
coffeescriptは廃れたから使われなくなったんじゃなくて、言語仕様に吸収されて役目を終えたんじゃないの？
欲しい機能を先行実装して、それが仕様に吸収されて基本仕様で需要が満たされた役目を終えるってむしろ素晴らしいことじゃん。
てか、jQueryを使って出た不満を解決するために出てきたのがReactであって、同じ不満を抱えてた人が多いから今の状況があるんでしょ。
「jQueryだけでいい、Reactなど不用」ってのも「React最高！jQuery滅ぶべし」ってのも、どっちも共感できない。
一番わからないのは「Web界隈は流行り廃りが激しすぎて糞」とかいう意味不明なDis。
jQueryで得たDOM操作はReact触るときにも役に立つし、Web Componentsは仕様に組み込まれる方向で動いてるんだから、
Reactが廃れるとしたら、それはcoffeescriptと同様にその役目を終えただけで、廃れたから使われなくなるわけじゃないと思うんだが。
全く別の技術が林立してるんならその批判もわかるけど、既存の技術の問題点を解決する技術の確立を否定したら進歩なんか無くなっちまうよ。
利便性が上がって手間が減るスピードが速い事のどこが悪い事なの？マジで意味わかんねぇ。
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
ユーザー体験がどうかはまあ意見が別れるでしょうからおいておくとして、ずっと楽に開発というのがよくわからないです。普通になんでもいいですけど、ウェブ側のフレームワークでちゃんとしたものを使っていれば別になんでもないことだと思うんですが、具体的にどういう状況を考えられていますか？
プログラムはユーザーサイドだけでは完結しなくて、入力チェックとかいろいろは絶対にやらないといけないですよね。ということで同じロジックを複数書く場面が出てくることが多いと思います。そういう手間も含めたうえで開発が楽になるというのはちょっとよくわからないです。
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？
ちょっとここ書き方分かりづらかったかもですが、「ES6で書く以上はES6を使えばいいじゃん」「変な独自拡張を入れてまでJSを使い続ける理由がわからん」という２つの疑問を同時に書いたつもりです。
将来長持ちする気がしています。
PHPやJSP,ASPが通ってきた道に見えてなりません（まあASPはまだ現役ですか。）。
正直その他のアプリケーション(サーバーサイドや、例えばAndroid/iOS開発)でこのような書き方はまずしないので、なぜわざわざ同一ファイルに書きたがるのかがわかりません。（ロードのコストを嫌がっているとかですかね？）
テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
ええと、テンプレートストリングではなくて、mustacheみたいに十分枯れているテンプレートエンジンでもいいですが、必要かどうかは別として確かに機能の豊富さはどうかはちょっとわかりません。
速度に関しては、実際みんな早いと言っていますがこの手の速度神話はJSにかぎらず昔からちゃんと前提と状況を考えなくてはいけなくて、（例えばJavaは重い！とか関数呼び出しはオーバーヘッド！とか仮想関数は使うな！とか）例えばさっとぐぐるとこんなものが出てきました。
http://www.stefankrause.net/wp/?p=283
まあよくわかりませんが、結局あんまいじらないのが一番良いという当たり障りない結論になってしまいませんか？（あと原理的に生のDOMを操作するのよりも早くなりようがない気がするんですがどうなんですかね？？）
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
ごめんなさい、Reactまわりのエコシステム全体も含めた時を意味したかったです。leftpad騒動とかもあったように、なんかまだちょっと不安がある感じがします。偏見でしょうかね。。
React.js界隈の人に聞きたい
http://anond.hatelabo.jp/20160521163144
最近某所で、React使うとjQueryは不要だ的なタイトルの記事を書いちゃた気がするので一応反応しときます。長文ごめんね。
えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQueryは不要」「jQueryは要らないこともある」と長く書いた方が正確です（本文ではちゃんとReactが万能ではない説明をしてる）。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。
そもそも世の中にそんなにSPAがあるのか
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAだから使いづらい」という主張はよく分かりません。GitHubやTwitterサイトがSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは（Reactではないけど）SPAで、ブラウザでMarkdownをレンダリングしています（ http://webpack.github.io/docs/ )。サーバサイドで動くスクリプトもタスクもゼロ。個人的にはこういう使い方で十分嬉しいです。
何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります。自分中の閾値としてはJSコードが数百行超えるならもうReact使う。
JSXを使うことに抵抗ないんですか？
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？ 正直その主張を聞いたのは初めてです。歴史的にJSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。
「JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装が一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしています。JSXは「関数呼び出しのシンタックスシュガーをJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います。仮想DOMの思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています。
とはいえ所詮JSXはシンタックスシュガーなので、使いたくないなら使わず、本来の関数スタイルで仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。
それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
Reactはもう登場して3年経過して未だに勢いが増していますし、日常で困らないレベルのコンポーネント集も揃っています。React-Bootstrapはいいぞ、心が豊かになる。そろそろ採用してもアーリーアダプターとも言えんでしょう。むしろ真に先端を見るのが好きな人に言わせりゃ、2015年なんて「Reactが淡々と成熟していくのを見ているだけの、つまらない年だった」みたいな感じらしいですし。
Reactは現時点で既に3年に1回レベルのビッグウェーブであることは疑いようがなく、「これが10年に1回、つまりjQuery以来のビッグウェーブなのかどうか」については、そう信じている人と懐疑的な人がいる、という状況です。私はAngularもCoffeeScriptも「3年に1回」レベルに感じたのでスルーしましたが、Reactには「10年に1回」の方になりうる素質を感じています（個人の感想です）。将来もっと凄いものが出るとしたって、それは「ベターjQuery」ではなくて「ベターReact」でしょう。通常は「3年に1回」レベルでも試したり仕事に使ったりして構わないと思いますが、10年に1回の技術でなければ使わない主義の方は、あと2～3年待てばよいと思います。
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
元増田です。
SPAは、クライアントが自立した1プログラムとして状態を管理する。サーバはUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバとサーバサイドページ生成のスタイルを、サーバとブラウザでやるようにシフトさせたものともみなせるだろう。
手間がかかりません？さらにもともとほぼサーバー側だけで済んでいたものを分けることでCSRFやSQLiなどの変なバグを仕込む可能性だってありますよね。これに見合うメリットが見えないのですがいかがでしょうか。
そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXはサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。
というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。シンタックスハイライトとかインデントも効かないじゃないですか。そういう点ではAngularJSが一番気持ちいいですが。。
まあそれはそれとして、なるほど、JSXは別にどうでもいい、というのはわかりました。まぁそれならわからんでもないです。
すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーなものとしては残り続けるだろうが。
ここわかんないですね。活発なメンテがそんなに重要なのかな？ということです。まあモダンな感じで書きたいということは理解できますが、それさえクリアされていればいいんじゃないでしょうか。そうでもないですか？
http://anond.hatelabo.jp/20160521163144
内容から誰が書いてるかわかるかもしれんけど、まぁスルーよろしく。
jQueryもそんなにガッツリ使ってるわけでもないし、Reactはまだリリース前の調査兼下地作りの段階だけど
正直言ってjQueryに戻るつもりは毛頭ないぐらいReact便利だと思ってる。
でもjQueryを捨て去れるかというとそれも無理だと思ってる。
その辺のことを適当に書いてみる。
社内サポート的なことやってて、サポートのテンプレート対応を省力化するために
Webでツール作って人が対応するコストを減らすために使ってる。
jQueryで一つツール作ってリリースしてそこそこ人的コスト削れたのはよかったと思ってる。
最大にして一番の理由がこれ。
そんなに大規模なアプリケーション作ってるわけでもないし、関係者も俺一人だけど正直DOMツリーを脳内でくみ上げるのに疲れた。
500行もいかないようなショボいコードでも脳内DOMツリーと格闘するのしんどい。
DOMツリー触るほうが楽ってみんなどの程度のコードでそんなこと言ってんの？
そんなスーパーハカー揃いなの？信じられないんだけど。
オリジナルのbootstrapはどうしても頭に入ってこなかったし、手を付ける気にもならなかったけど
React-Bootstrapはマジで楽だし、スッと理解できる。マジ最高。
Bootstrapってこっちを本筋にすべきじゃね？と割とマジで思ってる。
まだ触って3日も経ってないけど。
これはちゃんとしたWeb界隈の人は利点と思わないのかもしれないけど
一人でいろいろ賄わざるを得ない俺みたいな人間にとってはマジで楽。
ベースのHTMLにはベースのdiv一個載せとくだけで後は全部js。
レイアウトを大元のコンポーネントでReact-Bootstrapで組んで、あとは各コンポーネントを
個別に作っていけばいい。
HTML見て、CSS見て、JS見て、っていちいち記述方式の違うコードを見る必要がないのは
少なくとも俺にとっては一番楽。
やっぱまだReactはコンポーネントがそんなに揃ってないんだよね。
だからjQueryも使わざるを得ないけど、それも一つのコンポーネントに閉じ込められるから
管理が楽。
極力なくす方向で行くつもりだけど、今はまだ両方使ってる。
あの気持ち悪いコード考えた人はマジでいい意味でも悪い意味でも頭イカレてると思う。
気持ち悪くて仕方ない。いまだに大嫌い。
どんなに気持ち悪くても、結果が伴う以上使う。
5年後も自分がこの仕事やってるかどうかもわからんからそんなこと気にしたことない。
今ある仕事をなるべく早く簡潔に実行するために最適だと思ってるツールを使ってるだけ。
それがかつてはjQueryだったし、今も一部jQueryだし、大半がReactになろうとしてるだけ。
将来まだこの仕事やってて、もっと有用なツールがあればそっち使う。
俺みたいな一人前にすら届いてない奴の意見なんぞ必要ないだろうけど、
自分の今の考えを書いておくと後で見返せるかなと思って適当に書いてみた。
まずReactの特徴は、「状態データから変換してビューを生成する」スタイルに統一されることにある。
これはjQueryをはじめとするDOM操作モデルでの、「初期状態ビューの作成」と「(イベントに伴う)状態変化からの部分ビュー変更」で構成するスタイルから脱却され、たとえば部分処理の積み重ねから想定外の状態が生まれることを防ぐ。
SPAは、クライアントが自立した1プログラムとして状態を管理する。サーバはUIと同様の非同期なイベント発生源/イベント発行先の一つとして扱う。またReactとReduxの組は、データベースサーバとサーバサイドページ生成のスタイルを、サーバとブラウザでやるようにシフトさせたものともみなせるだろう。
そしてReact自体には、JSX構文もbabelもいらない。JSXタグを書くよりむしろReact.DOM.div({...},...)等で書いたほうがプログラミングでは扱いやすい。JSXはサーバサイドページ生成のテンプレート言語利用文化に寄せた表現に過ぎないといえる。そして今ではbabelで変換する対象もES6 modulesのexport/importだけだ。これも分割ファイル対応のためにwebpackあたりを使うなら、ついでにbabelでES6 modulesも、といった程度のこと。
すでに一般に忘れられつつあるprototype, Dojo, Mooと同格であるjQueryのほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーなものとしては残り続けるだろうが。
Reactのモデルは関数型プログラミングのモデルそのものであって、そういう観点ではすでに何年も続いたものであり、React自体は消えたとしてもその手法は長く続くことになる。
**誰かみんなの主張のまとめを作ってくれないですか？** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)
最近、JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。
論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ！ってことなんだと思います。(virtual DOMがメインだ！という話もあったけど、じゃあ何でReactなの？というのは聞きたいかな。メジャーだから？)
ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ（SPAではなかったような気がする）を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。
まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。
世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか？あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの？という感じで。
トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね！」っていうことなんだと思います。
こういう例、JS以外にもいろいろあって、例えばboost、Androidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ・記法を使いましょう、ってことですよね。
でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます（そこまでは違わないかｗ）。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ！！」っていうのはかなり危ういように見えます。
そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonやRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通の言語から変えるようなソフトウェアが流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。dartとかどうなってるんですかね。(まtypescriptとか一種それだという話もあるか)
五年、十年あとにReact.jsって流行ってるんでしょうか。例えば五年前はcoffee scriptが結構流行ってましたけど、たしかもうサポート打ち切りとかになっちゃったんですよね。もちろん営利企業がバックなので、そこまで急になくなるかはわからないですけど、五年したらみんなまた別のライブラリがすごい！！みたいに言ってるんじゃないでしょうか。
まあだからこれはフロントエンドエンジニア業界全体の問題なのかもしれませんが、そういう将来的な保守コストをどう考えているのかが気になります。特にもし業務ページであるなら、せいぜいがなるべく枯れたライブラリ（≒JQuery）と、テンプレートエンジンあるいはフォーマットストリングでも使ってpure ES6で書いたほうがいいんじゃないでしょうか。そうすると結局SPAにはしないですよね。
まあこれを突き詰めるとじゃあetaxもactivexで、銀行のシステムはcobolで、マシンはpc98で、、、とかなっちゃうかもしれないんで、難しいところではあるとは思いますが、、、
とりあえずこんなところで、有識者の皆さんよろしくお願いします。
React.jsでした。angularと混ざりました。。あと特に喧嘩売ってるつもりとかは全くないですがそう見えたらごめんね。
id:murishinai 主張は単純で、せいぜいES6+トランスコンパイラ(+JQuery)とかでいいんじゃね、遷移はサーバー側でやったほうが楽じゃない？という感じです。
id:wordi virtual domが最大のメリット、ってのはよく見る意見ですね。例えば実際どんな場面で（どのくらいの規模のプログラムで）domの改変コストが効いてくるのか、みたいな実例を教えてくださると助かります。（もちろんFBとかはそうでしょうけど、もっとなんだろう、身近な例でお願いしたいです。）なんかReactががりがり（かつユーザー目線から見て有効的に）使われている例がイメージ出来ないのが問題な気がしてきました。
id:logic ええっと、それはそうなんですけど、なんだろう。標準のもので、少なくとも今後10年はあるだろうと言うもの(たとえばES6+フォーマットストリング)があるのにも関わらず、今後5年持つかもわからないライブラリを全面に押し出すの、ちょっと怖く見えるなあという気持ちです。
id:erukiti 具体的に頭の悪い点をご教授くださるとたいへんありがたいです。小規模だとそもそもvirtual domのメリットもなさそうですし、ES6標準でええんちゃうのんという気がしてならないのですが。
id:manaten もちろんFBやGMailをJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。（ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます）
SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか？」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOMを1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチな需要じゃないでしょうか。
あとなんか保守点検に関する意識がちょっと違うのかなっていうコメントが散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね？ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらにもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。
それともしかしたら「枯れた技術」あるは「標準化」という意識があんまりないのかなとも思いました。まあ確かに「Webの世界は日進月歩！」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。
あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJSが世界を救う！みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。
増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情でお仕事としてのエンジニアはしていないですし。ほんとに純粋な質問だと思ってもらえればうれしいです。
まあ長くなってきたので私のブログにまとめ直してもいいのですけど。
そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLでモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在は必要ですけど～。
とりあえずこれと
http://www2u.biglobe.ne.jp/~oz-07ams/2002/ecma262r3/fulltoc.html
http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html
それとw3cでDOM-Coreを読んでおけば一通りわかるようになる
ecmascriptは最新が5だった気がするがブラウザに実装されていない分がかなりあるのでまた後でいい
初めて書くのでいろいろと不慣れだけど許してください。
■作ったサイト
■使った技術
cron
位だったと思う。
スクレイピングをPHPでするプログラムが半年くらい掛かった気がする。
てかそもそもはなんとなくスクレイピングに興味を持って作りこんでたら「あれ？これエロサイト作れるんじゃね？」って思ったので
エロサイトを作った流れ。
Wordpressとかで実際にサイト構築したのは１日掛かってない。
■サーバー
特に目新しいことはないです。
記事一覧が表示されて、cookieでお気に入りが追加できて、タグ一覧があって、検索できるだけ、
作る方法は頭の中にあるけど、どうせ作っても誰も押してくれないんでしょ？見たいになってる。
■スクレイピングについて
ただXVIDEOSは日本語タイトルじゃないからそれを日本語にするのが手間と言う理由で今はとめてる。
翻訳APIを使ってやってもいいんだけど、サーバーが落ちそうだから嫌だ。
そうそう、スクレイピングがめちゃくちゃ重すぎてサーバーが落ちる！
これがちょっと困る。
さすがにスクレイピングを自作ではめんどくさかったので[PHP Simple HTML DOM Parser]というスクレイピングの定番ライブラリを使っている。
これが重い最大の理由なんだけど、これなしで効率よくスクレイピングさせるのはめんどくさかった。
あとは、簡単に他の動画サイトからスクレイピングできるようなつくりにしたから、やろうと思えばニコ動でもyoutubeでもいろいろなところから取得できる。
これは結構利点だと思う。
FC2が突如つぶれても他のエロ動画サイトからスクレイピングすることが出来るから。
今は0です。
だっておとといドメインを取ったばかり何だもの、インデックスだって100ページ程度しかされてないし。
とにかく更新が楽だから（自動だから）忘れたことにPVがあがってくれると助かる。
ということで、一通り書いてみました。
■追記
いろいろとコメントを頂いてうれしいです。
大変参考になりました。
アフィリエイト広告については悩んでたのですが、早めに乗せることにしてみます。
ありがとうございました。
■追記2
諸事情で1週間ほどサイトを閉鎖しています・・・(2015/5/28現在）
ちょっと復活まで待ってください。
よろしくお願い致します。
■追記3
復活しました！
ぜひお楽しみください！！
Web漫画ってcomicoだのマンガボックスだのニコニコ静画だのいろいろあって面倒臭いじゃん
FC2ホームページとかにただ上げてる感じで１ページ読む毎にページ遷移が必要な奴とかだったらスマホで読むには本当最悪の操作感
出版社がやってるwebマンガ誌はUIはまともなの多いけど雑誌ごとにアプリが違っててこれまた面倒くさい
comicoやone版ワンパンマンみたいな有名なのだけで良いからこういうのを統括して検索できたり回線ショボいスマホ用にwifi環境中に画像データをキャッシュ保存できたりするアプリって需要ないっすかね
画像転載はダメだけど2ch専用ブラウザみたいにDOM解析？とかして画像引っ張れるようにすれば著作権的にも問題ないっしょ
作ってくれたら５００円くらいまでなら出す
当方いちおうWebもやってるエンジニヤーなのでときどき学生の方（デザイン系、美術系が多いです）から相談を受けるのですが、
というのが2大苦労事例みたいな感じです。
もちろんtumblrで実現できない要件も世の中には存在しますがそのような要件は既にデザイナひとりで抱えるような要件ではないので適宜エンジニヤーを捕まえて振りましょう。
注意点としては、インスペクタに表示されるHTMLはJavaScriptなどから動的に書き換えられた結果のHTML（正確にはDOM）です。
逆に言うと、JavaScriptで動的にページを書き換えるような場合にはインスペクタは必須なのではないかと思います。
あとmiのような古臭いエディタを使うのはやめてAtomのようにHTMLタグの折りたたみができるエディタを使いましょう。
突然vimやemacsを薦めてくるエンジニヤーはクソなので相手をしないようにしましょう。（難しいもの薦めてくる人ほど最後まで面倒見てくれません）
はてなNG - Chrome ウェブストア
https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj
はてなブックマーク内ページ（http://b.hatena.ne.jp/）
はてなの閲覧がめちゃくちゃ快適になりました！
目障りなサイトやアカウントは見なくて済むし、ブコメページのノイジーなコメントも連打スターもなくなってスッキリ！
更にワンクリックで気楽にNGフィルターオンとオフの切り替えが出来るようにした事で、NGありなしの状態が一目瞭然で比較できて、はてなのエントリーの傾向、ブックマーカーの傾向もよく分かるという新しい発見も！追)そして自分がどんなに偏ってるかの発見も！
ホットエントリーに上がってくる、まとめ系、はてな村系、虚構系なんかは個人的にどうにも苦手で、それについて以前増田で書いたら多くのご批判、ご意見を頂きました。
人気コメントが「無いなら自分で作れば」って感じで、成る程、ほんじゃまぁやってみるかと。一度Chromeの拡張機能を作ってもみたかったので。
で、NGリストを登録してはてなの公式ページをフィルタリングする方向で作ろうと決めました。あと、どうにも気になっていたのがkiya氏系のスター連打。この対策も機能に盛り込もうと。構想が固まって、勉強がてらある程度の試作を作ってみました。したらなかなか良い出来なんじゃないかと、手前味噌だけど自分だけで使ってるのは勿体無い、面白いから皆さん使ってみて下さいよーって事で、この連休でChromeウェブストア公開用に一気に作り込みました。
ざっくりと。
Chrome拡張機能はHTMLとJavaScriptで制作できます。
それらをマニフェストファイル（manifest.json）というJSON形式の設定ファイルで、タイトル、説明、権限やアイコンなどと共に紐付けして設定します。
これらが入ったフォルダをChromeの拡張機能ページから読み込ませれば動作します。
Googleに$5払ってデベロッパー登録し、バナー等必要データを用意すればChromeウェブストアで一般公開もできます。
拡張機能のスクリプトが動作する環境は大きく分けて4つで、マニフェストファイルで設定できます。
このマニフェストにはバージョンがあって、現在使用できるのは2.0のみになっています。Chrome拡張機能の製作方法はググれば先人達の情報が沢山出てきますが、このバージョンが古い情報もありますので注意しないとハマってしまいます。
参考にしたサイトは様々ですが、検索で出てきた日本語サイトでざっくりと把握させていただき最終的には公式サイトが一番確実でした。
http://dev.screw-axis.com/doc/chrome_extensions/（マニフェストのバージョンは1.0が対象のようです）
http://qiita.com/sqrtxx/items/19fd2114430e9e1fb57f
http://blog.fenrir-inc.com/jp/2012/09/jquery-chrome-extension.html
https://developer.chrome.com/extensions
https://developer.chrome.com/extensions/api_index
Chrome拡張機能開発は思ったよりは簡単でした。JavaScriptが出来る人は一度試してみると楽しいかもしれません。と、同時にインストールする拡張機能によってブラウザが重たくなる理由もわかりました。ブラクラになる程重い処理を裏でぶん回す事も簡単に出来てしまうので、なるほどなーと。
そんな感じで開発したのですが、機能ははてな様の現在のページデザインに依存しております。ですので、はてなのサイトデザインが改変した際には動作しなくなったりレイアウト崩れしてしまう場合があります。ご了承くださいませ。その他バグなどご報告下さいましたら出来るだけ対応いたしますのでご感想など聞かせていただければ嬉しいです。
HTML5がやっと勧告とか良く分からない言葉になったが、ちゃんと現状を認識しておこう。
そもそも、HTML5の目的は、新しいHTMLなんかじゃない。
正確には、新しいHTMLなるための道標だったのだ。（過去形）
君たちは、window.alertという関数を知っているだろうか。
え？と思うかもしれない。でも、これこそがHTML5の役割だった。
ドキュメントにalertなんて在るはるがないのだ。
そうやってHTMLは分断されていた。
HTMLというドキュメントを操作するAPIとしてDOM。そして、それ以外のAPIは黙殺。
XHTML1.xでも、それは繰り返された。
XHTML2.0が失敗したのは当然ともいえる。分断されたままアプリケーションに拡張しようとしたのだ。
現状を省みずに、ただ夢を追った。
既にHTMLはドキュメントではなくアプリケーションであると。
アプリケーションとして見たHTMLには、windowというオブジェクトが存在している。
次に進むのに必要なのは新しい夢などではなく、現状の再認識だ。
そう、それがW3Cに採用され、君たちの知っているHTML5になった。
「HTMLからバージョンを消すことです。バージョニングなんて考えは古い。HTMLは常に更新されるものです。」
彼らはそう語っていた。
window.alertがクロスブラウザで使える。それがHTML5だった。
君たちは、気付いてるだろうか。
以前よりもクロスブラウザで悩まされることが減ったことに。
だが、それでも道を踏み外した。
また夢を盛り込もうとした。アプリケーションならアプリケーションなら。
新しいアプリケーションプラットフォームという肥料でまるまると太った豚になった。
豚は、そのままでは動かなかった。
「HTML5.1です。」
HTML5は、終わった。
もうPC向けWebブラウザは、進化する余地がないのか、停滞しているように思えてしょうがない。
IEはともかく、FirefoxはデザインをChromeにしちゃったし(あれのどこがいいのやら)、Chromeに至っては、停滞どころか悪化しているとさえ感じる。
IE8になってようやくWeb標準に従うようになって、IE9でJavaScriptが劇的に速くなり、IE11でかなりWeb標準の準拠度が改善された。
また、Windows XPのサポート終了により、IE6というWebデザイナーの多数を地獄送りにしたブラウザから完全に脱走できるようになった。
しかも、サポートポリシーが変わって、2016年1月以降は各OSで最新のバージョンしかサポートしないと決まったため、思ったよりも早くWebデザイナーの苦痛が取れるようだ。IE6で懲りたんだろうか。
しかし、IEコンポーネントブラウザの互換性を軽視する傾向にある。
IE10では、Windows7の必須アップデートのせいで画面描画が乱れる場合があったり、特定のWebサイトでIEコンポーネントブラウザをフリーズさせるという必殺技を披露した。
IE11では、一部環境でDOMストレージが原因でブラウザコンポーネントを十数個開くとフリーズする新必殺技を披露した。(現在、バグ修正済)
次のIEでは、どんな技を披露してくれるのだろうか。
Chromeをパクってと同様、高速リリースサイクルになって3年目。
アドオンの互換性に悩み、自ら失敗といいつつも、高速リリースサイクルを何とかやっていけてるようだ。
シングルプロセス/マルチスレッドながら省メモリとJavaScriptの速度チューニングを着実に行っている。
つい先日、australisというChromeのパクリに非常によく似たUIを強制適用し、一部ユーザーから顰蹙を買う。
高速リリースサイクル、強制アップデートを流行らせた元凶。
Chromeは初期設計のポリシーがよく、HTML5の準拠度とブラウジングスピードは今でもよい。
登場からあっという間にシェアを獲得し、主要ブラウザと呼べるほど有名に。
しかし、バージョンが上がるたびに肥大化し、メモリ消費量がますます増え続け、低スペックマシンでは重くなる一方である。
レンダリングエンジンがWebKitから独立してBlinkになったが、さらに迷走していく。
ユーザーが阿鼻叫喚した、ウィンドウシステム共通化プロジェクト。
理想は、各種コントロール(スクロールバーやボタン、エディットボックスといったもの)を全プラットフォームで共通化した上で、GPUによる描画で高速化する・・・ということだった。
Windows版ではバージョン32から適用された。しかし、安定版になってもスクロールバーの矢印が消えた、汎用マウスジェスチャが使えない、
縦/横スクロールがまともに動かない、Webフォントが描画されないなどなど、多数のバグが残存していた。
今でも、バージョンが上がるにつれて改善されたものもあれば、一度改善していたのに不具合が再発するなど、安定版といいつつ安定しない日々が続いている。
いったい、「安定版」とは何なのだろうか。
最近、ChromeはGoogleのものであることをユーザーにしらしめる努力ばかりやっているのではないか。
Google Nowなど、自社のサービスを便利に使うために機能追加するのは別にかまわないが、新しいタブページの異常にでかいGoogleロゴはどうだろう。
よく開くページのサムネイルを小さくし、下に追いやってまでGoogleロゴを目立たせる必要はあったのだろうか。
今年中にNPAPI廃止を目論んでいるが、それは現実的なのだろうか。
Chrome独自に持っているPPAPIは、セキュリティが厳格なゆえにNPAPIの代替手段には決してなりえない。少なくとも、PPAPI上で動くFlashがNPAPIのそれと同等の速度で動かない限り、廃止はありえないと思う。
Firefoxが高速リリースサイクルを採用した初期の時のように、高速リリースサイクルを優先するあまり、品質を犠牲にしているケースが目立っている。
最近出た37では、DirectWrite周りの実装がお粗末で、安定版が最初に出たころはズームイン/ズームアウトするだけで文字が表示されなかった(翌日に修正)。今でも、ビットマップフォントの表示品質がGDIよりも悪い。
高速リリースサイクルの弊害が現れているのではないだろうか。このことに、Chromiumの中の人たちは、気づいているのだろうか。
なんかこの前ここで書いたダイアリーが400はてブとかついてすごいビックリした増田だよ。
お陰ではてブしてもらった日はいろんな人に見てもらえたみたいで
1日で12,000PVくらいいったんだけど、次の日から順当にPVは下がり続けて
今は1日1000PVくらいをうろうろしてる弱小エロサイトになった。
あれからPHP書いたりWordPress更新したりってちょくちょくやってるんだけど、
PHPってなんであんなむずいんだよ。ふざけんな。アドバイスしろくださいおまいら。
いろいろ改善してみたり、失敗したりした。
こんなめんどくさがりな俺でも続けていけるものが見つかるなんて
まずこれ。これはなかなか成功したんじゃないかと思う。
といってもテーマファイルを差し替えて、自分で少しHTML/CSSいじった程度なんだけど。
iPhoneからみてもPCから見てもそれなりな感じになったのでとりあえずこれで満足。
プロからみたらダメなところたくさんあるかもしれないけど妥協しとく。
うん、まともに変わったところといえばこれくらいか。
SEOについて調べていくとどうやらエロサイトは検索流入と同じくらい
アクセストレードってのが大事らしい。性質上ソーシャルからの流入はあまり見込めないから当然か。
なのでよくわからんけど主要っぽいアンテナサイトに相互RSS登録した。
いまのところあんまアクセス流れてこない。どうなってんだよアンテナどころか圏外じゃねーか。
そんでこれが本題。
やっぱり記事の更新作業がくそだるい。ニートなのでラクをしたい。そのためなら勉強する。
やりたいことってのはまとまってるんだけどそれを実現するためのソースコードが思い浮かばない。
Simple HTML DOM Parserってのを使えばいいってところまではわかった。
・指定のサイト、もしくはXVIDEOSから新着のサムネイルとXVIDEOS埋め込みタグを拾ってくる。
・それをデータベースに登録する。(この時にWordPressには下書きの状態で投稿されると最高)
・6時間おきとかに1日4回くらい実行する。
こんなことがしたいんだけどもうわけわかめ。
さらにそれぞれに紐づく下層ページにある埋め込み動画タグをスクレイピングするってのがわからない。
ここで書くのは間違いかもしれないけど教えてエロい人。
いい感じのタイトルを自動でつけてくれるとかいう神プログラムを組みたい。
ヤフーが提供してるAPIで形態素解析なんちゃらとかいうのを使えばできそうだなーとか思ったけど、
あまりに光の見えないトンネルに突っ込みそうだったからこれはまた今度。
ってことで整理するために書き起こしてみたけど
PHP,MySQLあたりの勉強をもっと頑張ればうまくいくのかな。
他のエロサイトがどうやってスクレイピングしてるのかまじで知りたい。
やっぱりRuby on Railsとかでスクレイピングしたほうがラクなのかな。
あーなにか目標持ってこんなに1日中ひとつのことに没頭してるの何年ぶりだろ。
