「jQuery」を含む日記 RSS

はてなキーワード: jQueryとは

2016-11-18

JavaScriptが嫌いだ

今行ってる現場ではJavaScriptがいっぱい使われている。

使用しているライブラリjQueryをはじめ、EJS、Knockout 、jsTreeなどなどなど10近くに上る。

 

ライブラリに何ができて何ができないのかよくわからないし、

ライブラリはどうやって使えばいいのか英文サイト見ながら勉強したり、

サンプル通りに実装しているはずなのに期待通り動かなかったり……

ちなみにJavaScriptライブラリだけで1メガバイト以上のサイズがあった。

もういや。JavaScriptなんてなくなってしまえばいいんだ(´;ω;`)ウッ…

2016-11-14

http://anond.hatelabo.jp/20161114194700

jQueryスクリプトは$.(...)ではなく$j.(...)やjQuery.(...)で書く(prototype.jsとの競合を避けるため)

2016-11-06

http://anond.hatelabo.jp/20161106094548

LaravelのCRUD程度ができる、CakePHPはやったことないけど同じPHPフレームワークだし覚える気はある。

jqueryアコーディオンとかは何も見ないでも作れるが他はネットで調べつつ。

PostgreSQLをよく使ってたけどMySQLはしたことない。

でもフレームワーク使うならSQL文ほぼ使わないだろうから追々覚えたら行けるだろ

って考えの大阪プログラマーだけど雇ってもらえます

エンジニア雇いたい

CakePHPでの開発がちょろっとできて、

jQuery程度がちょろっと使えて、

MySqlがちょろっと使える。

そんなLv10程度のエンジニアを、月収25~30万、賞与入れて年収400万くらいで雇いたいんだけど。

ゴリゴリスーパープログラマーとかじゃなくて全然いいんで。

けど見つからないんだよね。

そんなにエンジニア給与って上がってるのかな?

どこの求人サイトに、このクラスエンジニアが集まってるんだろ。教えてくれ。てか君を雇いたい。連絡くれ。

2016-11-03

なんでruby on rails5の本は出版されないの?人気なくなったの?

普段プログラマーやってるんだけど

暇なときAmazon眺めてるわけです

買う目的以外にも、いま何が流行ってるのかを本の出版の流れから推測してるわけですよ

いやgoogle検索とかQiitaとかgitHubとかほかにもいろんなところから流行りを推測するなんてあるけど

本の出版ってはやりがわかりやすいなって思うんだよね

やっぱり本で勉強するのが一番だと思ってるおじさんからすると、本が出版される=流行ってるってことだと思ってるからねいまだにw



それでみると今は明らかにpythonがキテるわけですよ

あんなに本がなくて困ってたのに、いまや出版ラッシュ

こりゃ本当にデータサイエンスが盛り上がってるんだろうなって感じ

そんで相変わらずのSwiftね。これはもうiPhone開発の必須だもんね。とくに日本じゃiPhone

そんでJavaだ。アンドロイドサーバーもいけるもんね

同じくらいunityがもりあがってるなってのは感じる

地味に本が出版されつづけてるJavascriptPHP存在感あるなって思いながら見てたんだけど



あれ?Rubyは?railsは?って思ったんだよね

最近俺は追いかけてなかったんだけどさ

本が出版されないんだよね

4のときはすさまじい速さでキャッチアップして本が出版されたのにさ

不思議なことにドットインストールも4止まりだし



もうみんな分かり切ってるから出版されないの?ネットで十分じゃい!みたいな

本なんて情弱のもんだろ!PHPやってろ!みたいな?

Rails界隈の人だれか知りませんかね



それとlaravelとか出版されないね海外では人気です!っていうけど

PHPは地味に出版が続いてるけど

cakePHPは2年前までは出版されてたけど今は全然

それからjQuery流行り終わったなって思う

ネットでやたらうるさかったフロントエンド界隈は全く本が出版されないね

ReactとかAngularとか



でもそれでいうならRails4のときの盛り上がりは何だったんだろうってくらいみんな一生懸命だったよね

から5の無風感が怖いんだよね


そもそもWEBアプリオワコンとかそういう話なのかな

2016-10-26

技術に明るくないWeb系開発会社

まあうちの会社ことなんだけどさ。



エディタ秀丸 (ライセンスがどうなってるかは知らない)

テキストエディタ秀丸推奨。というかエディタに金を出してくれない。

OSSエディタが増えてきたにも関わらず、意識低いので秀丸メインが多い。



バージョン管理は「ファイルを別フォルダコピー

最近ようやくSVNを導入してこれは解消されつつある。

しかGitではなくなぜSVNだったのか。



英語から」という理由Github却下

前述の通りようやくSVNが導入されたけれども、Github提案は「英語で使いづらい」という理由却下



パスワード使い回し当たり前

社内システムパスワードは全部ほぼ同じ。

総務だろうと何だろうと全社員rootで見ようと思えば見られる状態

性善説に頼りすぎだろ。



枯れた技術しか使わない

簡単というだけの理由jQueryを今更正式採用

ReactやAngularJSといったモダンものは難しいという理由俎上にすら乗らない。

そして誰も勉強しようとしない。勉強しても評価されないから。



何年もメンテされてないようなプラグインフレームワークを使い続ける

既に開発が打ち切られたjQueryプラグインなんかを当たり前のように使う。

当然開発が打ち切られてるもんだから新版jQueryでは動かない。

結果、特定プラグインを動かすためだけに複数バージョンjQueryを読み込ませたりする。

にも関わらず「何で遅いのか」と問題になったりする。

コード見ろよ。



コミュニケーション手段メール

Slackチャットワークはおろか、Skypeなども使われていない。

チーム・部門の連絡は全てメール

受信するメールの量が多いため当然取りこぼしも増える。



技術的な話題がない

社内の技術者から最新の情報共有が一切流れてこない。

基本、技術共有という文化がない。

結果、話しても無駄だという空気になる。



営業技術に無関心

当たり前のようにIE8対応仕様書必須要件に含まれている。

最新ブラウザ以外の対応に別料金でも取ればむしろ工数と金になるものを、無知なので最低要件に含めてしまう。

何度言っても理解しない。




もちろん、別にこれがダメってわけじゃない。いやダメなのもあるけど。

「これ使えてるだけまし」って人もいるかもしれない。

ただ、数え役満っていうのかな、技術力の低さがインクリメントされていって、現状の「技術に明るくない我が社」を作ってるように思う。

自分が少しずつ会社を変えていけばいいのはわかるけど、決定権持ってる人間技術に明るくないと、枯れた技術がいよいよ朽ち果てる寸前まで現状をよしとする。

それが、うちの会社

気がついたら「まともな技術持った人」が全員辞めていた。

そろそろやばい感じがする。気づくの遅かったかもしれない。

2016-10-08

JavaScript 辛くないですか?

全然詳しくないんだけど、JS辛くねえかこれって思ったので書きます

アドバイスお願いします。



で、何が辛いのって話なんだけどDOM操作が辛い。

TODOリストみたいなアプリがわかりやすくて、TODOひとつ追加するみたいなシチュエーション。これ辛くない?

jQuery 使うにしろ最近流行りの React みたいなものを使うにしろ追加するDOMテンプレっぽいものJSファイルのどこかに埋め込まなきゃいけないのがそもそもしんどい

んで、これはHTML側のコーディングがちゃんとしてたら辛くなりづらいと思うんだけど、上記のようなコンポーネントテンプレが大体使いまわしづらくて似たようなのがポンポンまれてくる気がするんだよね。これめっちゃしんどくないですか。


以上です。

2016-09-17

起業しない理由

古参ネット使いとして苦言を申すよー。

私はWEBデザイナー12年目。

紙もできる。ポスター、チラシ、雑誌のページ。

WEBコーディングは当たり前。エディタmiで直打ち。

CMSは3つ扱った。

drupal

Wordpress

movabletype

周りは独立していった人も一定数いた。

だが私は会社員を望んだ。

その理由を下記に述べる。

1.サラリー

私は恵まれたと思うくらいの会社所属している。

有給年間20日。夏休み5日。毎年年休はほぼ使い倒す。

夏休みも、5日フルにとり9連休にしている。

給料女性平均よりちょい上。

2.面倒くさい顧客シャットダウン

周りに恵まれているのである

営業さんや上司が間に入り、アホなことを言う奴らを丸く収めている。

アカ20校目とかない。

3.営業苦痛

起業したとして、いまの年収を考えると4倍の収入が得られなくてはならない計算だ。

無理。

そんなスキルあったら別の事で生かしてブイブイいわせてるわ。

4.私も青かった

くせーくせー青くせー。

高校進学校に行き、日教組と反発し。映画が撮りたくて専門学校に行く為に一年バイトして学費を貯めた。

行った専門学校はクソで。

しょーもない日雇い派遣で末端を見た。

瓶にヒビが入ってないかひたすら検品をする8時間

フォトショイラレが使えるだけで日の目を見ることができた。

5.脱線したな

まあ、あれだ。ブロガープログラミング知識はいらないぞ。

それhtmlとかcssでいけるぞ。

もしくはJavaScriptとかjquery

あとPHP

ハローワールドーとか書いてよし!とか思ったらウェルカム

ブログプログラミング始めました、とかかいたらアウト。

2016-06-30

2016 年 6 月版初心者向け JavaScript セキュリティ

JavaScriptUI を構築していると XSS がうんたらかんたらみたいな能書きをきちんと理解してきちんとやっていくのが一番よいというのはそうなのですが、 2016 年にもなってそんなことの学習時間がしがし使うのもおかしい気がする。おかしい気がしないというそこのあなたCPUFlash ストレージから自作して現代風のシステム全部作っといてください。

というわけで初心者は以下の原則を守ればいいと思う

JSjQuery作業しない

PHP だけでなにかを作る人間はもうたぶんいないですし、 JavaScript での UI 構築ももうそういうものだと思っていいのではないでしょうか。 React か Angular かなんか使っとけばいいと思います。 React おすすめ。これらの現代っぽいフレームワークを使っている限り XSS のような初歩的なミスはほぼ起きません。 React の場合危険機能には Dangerously Set innerHTML というヤバそうな名前がついていて便利です。

同一ドメイン内に決済とかあるサイトに関してはもちろん上の原則はあてはまりません。それは初心者が触るべきものではない。

2016-05-25

http://anond.hatelabo.jp/20160521234423

というかですね、そもそもVをロジックの中にベタ書きしちゃうの嫌なんですよね。

MVCモデルというのは、オブジェクト指向の発想。

DOMというのは、そもそもDocumentObjectModelでオブジェクト指向

JQueryはそのVを関数型的に扱おうとした拡張

Reactは、これらすべてを一旦ご破産にした。

MVCのVだ、と公式サイト説明されているが、これは半ば皮肉であって、本当はVは存在しない。Cももちろん存在しない。M、モデルロジックしか存在しない。モデル一元論、それがReact。

VであるDOM消滅し、JavaScriptの `x` や `a` などその他の変数と同列のファーストクラス仮想DOMとしてしか存在していない。

まり仮想Vは、M(モデル)内で関数型の文脈自由自在演算できるわけ。

コード最後マウントしておけば、仮想Vは自動的に、実VのDOMとして描画される。

M=ロジックの外に、あらかじめわざわざ決め打ちしたVを用意するよりも、M=ロジックに一元化するほうが賢い。それがReactであり、JSX

http://anond.hatelabo.jp/20160521163144

ReactはJavaScript界隈の関数型プログラミング化の潮流で登場。

最近炎上している別の方面で、特にFRPと組み合わせると圧倒的なパワーを発揮すると一部では実例とともに指摘されている。

http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html

Reactは、関数型あるいは宣言型に書けるように用意されている。DOMは、「仮想DOM」として、JSJSX)上の「値」として統合されていて、それは自由に変形し、組み合わされ、リアクティブJSX上の仮想DOMからDOMリアルタイムマッピングされ描写される。

JQueryも、実DOM関数型で操作できるような拡張ではあるが、Reactのように宣言的に書くことは不可能

coffee scriptは、ES6登場までの過渡期の橋渡しみたいなもので、登場したのも消えたのも合理性がある。

React.jsは、関数型の潮流で登場したものでこれも合理性があり、この延長線上でさらに洗練された代替物が登場する可能性はあれど、このパラダイムが消えることはない。

【超ポエム】jQueryは解体されるべきである

よーするにjQeuryって「でかくなりすぎ」「今では不要になったものたんまり」なのかなあ。

なら、いっそ解体してしまうのはどうか。

どうしても生DOMをいじりたい変態にはそれだけの機能を。ほかのDefferedやらPromise実装が嫌いな輩にはそれだけの機能を。アニメーションのサポートが欲しい人にはそれだけの機能を。分割解体された個別の機能が存続すればいい。

解体プロジェクトの名は、そうだなあ、「Rightgene」あたりで。……すまん、これが言いたかっただけ。

2016-05-23

jQuery消し去りたい人って

純粋質問

ReactなりAngularを使ってjQueryはもう使うなって言うけど、

すでにたくさんあるjQueryプラグインと同じ機能実装したい場合はどうすればいいの?

歯車の再発明しなきゃいけないの?

2016-05-22

http://anond.hatelabo.jp/20160522140810

JS機械語だよ。

いくら仕様アップデートされたって、生JSDOM弄るのjQueryで弄るより辛いでしょ?

機械語人間にわかやす書くためにアセンブラがあるのと、生JSDOM弄るの"人間にわかやすくするためにjQueryがあるのって、似てない?

操作対象を直で弄るって言う根本は変えずに見た目を理解やすくするって意味結構似てると思うんだけどなぁ

http://anond.hatelabo.jp/20160522140810

ほんにこれ。生jsも出さずjQueryだのReactだの無知浅学でドヤって馬鹿じゃねーの

javascriptjqueryの知識もなくて、テンプレそのまま使ってる人がいる。

コードみたらぐちゃぐちゃだしJSなんて似たような内容のやつ5~6個読み込んでたり。

エラーが出たら私が直すようにしてる。

でもデザインがすごく良い。画像の使い方、文字の配置。

いつもそれを見て、凹む。うらやましい。私にはできない。

どれだけHTMLCSSJSの知識があったって、こんなの作れない。センスがない。

デザインの基礎を学ぶことはできても、応用はできない。

うらやましい、悔しい。私もあんものを作りたい。

http://anond.hatelabo.jp/20160522134726

jQueryアセンブラって生jsはどこいったんだよ勉強足りなくてまったく参考にならんわ

これだからReactはダメなんだよ

「Reactは大規模SPA用途以外はコスパ悪い」っていう先入観意味不明

しろweb制作入門用に最適だと思う。

個人的な考えは以下の通り。


UI構造がおおよそのコード構造と一致する

そもそもコンポーネント指向ライブラリからチュートリアルからして構造化を基本において書かれてるのが入門用にこそ適していると思う。

だって初心者の頃jQueryで場当たり的にコード追加していって九龍城みたいになったこと、あるでしょ?

もちろん自分で間違いを犯してその痛みを知るってのも方法論としてはありかもしれんけど、

DOM操作抽象化したライブラリから入って、徐々に具体的なところに落とし込んでいくのが効率的じゃない?


しろ小規模案件にこそ導入して「構造化とコード再利用」を意識づける

ライブラリ自体構造化を念頭に置いてるから自然とパーツごとに作るようになって、

その次の段階として自分の作ったパーツの再利用を考えられると思う。

jQueryで場当たり的に(以下略


抽象化の高いレイヤーから入って抽象化の低いレイヤー学習範囲を伸ばすべき

jQueryってホントに何でも出来るからキチンと扱える技術を既に持ってる人には良いだろうけど

やっぱ初心者には逆に指針がぶれやすいと思うんだよね。

チュートリアル書く人にもそれぞれ別の方法論があって、

しかもその振れ幅が広くて、どの方法論もそれなりに意味がある場合が多い。

正解が沢山ある問題をいきなり解かせるんじゃなくて、

まずは答えがある程度決まってる問題から入って、徐々に馴らしていくべき。


jQueryWebフロントエンド界隈のアセンブラだと思う

最初に手を出すには抽象化の度合いが低すぎるというか、

ある程度経験を積んだプログラマーこそが手を出すべきと言うか。

だってアセンブラ機械語がなくなってないのと同じように

webからDOMの直接操作不要になることもないと思う。

どんなに抽象化が高度になっても、裏でやってるのはDOMの直接操作なんだから

でも、大事な基礎技術からといって、それだけで済ませて技術革新放棄するべきではないでしょ

しろ抽象化の高いところから入門して、基礎技術に触れる必要が出来てから触った方が理解が早いと思う。


から初心者や小規模案件にこそReactを!

と、私は考えます

http://anond.hatelabo.jp/20160522003506

http://anond.hatelabo.jp/20160522003506

ども。

この辺りの一連の発言特に後二者)を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAWeb APIといったフロントエンド世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます

ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データ配信DB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリレベルに追いつき、同じやり方ができるようになった、というだけの話です。

とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。

具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドリアルタイム集計が登場する勤務予定表的なものを、1人でjQuerySPAで作った際、数百行のHTMLと数千行のJSスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代ベスト」として自信を持って残せますJSX局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません(私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います)。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。

「変な独自拡張を入れてまでJSを使い続ける理由わからん」についても、まるでJS生来嫌われ者で、クライアント側でもPythonRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね? たぶんES6は人々から積極的に愛されています。現状、クライアント側にPython進出するのではなく、逆にデスクトップモバイルサーバ側にどんどんJavaScript進出する流れが起きています

速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね(mustache使うよりは速いよね)ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通JS技術者普通に触れる程度の成熟はしています(枯れたとまでは言いませんが)。

http://anond.hatelabo.jp/20160521163144

coffeescriptは廃れたから使われなくなったんじゃなくて、言語仕様に吸収されて役目を終えたんじゃないの?

欲しい機能を先行実装して、それが仕様に吸収されて基本仕様需要が満たされた役目を終えるってむしろ素晴らしいことじゃん。


てか、jQueryを使って出た不満を解決するために出てきたのがReactであって、同じ不満を抱えてた人が多いから今の状況があるんでしょ。

jQueryだけでいい、Reactなど不用」ってのも「React最高!jQuery滅ぶべし」ってのも、どっちも共感できない。


一番わからないのは「Web界隈は流行り廃りが激しすぎて糞」とかい意味不明Dis

jQueryで得たDOM操作はReact触るときにも役に立つし、Web Componentsは仕様に組み込まれる方向で動いてるんだから

Reactが廃れるとしたら、それはcoffeescriptと同様にその役目を終えただけで、廃れたから使われなくなるわけじゃないと思うんだが。

全く別の技術が林立してるんならその批判もわかるけど、既存技術問題点解決する技術確立否定したら進歩なんか無くなっちまうよ。

利便性が上がって手間が減るスピードが速い事のどこが悪い事なの?マジで意味わかんねぇ。

学習コストこれ以上払うの嫌でござる」って素直に言えばいいのに、何でかっこつけようとするのかね。

http://anond.hatelabo.jp/20160521235357

元増田です。トラバありがとう

世の中の絶対数は知りませんが、自分脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、<input type="hidden">とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。

ユーザー体験がどうかはまあ意見が別れるでしょうからおいておくとして、ずっと楽に開発というのがよくわからないです。普通になんでもいいですけど、ウェブ側のフレームワークでちゃんとしたものを使っていれば別になんでもないことだと思うんですが、具体的にどういう状況を考えられていますか?

プログラムユーザーサイドだけでは完結しなくて、入力チェックとかいいろは絶対にやらないといけないですよね。ということで同じロジック複数書く場面が出てくることが多いと思います。そういう手間も含めたうえで開発が楽になるというのはちょっとよくわからないです。

んー、要するに「別物であるDartCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか?

ちょっとここ書き方分かりづらかったかもですが、「ES6で書く以上はES6を使えばいいじゃん」「変な独自拡張を入れてまでJSを使い続ける理由わからん」という2つの疑問を同時に書いたつもりです。

将来長持ちする気がしています

PHPJSP,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騒動とかもあったように、なんかまだちょっと不安がある感じがします。偏見でしょうかね。。

2016-05-21

http://anond.hatelabo.jp/20160521163144

React.js界隈の人に聞きたい

http://anond.hatelabo.jp/20160521163144

最近某所で、React使うとjQuery不要だ的なタイトル記事を書いちゃた気がするので一応反応しときます。長文ごめんね。

えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQuery不要」「jQueryは要らないこともある」と長く書いた方が正確です(本文ではちゃんとReactが万能ではない説明をしてる)。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。

そもそも世の中にそんなにSPAがあるのか

世の中の絶対数は知りませんが、自分脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、<input type="hidden">とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。

というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAから使いづらい」という主張はよく分かりません。GitHubTwitterサイトSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは(Reactではないけど)SPAで、ブラウザMarkdownレンダリングしていますhttp://webpack.github.io/docs/ )。サーバサイドで動くスクリプトタスクゼロ個人的にはこういう使い方で十分嬉しいです。

何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります自分中の閾値としてはJSコードが数百行超えるならもうReact使う。


JSXを使うことに抵抗ないんですか?

んー、要するに「別物であるDartCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか? 正直その主張を聞いたのは初めてです。歴史的JSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。

JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしていますJSXは「関数呼び出しのシンタックスシュガーJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います仮想DOM思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています

はい所詮JSXシンタックスシュガーなので、使いたくないなら使わず本来関数スタイル仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。

それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレート仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います

5年後のビジョンがありますか?

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を採用すべきだと思います

http://anond.hatelabo.jp/20160521190026

元増田です。

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のほうが五年後も活発にメンテされるのかどうか怪しいだろう。もちろん、レガシーものとしては残り続けるだろうが。

ここわかんないですね。活発なメンテがそんなに重要なのかな?ということです。まあモダンな感じで書きたいということは理解できますが、それさえクリアされていればいいんじゃないでしょうか。そうでもないですか?

ログイン ユーザー登録
ようこそ ゲスト さん