「jsx」を含む日記 RSS

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

2022-08-20

だれかシャノンラボのReact×Firebaseマンツーマン講座を受講した人いる?

どんな感じでした???

https://shannon-lab.co.jp/?p=9737

React×Firebaseマンツーマン講座

概要

昨今ではFacebookが開発したJavaScriptフレームワーク「React」が注目を集めていますFacebookInstagramAirbnb等の大規模なサービスからプロトタイプまで幅広い現場採用されています

また、GoogleのBaaS(Backend as a Service)「Firebase」が登場し、バックエンドの開発が不要となり、大幅な開発工数の削減が可能となりました。

Reactにフロントエンド、Firebaseをバックエンドとして採用することで、効率的に質の高いWebアプリケーションを開発することが可能になりました。

しかし、ReactやFirebaseは日本語情報も少なく、学ぶ機会も限られています。本講座では、React、Firebaseの基礎からアプリケーションの開発までマンツーマン指導を行います

カリキュラム

ReactとFirebaseの基礎を習得し、演習としてSNSの開発を行うことで理解を深めます

React概要SPA

関数コンポーネントJSX基礎

ステート管理基礎

定番ライブラリ

UIコンポーネントライブラリ

Firebase概要

Authentication基礎と会員機能

Firestore基礎とRDBとの違い

Cloud Storage基礎

Cloud Functions基礎

セキュリティルール

SNS開発演習1

SNS開発演習2

SNS開発演習3

StyleCIによるデプロイ自動化

本講座のメリット

開発からデプロイまで、テストツールを使い実際の開発に限りなく近い環境で学ぶことにより、実践で生きるスキルが身につきます。一人でもアプリの開発ができるようにスキルアップしていけます

講座スケジュール費用

授業時間 週1回1.5時間

受講費 月7万x6ヶ月=42万円+税

期間 2020年10月~2021年3月

'''

2022-07-21

Reactについて知ってる人少ない

技術部顧問レベルでReact知ってる人って少ないよね(実務で使ってる場合)

技術トップがReact知ってると、ちゃんと開発してるんだなあ、って思うけど。

なんも知らないやつマジで知らない落差がすごい。

 

コンポーネントを細かく分割すると本当に小さい部品テキストエリア送信ボタンだけの部品かになるので。

開発者によってはコンポーネント数は凄まじく増える(いいかいかは別として)

コンポーネント複数まとめて一つのファイル記載できるからjsxファイルの数=コンポーネントの数じゃない。

 

jsxファイルの数=コンポーネントの数って前提で話してる技術部顧問と話して、その上絶対自分の間違いを正さないから、話合わなくてめんどくせー

 

これもうJavaクラスなんかと勘違いしてるだろ。

JavaとかやってるからReactもノリで答えられるっしょ〜、みたいなやつ。

まずコンポーネント理解して欲しい

 

この顧問のように勉強しなければ、すぐに時代遅れになるんだなと自戒した

というか十分な知識のない奴はこういう知ったかぶりの言うこと本気にして鬱になるんやろな…。

「えっ、もしかしてjsxファイルの数=コンポーネントの数だと思ってます?(笑」

っていいそうになったわ。そいつのためにはならないけど、もうそういう何かの訓練だと思って黙ってたわ。

2022-07-12

React.jsの良さがさっぱりわからない

何年か前に、Vue.jsとReact.js比較して、Vue.jsを使うことに決めたんだけど、

最近の風潮として、React.js一強になりつつあるから、またReact.jsのことをちょっと調べ始めた。

正直、React.jsって何がいいんだかさっぱりわからない。

JavaScriptの中にHTMLタグ記述されるJSXって、ものすごく筋が悪いように思う。

大昔、Servletの中でちまちまHTMLタグ出力してた時代に戻ったみたい。

後、これってどういうワークフローで開発してくの?

デザイナーHTMLCSS書いて、プログラマーJavaScriptを書く、みたいなときってどうやんの?

2022-07-08

React とは「選ばれし者たちだけが振れる伝説の剣」である

私がまだ駆け出しだったころ React に挑んで挫折した。

JSX別に気持ち悪いとは思わなかった。classNameとhtmlFor以外は)

------------------------------------------------------------------

そんな自分でも Vue は一瞬で理解できた。

使いたいデータは data に書けばいいし、使いたい関数は methods に書けばいい。

非常に単純明快だ。

------------------------------------------------------------------

React は、JS をある程度理解していないと使うことすらままならない。

さらに React の設計思想を深く理解していないと、うまく使いこなすことはできず render 地獄が生まれしまう。

「俺たちの設計思想理解できない奴は使わなくていいよ。初心者のためにわかやすくなんか絶対しないよ」と言うメッセージを、駆け出しの私は確かに受け取った(実際そう思ってるんじゃないかな)。

------------------------------------------------------------------

React 推しエンジニアほとんどは、発表当初すでに JS に強かった人が多い。

そして Vue すら理解できないエンジニア世間にはゴロゴロいることも知らない層だと思う。

から批判に React を礼賛できる。そりゃ自分や周りが振る分には切れ味最高なわけだからね。

その剣を持ち上げることすらできなかったり、持ち上げられてもうまく振れない人々がいるなんて、思いもしないのだろう。

------------------------------------------------------------------

React は実際、多くの美点を持つライブラリである

しかし強いエンジニアに影響された何もわかってない駆け出しが「React 最高〜〜 Vue はクソ」みたく嘯いているのを聞くと「本当にわかってて言ってる?」と思わざるを得ない。

Vue の Options API すら理解できない人々に、useEffect が使えるわけないからだ。

React 信者たちは「俺達が簡単に覚えられたんだからお前らもできるだろ」的な知的マッチョ思想で、不特定多数の駆け出しにReactを勧めるのを今すぐやめるべきだ。

------------------------------------------------------------------

もちろん強いとわかってる後輩には勧めていいけどね。

日本エンジニア給与の下限は、Reactを習得する対価としては低すぎるのです。

------------------------------------------------------------------

最後一言、Svelteはいいぞ

(こんなことを書くとステマだと言われるが、書かないと「じゃあ代替案を出せ」と言われるから一応ね)

2022-03-26

Reactの良さがわからない

JSXが嫌いとかそう言うわけじゃない。慣れれば、これはこれで良いかなと感じる部分もある。

只々、双方向バインディングが一々面倒。


何かの入力項目があった場合に、State定義して、入力変更イベントを拾って、Stateに設定し直す処理を毎度書く必要がある。

何十項目とそれがあった場合、面倒だし、それらが単純なものとは言え、無視できないコストになってしまう。


コンポーネントコード中に、あまり本質的でない、State定義入力変更イベントStateに設定し直す処理が、何十スクロールと続くのって読んでいて辛くならない?


State定義Objectでまとめて定義するって言うのも、解決策の一つなんだろうか?

調べてみたらできるっぽいけど、Objectの分割代入を使わなくちゃいけないみたいで、これはこれで面倒。


React Hook Formと言うのもあるみたいだけど、そもそもコアな部分で、それを吸収できる機構が無いのは如何なものかと思ってしまう。

(それをしないのが、React的なシンプル設計思想でもあるのかな?)


Vue.jsでは、双方向バインディングはv-modelだけで出来ちゃうし、Angularの事は詳しく無いけどAngularも同じノリで出来るみたい。

まとめると、自分的な辛さの原因は『双方向バインディング辛い』ってことだけなんだけど、みんな本当にReactに満足してるのかな?


あと、Reduxに関しても、ちょっと言いたい。大抵のプロジェクトで、そこまでRedux使いたくなるか?

SNSのようなリッチインタラクティブが求められる尖ったUIを作るのなら、もしかしたら必要なのかもって思うけど、大抵の場合不要じゃないかって思うんだけど。

2022-01-20

anond:20220120005158

フレームワーク使ってるのにブラウザ上のHTMLタグ閉じ忘れチェックするの?

JSXなりvueファイルしかチェックしないでしょ・・・

2022-01-19

なんでReact使ってるの?

ReactもAngularもVueも使ってきたけど

JSXを半ば強制されるReactはあんまり使いたくない

何故かってPugを使いたいか

Pugを一度使ったらHTMLなんてもう使えない

Pugを使うためだけにVueを使ってるといっても過言では無いというかそれが真実

将来的にVueとReactのどっちが生き残ってるかとかどうでもよくて

だって5年後にはきっと全然違うフレームワーク使ってる

というかWebじゃないかもしれない

なので今使いやすフレームワーク使えばいいと思うし

新しいフレームワーク学習コストが高いと思う人は退場した方が身のためだと思う

2020-05-09

anond:20200508160908

お前のせいでJSX女子小学生と○ックスにみえてにただろ。React使いに謝れ!

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

2016-05-22

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技術者普通に触れる程度の成熟はしています(枯れたとまでは言いませんが)。

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

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

jQueryからReactに移ろうとしてる自分個人的理由

http://anond.hatelabo.jp/20160521163144

内容から誰が書いてるかわかるかもしれんけど、まぁスルーよろしく。

jQueryもそんなにガッツリ使ってるわけでもないし、Reactはまだリリース前の調査下地作りの段階だけど

正直言ってjQueryに戻るつもりは毛頭ないぐらいReact便利だと思ってる。

でもjQueryを捨て去れるかというとそれも無理だと思ってる。

その辺のことを適当に書いてみる。


用途

社内サポート的なことやってて、サポートテンプレート対応を省力化するために

Webツール作って人が対応するコストを減らすために使ってる。

チーム組んでガッツリ大規模ツール開発ってわけでもない。

jQueryで一つツール作ってリリースしてそこそこ人的コスト削れたのはよかったと思ってる。


jQuery脳内DOMリーとの格闘に疲れ果てた

最大にして一番の理由がこれ。

そんなに大規模なアプリケーション作ってるわけでもないし、関係者も俺一人だけど正直DOMリー脳内でくみ上げるのに疲れた

500行もいかないようなショボいコードでも脳内DOMリーと格闘するのしんどい。

DOMリー触るほうが楽ってみんなどの程度のコードでそんなこと言ってんの?

そんなスーパーハカー揃いなの?信じられないんだけど。


React-Bootstrapかいう神コンポーネント出会った

オリジナルbootstrapはどうしても頭に入ってこなかったし、手を付ける気にもならなかったけど

React-Bootstrapマジで楽だし、スッと理解できる。マジ最高。

Bootstrapってこっちを本筋にすべきじゃね?と割とマジで思ってる。

まだ触って3日も経ってないけど。


ページのほぼすべてがjsに集約できる

これはちゃんとしたWeb界隈の人は利点と思わないのかもしれないけど

一人でいろいろ賄わざるを得ない俺みたいな人間にとってはマジで楽。

ベースHTMLにはベースのdiv一個載せとくだけで後は全部js

レイアウト大元コンポーネントでReact-Bootstrapで組んで、あとは各コンポーネント

個別に作っていけばいい。

HTML見て、CSS見て、JS見て、っていちいち記述方式の違うコードを見る必要がないのは

少なくとも俺にとっては一番楽。


でもjQueryも完全には捨てられない

やっぱまだReactはコンポーネントがそんなに揃ってないんだよね。

からjQueryも使わざるを得ないけど、それも一つのコンポーネントに閉じ込められるから

管理が楽。

極力なくす方向で行くつもりだけど、今はまだ両方使ってる。


JSXは汚くて気持ち悪いけど、コードで書くのはもっといから仕方なく使う

あの気持ち悪いコード考えた人はマジでいい意味でも悪い意味でも頭イカレてると思う。

気持ち悪くて仕方ない。いまだに大嫌い。

でも書くコード減らせて楽なんだよね。だから仕方ない。

どんなに気持ち悪くても、結果が伴う以上使う。


5年後なんて自分の姿すら思い描けないことは考えない

5年後も自分がこの仕事やってるかどうかもわからんからそんなこと気にしたことない。

今ある仕事をなるべく早く簡潔に実行するために最適だと思ってるツールを使ってるだけ。

それがかつてはjQueryだったし、今も一部jQueryだし、大半がReactになろうとしてるだけ。

将来まだこの仕事やってて、もっと有用ツールがあればそっち使う。

別にツールにこだわるつもりは毛頭ないから。

Web界隈の人はもっと真剣考慮すべきかもね。


ちゃんとしたWeb界隈の人のちゃんとした意見も見たい

俺みたいな一人前にすら届いてない奴の意見なんぞ必要ないだろうけど、

自分の今の考えを書いておくと後で見返せるかなと思って適当に書いてみた。

ちゃんとしたWeb界隈の人にとってこの辺の問題ってどんなもんなんだろうね?

みんなも増田ポエム、書こう!

http://anond.hatelabo.jp/20160521163144

まず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自体は消えたとしてもその手法は長く続くことになる。

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

**誰かみんなの主張のまとめを作ってくれないですか?** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)

最近JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。

論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ!ってことなんだと思います。(virtual DOMがメインだ!という話もあったけど、じゃあ何でReactなの?というのは聞きたいかな。メジャーから?)

ただちょっと個人的違和感が拭えないので聞きたいです。

ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ(SPAではなかったような気がする)を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。

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

まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。

世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか?あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの?という感じで。

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

トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね!」っていうことなんだと思います

こういう例、JS以外にもいろいろあって、例えばboostAndroidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ記法を使いましょう、ってことですよね。

でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます(そこまでは違わないかw)。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ!!」っていうのはかなり危ういように見えます

そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通言語から変えるようなソフトウェア流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。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 もちろんFBGMailJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。(ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます

トランスパイラですねごめんなさいw

SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか?」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOM1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチ需要じゃないでしょうか。

あとなんか保守点検に関する意識ちょっと違うのかなっていうコメント散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね?ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。

それともしかしたら「枯れた技術」あるは「標準化」という意識あんまりないのかなとも思いました。まあ確かに「Web世界日進月歩!」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。

あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJS世界を救う!みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。

増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情お仕事としてのエンジニアはしていないですし。ほんとに純粋質問だと思ってもらえればうれしいです。

まあ長くなってきたので私のブログにまとめ直してもいいのですけど。

そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在必要ですけど~。

2015-02-15

二種類のJSXについて——DeNAはFacebook名前を譲るべきだ

この世にはJSXと名のつくものがふたつある。

名前から察せる通り、これらはコンピュータとかWebとかそういうのと関係のあるJavaScriptというスクリプト言語関係する。

そして、この「JSX」という同じ名前のモノが同じ業界に二種類存在してしまっているのだ。ひとつDeNAが開発したもの、もうひとつはかのFacebookが開発したものだ。

DeNAが開発したJSX

https://jsx.github.io/

Facebookが開発したJSX

http://facebook.github.io/jsx/

しかも、GitHub検索したらあといくつかあるらしい。本当に嘆かわしいことだ。

https://github.com/search?q=JSX

私は、DeNAかい日本国内だけでは知名度のある企業は、世界的な大企業Facebookに早くJSX名前を譲るべきであると思う。

DeNAなんて、日本でいうところの百度新浪捜狐に等しい。なんか違法な感じの動画とかちょっとアダルトっぽいコンテンツを見たときに見たことがあるようなないような、というレベルだ。

オープンソースとそのコミュニティーによって支えられている現在Webというもの、そしてその発展を阻害しないためにはFacebookという巨人に席を譲るべきだろう。

2013-11-22

料理レシピサイト運営の某C社の面接に行った

まぁ、本当に優秀な人(RubyコミッタとかJSX作ったとか)しか取らないんだろうなぁという感じの面接だった。

いちおうこの僕もコード試験パスして来てるはずなんだけど、あまり相手にされてない感じだったよね。

それにしては新卒取ってるんだよなぁ。不思議会社

2013-09-09

http://anond.hatelabo.jp/20130908232805

プログラマならjsxするといいよ。

psd処理の自動化+それに伴って厳密な(デザイナに対する)仕様設定もできる。

一旦決めちゃえばシャドーだろうが何だろうがボタン一発でスライス。書き出し。

多分どこのフロントエンドエンジニアもそうやってるよ。

面倒な奴からは本当は工数1分のところ半日にして請求すればいいよ。

追記:あとSlicyってアプリがpsdスライスに便利っすよ。

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