「Dom」を含む日記 RSS

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

2017-11-29

何者にもなれなかった

フロントエンドエンジニアにもデザイナーにもなれなかった.


HTML/CSSリファレンスなしで書けるし, WAI-ARIAを用いたアクセシブルなコーディングもできる.

CSS設計意識した保守性を大切にしたコードを書いているし, CSSアニメーションインタラクション操作できる.

SVGを一から書く方法やいくつものブレイクポイントを持ったページのコーディングスキルも身につけた.

Gitバージョン管理をしたりWebPackでscssコンパイルリントを通したりする能力も得た.

インプットが大好きで, 毎日毎日様々なWebに関する知識を頭に詰め込んだ.


だけどJavaScriptは書けない.

JQueryコピペして簡単DOM操作を行うのが限界だった.


然しながら, 昨今のフロントエンドエンジニアJavaScriptが書けて当たり前だし,

JSフレームワークWeb Assembly, Web Componentsをバリバリ使いこなして開発している.


サーバーサイドレンダリングが主流のこの時代, 生のHTMLを書いているような人種は淘汰され,

数年後には食いつなぐことが厳しくなる未来しか見えない.

両者の間には旧石器時代現代程の格差を感じる.


デザイナーなら道はあるかと思い, UIデザインにも挑戦した.

バーティカルリズムや8pxルール, 配色理論意識した整ったレイアウトSketchIllustratorで作れるようになった.

でも'整ったレイアウト', '小奇麗なレイアウト'は作れても, その壁を超えることはできなかった.


全ては自分怠惰性が招いた結果である.

だけど, 藻掻き続けても道が拓けない.

もうこの先, どのように歩み進めればいいのかもわからない.


助けて欲しい.

何者にもなれない自分は嫌だ.

2017-11-18

anond:20171118113822

主張が良く分からん

手元で計測してみたら、

阿部 寛のホームページDOM Content Loadが100ms、Load200msから300ms

dev.toがDOM Content Loadが200ms、Load6秒から7秒

だった。

阿部 寛のホームページアクセス5回(画像2枚)で終わっているのに対して、dev.toはトップに含まれコンテンツが多いので当たり前ではあるが。

2017-11-11

IT技術の禍根

今更言ってもしかたないけど、筋が悪い技術が広まって変えられなくていろいろ災難起こしてるのってあるよね。

Cが広まったのとか。

昔はコンパイラ技術が低くて、ああい言語効率よかったけど、すでに90年ごろには最適化技術が発達して「人間テクニックを使って最適かするより素直に書いてコンパイラ最適化させたほうが実行速度が速くなる」とか言われてたし、Macなんか開発言Pascalだったし。

OSやミドルウエアが(せめて)Pascalで書かれてる世界線だったら、いまのソフトウエア脆弱性は大幅に減ってたと思うわ。

あとマークアップ言語HTMLの上で動的型のJavascriptを動かして、フロントエンドプラットホームになってしまってるのとか。

一時期、ネットアクセススマホアプリから行うのが一般的になって、Webは衰退するって観測で、いい方向に向かってたけど、最近アプリ開発までDOMの上にReactとか積み上げてJSでやろうみたいな流れがあるし。

業務アプリなんかもPHPJSの人に、昔のクラサバのほうが開発効率よくてユーザーの使い勝手もよかったって言っても全く理解できないみたいだし、どんどん悪い方向に向かってるな。

2017-10-02

うそろそろHTMLJavaScriptは終わってほしい

今そういう話題ホットエントリに入っているけど、HTML/DOMを再発明っていうか、もうやめればいい。

モバイルブラウザでなくてアプリネットアクセスしてるからPCもそうすればいい。

HTML+Javascript+PHP現場仕事をしていて、偉い人に「昔のクラサバのほうが開発効率いいしユーザーも使い勝手良かったっすよ。今のWebアプリは開発効率悪いし使いにくいけど時代の流れだからしかたないっすね」みたいなことを言ったら、すごい感情的に「それは同意できない。どういうことか言ってみろ」とか食ってかかられたわ。

Web系の動的型の言語を使ってる人たちはガチに、自分らは開発効率いいと思ってるのがすごい。

一般に公開するようなものWebがいいだろうけど、業務系は普通にPCアプリで作ったほうがいいよな。

Webアプリは、インストールしなくていいか運用が楽って触れ込みだったけど、業務系のWebアプリなんて大概、ブラウザブラウザバージョンが固定で、バージョンアップのたびに動かなくなるとかそんなんばっかりだし。

2017-05-06

結局Vue.jsが最強だった

Reactは大規模なフロントエンド開発なら良いかもしれないけど何もかも大げさすぎだし概念理解するのが大変

Angular2は最初覚えなきゃいけないことが,TypeScriptからまりES2015、依存モジュール多数と始めるのがまず大変

Knockoutは古いブラウザサポートしなきゃいけないとき以外は使わない

jQueryでのDom操作は増えてくると辛みがあるリアクティブに書くのは大変

Vue.js使うと覚えること少ないわ、リアクティブに動くわVirtualDomなんて意識しないで良いわで最高すぎる

たいていこれで良いんじゃないか

2017-05-01

http://anond.hatelabo.jp/20170501085956

JavaScriptDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔建設に耐えうる言語でもない。」

ほんとこれなんだよなあ。TypeScriptへ徐々に移行するしかないと思うけど、TypeScript廃れて来てるの?つい最近Googleが社内で公式採用したって読んだばかりだけど。

フロントエンドが嫌い

ウェブフロントエンド技術進歩と興亡の速度には目を見張るものがある。

browserifyが生まれGruntが生まれ、Gulpが生まれた。

そしてその全てが死んだ。

Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。

一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。

そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプター自称し最新技術のケツを追いかQiitaにクソを垂れ流す彼らこそ我らがイケイウェブフロントエンジニアである

最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれたて技術知名度は彼らにより上げられる。

それはやがて大きな同調圧力空気となって流行った技術を押し流す。

さて、少し話は変わる。

かつては栄えた技術が滅び、消え去れども残るものはある。

書いてしまったソースコードと拭いきれない遺物と化したクソの塊だ。

ウェブサービスはただ作って終わりではない。その先にあるのは長く続くメンテナンスだ。

少し例を挙げたい。あるところにイケイウェブエンジニアあなたがいたとする。

ある日あなた上司からあるウェブサービスを作ってほしいと頼まれ、それを引き受けた。

さて、サービスを作るにあたりあなた使用する技術を選定する。イケイウェブエンジニアあなたはとても流行に敏感だ。勿論jQueryを使い泥臭くDOMを弄くり回すことなどあってはならない。

あなたESの最新規格に準拠したコードを書き、Flowtypeで静的型検査を行い、Angular4を使うことにした。

勿論そのままでブラウザ動作しないためWebpackとBabelを駆使してトランスパイルする。

数週間後、めでたくサービスは完成した。

さて、問題はここからである

一年後のある日、あなた上司に呼び出された。

曰く、そのサービスに新たな機能を追加して欲しいのだという。

あなた脳内で試算する。時間と手間は掛かるが可能だと判断したところで、はい、と答え一年ぶりにプロジェクトソースコードを開いた。

ここであなたはあるものを目撃、頭を抱えることになるだろう。

それは何か。陳腐化した一年前のトレンド技術の塊である

一年後の未来世界では Webpack2 など既に新しく現れた技術に叩き潰され醜く断末魔の鳴き声を上げる死に瀕した哀れなヒキガエルの如き存在だった。もちろんAngular4はもう誰も使おうとはしない。

もちろんあなたもそれらを過去存在へと葬り去った新技術に首ったけだ。

さて、ここであなたがとれる戦略は次の2つだ。

一方は、クソだクソだと悪態を付きながらもはやメンテナンスもされていないクソプラグインの体系化されていないクソドキュメントとにらめっこをしながら古臭いクソの塊と付き合っていくこと。

もう一方は、新たに聳え立った最新のクソの塊に無限移植を続けることだ。

前者を選んだあなた時間が経つごとにまともな情報を得られなくなり、やがては身動きが取れなくなった段階でようやく最新技術への移植を考えはじめる。しかし、その頃には膨れ上がった旧時代のクソはそんなことを容易に許してはくれやしない。

さて、後者を選んだあなたを待っているのは無間地獄の如き最新技術の濁流だ。それに揉まれながら一年ごとに、古臭きは悪だと声高に叫びながら無限移植作業を行うことになるだろう。

どちらにせよ待っているのはクソの如き地獄である

しかし、どれほど技術が移り変われど変わらないものもある。

あなたがクソと罵り選択肢からも除外されたjQueryである一年後の未来であってもjQueryはそこにあった。もちろんクソと野次られながら。

クソレガシーこと枯れた技術の利点はそこにある。

勿論jQueryを使った品質の低いクソコードはクソだ。

けれども一年前のあなたjQueryを使ったコードが読めるし、今のあなたももちろん読める。一年後のあなたは疎か、三年後のあなたの後継ですらも (泥臭くDOMを弄るコード閉口しながらではあるが) やはりあなたの書いたコードを読めるだろう。

そもそもからしてウェブフロント倒錯している。

JavaScriptDOMを書き換えるためだけに存在している書捨てのクソ言語であって、サーバーサイドを書くために存在している言語でも、100万行からなるバベルの塔建設に耐えうる言語でもない。

前提からして倒錯したクソウェブフロントは一度無に還るべきだし、私はそんなクソウェブフロント界隈が大嫌いだ。

この意味不明なクソポエムも憎むべきクソの一端である

2017-04-21

ネタバレ注意】キングダム王翦って…

王 = king

翦 = 切りそろえる → 支配する = dom

実は主人公なんじゃね?

最近活躍だし、ここから秦が中華統一するまで神がかった快進撃だしな。

一方、李信なんて蒙恬と一緒に楚に攻め込んで返り討ちに遭って、逆に秦を滅亡の危機に陥れるんだぜ。

(その後王翦が楚を攻略

2017-04-12

良いこと

最近嫌なニュースばかりなので、良かったこと楽しかったことを挙げてみる。

梅干し純久しぶりに食べた。うめぇ

エビフライを久しぶりに食べた。うめぇ

・毛ガニをもらう。カニそんなに好きじゃなかったけど、歳を取ると共にどんどん美味しく感じるようになってきた

・オオスカシバを見た。かわいい

・近所の野良猫かわいい

・遅くまで残業していたら、酒を飲んで酔っ払ってきた社長がやって来て、チロルチョコをくれた。殺意を覚える。

・近所の古いマンションが、角度によってジブリっぽいことに気づく

・凄い強そうなおっぱいを見た

アニメ月がきれいを見た。おっさんのくせにドキドキした。

・久しぶりにヨコハマ買い出し紀行を読み返す。最高

上司がVBAに挑戦していた。Dom i as longになっていた。

・夢の中でサーフィンをした。凄いモテた。目が覚めて泣いた

・毎朝髪の毛が自分から卒業していくので、窓の外へ送り出している。元気でやれよ

以上

2017-04-11

オライリーに出てくるフレンズ

参考:http://www.oreilly.com/animals.csp

2016-12-30

2020年に振り返る2016年Web開発

後輩「先輩、このシステム僕が引き継ぐ事になりました。よろしくお願いします」

先輩「そうかそうか、やっと肩の荷がおりるな」

後輩「これ2016年に作ったシステムなんですよね。僕その頃まだ入社してないんで、最初の方から教えてもらっていいですか」

先輩「よしわかった。環境構築から順を追って説明する」

先輩「まずはじめにnode.jsを入れる」

後輩「あ〜昔流行ったサーバーサイドでJavascript使えるやつですよね。このシステムnodeで動いてたんですね」

先輩「いや、nodeは使ってない」

後輩「え?」

先輩「nodeに付属しているnpmというパッケージマネージャーを使ってる」

後輩「なんでまたそんな回りくどいことを・・・

先輩「当時はnpmが一番メジャーだったんだよ。今主流のN3(N3 is Not Npm)はまだ無かったしな」

先輩「よしnode入れたな。じゃあnpm installだ」

後輩「えい!・・・先輩、なんかエラー出ました・・・

先輩「printFizzBuzzというパッケージが404みたいだな」

後輩「何に使うんですかそのライブラリ

先輩「知らん。依存してるライブラリ依存してるライブラリ依存してるライブラリかなんかだろう」

後輩「バタフライエフェクトってやつですね」

先輩「思い出した。これは昔話題になったやつだ。printFizzBuzzは何かの特許抵触していて非公開になったらしい。

  npm installで落とすのは諦めて、ローカルに残ってるやつで何とかするしかないな」

後輩「それ使って大丈夫ですかね。法的に」

先輩「仕方ないだろ」

先輩「ようやく諸々揃ってBabelやReactやWebpackを使えるようになった」

後輩「それ何ですか?」

先輩「まずBabelだが、これはES2015をES5にコンパイルするツールだ」

後輩「え、なんでダウングレードするんですか?」

先輩「古いブラウザで当時の最新機能を使うにはこうする必要があったんだ」

後輩「なるほど。ではReactは?」

先輩「これは今で言うWeb Componentsみたいなものだな。あと仮想DOM

後輩「Babelじゃダメだったんですか?」

先輩「ダメだったんだよ」

後輩「で、最後Webpackは?」

先輩「リソースモジュール管理して最適化するツールだ」

後輩「最適化サーバー仕事じゃないんですか?」

先輩「当時はモジュールが標準対応してなかったり、http/2もあまり普及してなくてサーバー馬鹿だったんだよ」

後輩「へ〜大変ですね」

後輩「いつの間にかこんな時間ですね。今日まだ1行もコード書いてないですよ」

先輩「一度準備してしまえば、そこから先が楽になるんだ」

後輩「今となっては余計な苦労が増えてるような気がしますけどね〜」

先輩「当時はこれが最善の選択だったんだよ」

後輩「そうなんですね」

2016-10-06

html3d対応したとしたらどうなるんだろうね?

結局 js 書かなきゃいけないとかになるかな?

cssdom だけで表現できるようになったら意外と楽しそうな気がする

2016-09-14

Yahooショッピングメール

お荷物の発送手続き完了のお知らせ、ご確認商品出荷完了の三点のメール

それぞれWin32/GenKryptik.DOMの亜種を添えて。

zaq.ne.jpベトナムハノイと、dion.co.jp

ついに国内踏み台からですね。

2016-05-29

http://anond.hatelabo.jp/20160524094615

状態渡しとか関係なくDOMから長いだけじゃん。っていうか

そう書いてあるのに改ざんして引用するkenokabeさすがだな。

http://anond.hatelabo.jp/20160524094615

岡部氏が故意理解できなくて引用しなかったDOMどころか、

「静的型」という用語も知らないことが発覚。これはすごい

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-24

http://anond.hatelabo.jp/20160524145224

よーわからんw 岡部氏は、自作ライブラリHPで、

FRP純粋理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせ

まり関数型の拡張っていうなら誰も反対無いと思うんだけど。

FRPライブラリサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか?

https://www.npmjs.com/package/timeengine

HaskellのIOモナドみたいな別の抽象化DISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの?

IOモナドDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからFRPの効力がまざまざと見せつけられている。

荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?

あるよ。

関数がどのパラメータ依存して、何を結果として返すのか明確になる。

グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。

短いプログラムならそれでもいいけどね。

別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数関数に渡すのか?

グローバルな値を参照したり書き換えたりして

いやだから、定数なんだから書き換わらないんだよ、FRPストリームconst 定数なんだから

関数型のわかりやす説明であって、住井派に反対してるとか、岡部路線とかじゃないよね、と。

オブジェクト指向と対比して考え方をまず学ぶって岡部路線、住井グループはそれを目の敵にしていて集団的攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。

http://anond.hatelabo.jp/20160524143022

そうなんだよね・・そもそもconstの定数をわざわざ、関数引数にすべき必要があるのか??という根本的な問題がある。

たとえばGlobalにアクセスできて当然のDOM要素とか、Piとか、スコープ可視の定数は引数にしないよね?

2016-05-22

http://anond.hatelabo.jp/20160522140810

JS機械語だよ。

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

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

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

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

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん