質問編集履歴
13
Reactの記事にしたいのにAngulerやKnockoutの記事になってしまうのでタグを削除しあmした。
title
CHANGED
File without changes
|
body
CHANGED
File without changes
|
12
改善
title
CHANGED
File without changes
|
body
CHANGED
@@ -1,32 +1,36 @@
|
|
1
1
|
私は数年前からReactについて意識しており、実際にReactに関する書物などを購入してHello Worldの実装も行なったことがあるのですが、どうもReactは癖が強い気がしていまして(JSXなど)今までテンプレートエンジンを利用してウェブサイトを作成していた自分には、Reactの素晴らしさがまだ実感できていません。
|
2
2
|
|
3
|
-
私が
|
3
|
+
私がこれらデータバインディング系(またはWebコンポーネント化系?)モジュールに初めて触れたのはKnockout.jsが切っ掛けになるのですが、Knockout.jsを利用することで複雑なDOM操作から解放されたときは本当に感動しました。
|
4
4
|
|
5
5
|
しかし、それらのモジュールを使いこなしていく過程でより複雑なことをしようとすると、どう実装すれば良いかわからないことがあり、ドキュメントを何度も読み返して悪戦苦闘することがありました。(Knockout.jsならではの苦闘かもしれませんが)
|
6
6
|
|
7
|
-
時々jQueryでいいんじゃないの?と、思うこともありつつ、なんとか実装を終えて一息ついたところでプロジェクトから離れるわけですが、残念なことに再び戻ってきて自分の書いたコードを見て見ると、コードが複雑すぎてよくわからない状態
|
7
|
+
時々jQueryでいいんじゃないの?と、思うこともありつつ、なんとか実装を終えて一息ついたところでプロジェクトから離れるわけですが、残念なことに再び戻ってきて自分の書いたコードを見て見ると、コードが複雑すぎてよくわからない状態が起こり、基本に立ち返って勉強をし直すといったことがありました。
|
8
8
|
|
9
9
|
もちろんこれは、自分の書いたコードが汚いということもあると思いますがこれらモジュールの学習コストが高いのも事実だと思います。
|
10
10
|
|
11
11
|
そんな痛い経験をしつつも、総合的にデータバインディング系(またはWebコンポーネント化系?)モジュールは便利であると思っているのですが、どうにも単純明快なモジュールが少ないように思います。
|
12
12
|
|
13
|
-
個人的にVue.jsはとてもシンプルだなと思ってい
|
13
|
+
個人的にVue.jsはとてもシンプルだなと思っており今最も関心を持っていたりするのですが、新しいモジュールが登場したり、従来のモジュールにおいてもアップデートが頻繁に行われたりなど、モジュールの進化が速いこともあり、未だに安心して使えるものが見つかっていません。
|
14
14
|
|
15
|
-
そもそも、自分がこれらのモジュールに興味を持ったのはサーバサイドレンダリングに魅力を感じたからです
|
15
|
+
そもそも、自分がこれらのモジュールに興味を持ったのはサーバサイドレンダリングに魅力を感じたからです。もし、これから作るプロジェクトはSPAで作ると初めから定めることができるのであれば、あまり気にしなくて良いことなのかもしれませんが、実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。
|
16
16
|
|
17
|
-
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトを読み込ませて何でもかんでもJSでやろうとする新しい考え方が、古いWeb技術と比較した時にギャップが多大なために色々なことに悩まされるといった状態から解放されると思った
|
17
|
+
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトを読み込ませて何でもかんでもJSでやろうとする新しい考え方が、古いWeb技術と比較した時にギャップが多大なために色々なことに悩まされるといった状態から解放されるとも思ったため、サーバサイドレンダリングに関心を持って今まで追ってきました。
|
18
18
|
|
19
19
|
ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQueryの必要性を奪い、Ajaxは代わりにfetchを利用するなど、新しいスタイルで開発することを余儀なくされる点も含まれていると思います。
|
20
20
|
|
21
|
-
|
21
|
+
また、jQueryのような原始的なDOM操作がどうしても必要になってくる場面というものがあるような気がしていて、例えばUXをより良いものにするために画面全体に暗転用のDIVを貼り付けてロードサークルを表示させたり、touchmoveを制御してスマートフォンで一時的にスクロール操作を禁止するといった、jQueryを使って今まで行っていたトリッキー制御がReactやjQueryを使わずに簡単に実装できるのかわかりません。
|
22
22
|
|
23
|
-
|
23
|
+
jQueryは確かに古い技術なのかもしれませんが、シンプルなセレクタとメソッド、そして豊富なプラグインを提供してくれるjQueryは素晴らしいものであると私は今でも思っています。(容量が気になりますが)
|
24
24
|
|
25
|
-
し
|
25
|
+
そこで色々と考えた結果、jQuery環境を残しつつ、サーバサイドレンダリングが行える環境を実現できれば良いと思い、独自のモジュールを作ったりもしました。その独自モジュールはnodeで実装されており、従来の良くあるテンプレートエンジンを利用したHTML出力に加え、サーバサイドのテンプレートの一部をクライアントサイドに送りつけて特定の範囲をクライアントサイドで再レンダリングできるというものです。
|
26
26
|
|
27
|
+
サーバサイドのテンプレートをクライアントサイドでも利用できれば事足りることが多かったため、個人的にこの方法はうまくいきました!つまりReactのような大げさなものはいらない..と。
|
28
|
+
|
29
|
+
しかしこの独自モジュールはアプローチが異なり、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成することはできないため、もしもプロジェクトが大きくなっていってコンポーネントの必要性に迫られた時には恐らく困ってしまうんだと思います。
|
30
|
+
|
27
31
|
(話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか..もちろん、データバインディング機能込みで初めてサーバサイドレンダリングといえるのかもしれませんが..)
|
28
32
|
|
29
|
-
そういった意味でやはり独自のものは使わず、なるべくメジャーなモジュールを使いたい...そう思っているのですが、どうにも多すぎやしませんか?今日、Riot.jsというものの存在を知ってもう意味わからんと思ってます。
|
33
|
+
そういった意味でやはり独自のものは使わず、なるべくメジャーなモジュールを使いたい...そう常日頃思っているのですが、どうにも多すぎやしませんか?今日、Riot.jsというものの存在を知ってもう意味わからんと思ってます。
|
30
34
|
|
31
35
|
これら独立したモジュールに対し、それぞれ互換性の異なるコンポーネントがたくさん作られているんですよね...?そう考えると心底ゾッとします。
|
32
36
|
|
@@ -34,8 +38,10 @@
|
|
34
38
|
|
35
39
|
しかも、Web componentsはReactやVueに比べてより低レベルなコンポーネントの実装ができるわけです。
|
36
40
|
|
37
|
-
コンポーネントとしてはやはりより低レベルな実装の方が良いわけで、
|
41
|
+
そこでふと思ったのですが、コンポーネントとしてはやはりより低レベルな実装の方が良いわけで、このまま主要ブラウザのWeb componentsの実装が進むにつれて、ReactやVueで作られたコンポーネントはWeb componentsで作り直され、デベロッパーの意識がWeb componentsに集約することによってReactやVueといったデータバインディング系(またはWebコンポーネント化系?)のモジュールは不要なものになってしまうのではないでしょうか?
|
38
42
|
|
39
|
-
|
43
|
+
そう考えていたら、ただでさえどれを使えば良いか迷っている中、怖くてこれらのモジュールを導入することが本当に正しいのかわからなくなってしまいました。
|
40
44
|
|
45
|
+
もし、ReactやVueなどで作られたコンポーネントがこの標準のコンポーネントと互換性を持たないのであれば、Web componentsはこれらデータバインディング系(またはWebコンポーネント化系?)モジュールに破壊的な打撃を与えることになると思っているのですが、皆様はどう思われますか?
|
46
|
+
|
41
|
-
|
47
|
+
意見をお待ちしております。
|
11
title
CHANGED
File without changes
|
body
CHANGED
File without changes
|
10
title
CHANGED
File without changes
|
body
CHANGED
@@ -36,6 +36,6 @@
|
|
36
36
|
|
37
37
|
コンポーネントとしてはやはりより低レベルな実装の方が良いわけで、もしWeb componentsの実装が進んだら、ReactやVueはいらない子になってしまうのではないでしょうか?
|
38
38
|
|
39
|
-
もし、ReactやVueなどで作られたコンポーネントがこの標準のコンポーネントと互換性を持たないのであれば、Web componentsはこれらデータバインディング系(またはWebコンポーネント化系?)モジュール
|
39
|
+
もし、ReactやVueなどで作られたコンポーネントがこの標準のコンポーネントと互換性を持たないのであれば、Web componentsはこれらデータバインディング系(またはWebコンポーネント化系?)モジュールに破壊的な打撃を与えることになるのではないでしょうか?
|
40
40
|
|
41
41
|
皆様の意見をお待ちしております。
|
9
title
CHANGED
File without changes
|
body
CHANGED
File without changes
|
8
title
CHANGED
File without changes
|
body
CHANGED
@@ -4,32 +4,38 @@
|
|
4
4
|
|
5
5
|
しかし、それらのモジュールを使いこなしていく過程でより複雑なことをしようとすると、どう実装すれば良いかわからないことがあり、ドキュメントを何度も読み返して悪戦苦闘することがありました。(Knockout.jsならではの苦闘かもしれませんが)
|
6
6
|
|
7
|
-
時々jQueryでいいんじゃないの?と、思うこともありつつ、なんとか実装を終えて一息ついたところでプロジェクトから離れるわけですが、残念なことに再び戻ってきて自分の書いたコードを見て見ると、コードが複雑すぎてよくわからない状態にな
|
7
|
+
時々jQueryでいいんじゃないの?と、思うこともありつつ、なんとか実装を終えて一息ついたところでプロジェクトから離れるわけですが、残念なことに再び戻ってきて自分の書いたコードを見て見ると、コードが複雑すぎてよくわからない状態になり、基本に立ち返って勉強をし直すといったことがありました。
|
8
8
|
|
9
9
|
もちろんこれは、自分の書いたコードが汚いということもあると思いますがこれらモジュールの学習コストが高いのも事実だと思います。
|
10
10
|
|
11
|
-
そんな痛い経験をしつつも、総合的にデータバインディング系(またはWebコンポーネント化系?)
|
11
|
+
そんな痛い経験をしつつも、総合的にデータバインディング系(またはWebコンポーネント化系?)モジュールは便利であると思っているのですが、どうにも単純明快なモジュールが少ないように思います。
|
12
12
|
|
13
|
-
個人的にVue.jsはとてもシンプルだなと思っていますが、アップデートが頻繁に行われることも多く、未だにデータバインディング系(またはWebコンポーネント化系?)モジュールで「これだ!」と思うものが見つかっていません。
|
13
|
+
個人的にVue.jsはとてもシンプルだなと思っていますが、そのほかのモジュールも含め、アップデートが頻繁に行われることも多く、未だにデータバインディング系(またはWebコンポーネント化系?)モジュールで「これだ!」と思うものが見つかっていません。
|
14
14
|
|
15
|
-
そもそも、自分がこれらのモジュールに興味を持ったのはサーバサイドレンダリングに魅力を感じたからです(Knockout.jsにはサーバサイドレンダリング機能はありませんが)。SPAで確定できるのであれば気にしなくて良いことなのかもしれませんが、やはり実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。
|
15
|
+
そもそも、自分がこれらのモジュールに興味を持ったのはサーバサイドレンダリングに魅力を感じたからです(Knockout.jsにはサーバサイドレンダリング機能はありませんが)。もしこのプロジェクトはSPAで作ると確定できるのであれば気にしなくて良いことなのかもしれませんが、やはり実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。
|
16
16
|
|
17
|
-
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトを読み込ませて何でもかんでもJSでやろうとする新しい考え方が、古いWeb技術と比較した時にギャップが多大なために色々なことに悩まされるといった状態から解放されると思ったこともあり、サーバサイドレンダリング
|
17
|
+
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトを読み込ませて何でもかんでもJSでやろうとする新しい考え方が、古いWeb技術と比較した時にギャップが多大なために色々なことに悩まされるといった状態から解放されると思ったこともあり、サーバサイドレンダリングを追ってきました。
|
18
18
|
|
19
19
|
ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQueryの必要性を奪い、Ajaxは代わりにfetchを利用するなど、新しいスタイルで開発することを余儀なくされる点も含まれていると思います。
|
20
20
|
|
21
21
|
そこで色々考えた結果、単純かつプラグイン豊富なjQuery環境を残しつつ、サーバサイドレンダリングが行える環境を実現できれば良いと思い、独自のモジュールを作ったりもしました。その独自モジュールはnodeで実装されており、従来の良くあるテンプレートエンジンを利用したHTML出力に加え、サーバサイドのテンプレートの一部をクライアントサイドに送りつけて特定の範囲をクライアントサイドで再レンダリングできるというものです。
|
22
22
|
|
23
|
-
個人的にはサーバサイド
|
23
|
+
個人的にはサーバサイドのテンプレートをクライアントサイドでも利用できれば良いことが多かったため、この方法はうまくいきました。つまりReactのような大げさなものはいらない..と。
|
24
24
|
|
25
25
|
しかしこの独自モジュールはアプローチが異なるため、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成することはできないため、もしもプロジェクトが大きくなっていってコンポーネントの必要性に迫られた時には恐らく困ってしまうんだと思います。
|
26
26
|
|
27
|
-
(話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか)
|
27
|
+
(話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか..もちろん、データバインディング機能込みで初めてサーバサイドレンダリングといえるのかもしれませんが..)
|
28
28
|
|
29
29
|
そういった意味でやはり独自のものは使わず、なるべくメジャーなモジュールを使いたい...そう思っているのですが、どうにも多すぎやしませんか?今日、Riot.jsというものの存在を知ってもう意味わからんと思ってます。
|
30
30
|
|
31
|
-
これら独立したモジュールに対し、それぞれ互換性の異なるコンポーネントがたくさん作られているんですよね...?そう考えるとゾッとします。
|
31
|
+
これら独立したモジュールに対し、それぞれ互換性の異なるコンポーネントがたくさん作られているんですよね...?そう考えると心底ゾッとします。
|
32
32
|
|
33
|
-
|
33
|
+
さらには、ブラウザ標準搭載予定のWeb Componentsの実装が進んでるというカオスっぷり。
|
34
34
|
|
35
|
+
しかも、Web componentsはReactやVueに比べてより低レベルなコンポーネントの実装ができるわけです。
|
36
|
+
|
35
|
-
|
37
|
+
コンポーネントとしてはやはりより低レベルな実装の方が良いわけで、もしWeb componentsの実装が進んだら、ReactやVueはいらない子になってしまうのではないでしょうか?
|
38
|
+
|
39
|
+
もし、ReactやVueなどで作られたコンポーネントがこの標準のコンポーネントと互換性を持たないのであれば、Web componentsはこれらデータバインディング系(またはWebコンポーネント化系?)モジュールは、破壊的な打撃を受けることになるのではないでしょうか?
|
40
|
+
|
41
|
+
皆様の意見をお待ちしております。
|
7
title
CHANGED
File without changes
|
body
CHANGED
@@ -2,24 +2,26 @@
|
|
2
2
|
|
3
3
|
私が初めてこれらデータバインディング系(またはWebコンポーネント化系?)モジュールに触れたのはKnockout.jsなのですが、Knockout.jsを利用することで複雑なDOM操作から解放されたときは本当に感動しました。
|
4
4
|
|
5
|
-
しかし、それらのモジュールを使いこなしていく過程でより複雑なことをしようとすると、どう実装すれば良いかわから
|
5
|
+
しかし、それらのモジュールを使いこなしていく過程でより複雑なことをしようとすると、どう実装すれば良いかわからないことがあり、ドキュメントを何度も読み返して悪戦苦闘することがありました。(Knockout.jsならではの苦闘かもしれませんが)
|
6
6
|
|
7
|
-
|
7
|
+
時々jQueryでいいんじゃないの?と、思うこともありつつ、なんとか実装を終えて一息ついたところでプロジェクトから離れるわけですが、残念なことに再び戻ってきて自分の書いたコードを見て見ると、コードが複雑すぎてよくわからない状態になるということがあり、基本に立ち返って勉強をし直すといったことがありました。
|
8
8
|
|
9
|
-
|
9
|
+
もちろんこれは、自分の書いたコードが汚いということもあると思いますがこれらモジュールの学習コストが高いのも事実だと思います。
|
10
10
|
|
11
|
-
|
11
|
+
そんな痛い経験をしつつも、総合的にデータバインディング系(またはWebコンポーネント化系?)もは便利であると思っているのですが、どうにも単純明快なものが少ないように思います。
|
12
12
|
|
13
|
-
|
13
|
+
個人的にVue.jsはとてもシンプルだなと思っていますが、アップデートが頻繁に行われることも多く、未だにデータバインディング系(またはWebコンポーネント化系?)モジュールで「これだ!」と思うものが見つかっていません。
|
14
14
|
|
15
|
-
そのた
|
15
|
+
そもそも、自分がこれらのモジュールに興味を持ったのはサーバサイドレンダリングに魅力を感じたからです(Knockout.jsにはサーバサイドレンダリング機能はありませんが)。SPAで確定できるのであれば気にしなくて良いことなのかもしれませんが、やはり実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。
|
16
16
|
|
17
|
-
た
|
17
|
+
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトを読み込ませて何でもかんでもJSでやろうとする新しい考え方が、古いWeb技術と比較した時にギャップが多大なために色々なことに悩まされるといった状態から解放されると思ったこともあり、サーバサイドレンダリングについて調べることが多かったです。
|
18
18
|
|
19
|
-
|
19
|
+
ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQueryの必要性を奪い、Ajaxは代わりにfetchを利用するなど、新しいスタイルで開発することを余儀なくされる点も含まれていると思います。
|
20
20
|
|
21
|
-
|
21
|
+
そこで色々考えた結果、単純かつプラグイン豊富なjQuery環境を残しつつ、サーバサイドレンダリングが行える環境を実現できれば良いと思い、独自のモジュールを作ったりもしました。その独自モジュールはnodeで実装されており、従来の良くあるテンプレートエンジンを利用したHTML出力に加え、サーバサイドのテンプレートの一部をクライアントサイドに送りつけて特定の範囲をクライアントサイドで再レンダリングできるというものです。
|
22
22
|
|
23
|
+
個人的にはサーバサイドでよく行なっていたテンプレートを利用したHTML出力をクライアントサイドでも再び実行できればよかったので、この方法はうまくいきました。つまりReactのような大げさなものはいらない..と。
|
24
|
+
|
23
25
|
しかしこの独自モジュールはアプローチが異なるため、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成することはできないため、もしもプロジェクトが大きくなっていってコンポーネントの必要性に迫られた時には恐らく困ってしまうんだと思います。
|
24
26
|
|
25
27
|
(話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか)
|
6
title
CHANGED
File without changes
|
body
CHANGED
@@ -1,28 +1,33 @@
|
|
1
|
-
数年前からReactについて意識し、実際にReactに関する書物を購入してHello Worldの実装
|
1
|
+
私は数年前からReactについて意識しており、実際にReactに関する書物などを購入してHello Worldの実装も行なったことがあるのですが、どうもReactは癖が強い気がしていまして(JSXなど)今までテンプレートエンジンを利用してウェブサイトを作成していた自分には、Reactの素晴らしさがまだ実感できていません。
|
2
2
|
|
3
|
-
|
3
|
+
私が初めてこれらデータバインディング系(またはWebコンポーネント化系?)モジュールに触れたのはKnockout.jsなのですが、Knockout.jsを利用することで複雑なDOM操作から解放されたときは本当に感動しました。
|
4
4
|
|
5
|
-
|
5
|
+
しかし、それらのモジュールを使いこなしていく過程でより複雑なことをしようとすると、どう実装すれば良いかわからず、ドキュメントを何度も読み返して悪戦苦闘することがありました。(Knockout.jsならではの苦闘かもしれませんが)
|
6
6
|
|
7
|
+
しかし、なんとか実装を終えて一息ついたところでプロジェクトから離れ、それから再び戻ってきて自分の書いたコードを見て見ると、コードが複雑すぎてよくわからない状態になるということもあり(もちろん自分のコードが汚いだけかもしれませんが学習コストが高いのも事実だと思っています)基本に立ち返って勉強をし直すといったことがありました。
|
8
|
+
|
9
|
+
そんな痛い経験をしつつも、総合的にデータバインディング系(またはWebコンポーネント化系?)は便利であると思っているのですが、どうにも単純明快なものが少ないように思います。
|
10
|
+
|
7
11
|
個人的にVue.jsはとてもシンプルだなと思っていますが、まだ利用するかどうか悩んでいるところです。
|
8
12
|
|
9
|
-
そもそも、自分がこれらのモジュールを
|
13
|
+
そもそも、自分がこれらのモジュールに興味を持ったのはサーバサイドレンダリングに魅力を感じたからです(Knockout.jsにはサーバサイドレンダリング機能はありませんが)。SPAで良いのであれば気にしなくて良いことなのかもしれませんが、やはり実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。
|
10
14
|
|
11
|
-
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトを
|
12
|
-
(要するに安心が欲しい)
|
15
|
+
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトを読み込ませて何でもかんでもJSでやろうとする新しい考え方が、古いWeb技術と比較した時にギャップが多大なために色々なことに悩まされるといった状態から解放されると思ったからです。
|
13
16
|
|
14
|
-
ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQuery
|
17
|
+
ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQueryの必要性を奪い、Ajaxは代わりにfetchを利用するなど、新しい方法で開発することを余儀なくされる点も含まれていると思います。
|
15
18
|
|
16
|
-
そこで色々考えた結果、jQuery環境を残しつつサーバサイドレンダリングが行える環境を実現するため、独自モジュールを作ったりもしました。その独自モジュールは従来の良くあるテンプレートエンジンを利用したHTML出力なのですが、HTMLにサーバサイドで利用したテンプレートの一部をキャッシュさせクライアントサイドで特定の範囲を再レンダリングできるというものです。
|
19
|
+
そこで色々考えた結果、プラグイン豊富で単純なjQuery環境を残しつつ、サーバサイドレンダリングが行える環境を実現するため、独自モジュールを作ったりもしました。その独自モジュールは従来の良くあるテンプレートエンジンを利用したHTML出力なのですが、HTMLにサーバサイドで利用したテンプレートの一部をキャッシュさせクライアントサイドで特定の範囲を再レンダリングできるというものです。
|
17
20
|
|
18
|
-
個人的にはサーバサイドで行なっていたテンプレートを利用したHTML出力をクライアントサイドでも
|
21
|
+
個人的にはサーバサイドでよく行なっていたテンプレートを利用したHTML出力をクライアントサイドでも再び実行できればよかったので、今のところこの独自モジュールで満足することが多いです。つまりReactのような大げさなものはいらない..と。
|
19
22
|
|
20
|
-
しかしこの独自モジュールはアプローチが異なるため、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成する
|
23
|
+
しかしこの独自モジュールはアプローチが異なるため、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成することはできないため、もしもプロジェクトが大きくなっていってコンポーネントの必要性に迫られた時には恐らく困ってしまうんだと思います。
|
21
24
|
|
22
25
|
(話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか)
|
23
26
|
|
24
|
-
そういった意味で
|
27
|
+
そういった意味でやはり独自のものは使わず、なるべくメジャーなモジュールを使いたい...そう思っているのですが、どうにも多すぎやしませんか?今日、Riot.jsというものの存在を知ってもう意味わからんと思ってます。
|
25
28
|
|
26
|
-
|
29
|
+
これら独立したモジュールに対し、それぞれ互換性の異なるコンポーネントがたくさん作られているんですよね...?そう考えるとゾッとします。
|
27
30
|
|
31
|
+
そこで、さらにブラウザ標準搭載予定のWeb Componentsの実装が着実に進んでるというカオスっぷりな訳ですが、より低レベルなWeb Componentsの実装が進んだら、コンポーネントとしてはやはりブラウザ標準ものの方が良いわけで、ReactやVueなどで作られたコンポーネントはこの標準のコンポーネントと互換性を持たないと勝手に思っているのですが実際どうなのでしょうか?
|
32
|
+
|
28
33
|
主要ブラウザのWeb Componentsの実装が進むにつれてReactやVueなどはいらない子になってしまうのでしょうか?
|
5
文章を修正
title
CHANGED
File without changes
|
body
CHANGED
@@ -1,23 +1,23 @@
|
|
1
1
|
数年前からReactについて意識し、実際にReactに関する書物を購入してHello Worldの実装なども行なっていたのですが、どうもReactは癖が強い気がして(JSXなど)今までテンプレートエンジンを利用してウェブサイトを作成していた自分には、Reactの素晴らしさがまだ実感できていません。
|
2
2
|
|
3
|
-
Knockout.jsなども試したのですが、複雑なことをしようとするとどう書いて良いか分からず、ドキュメントを何度も読み返してなんとか実装
|
3
|
+
Knockout.jsなども試したのですが、複雑なことをしようとするとどう書いて良いか分からず、ドキュメントを何度も読み返してなんとか実装し、データバインディングの利便性を体感しました。しかし、プロジェクトから離れて再度戻ってみるとコードが複雑すぎてよくわからない状態になって勉強をし直すといったことがありました。
|
4
4
|
|
5
5
|
どうにも最近よくあるデータバインディング系(またはWebコンポーネント化系?)のモジュールは単純明快なものが少ないように思います。
|
6
6
|
|
7
7
|
個人的にVue.jsはとてもシンプルだなと思っていますが、まだ利用するかどうか悩んでいるところです。
|
8
8
|
|
9
|
-
そもそも、自分がこれらのモジュールを利用しようとした理由はサーバサイドレンダリングに魅力を感じたからです。SPAであれば気にしなくて良いことなのかもしれませんが、やはり実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。
|
9
|
+
そもそも、自分がこれらのモジュールを利用しようとした理由はサーバサイドレンダリングに魅力を感じたからです(Knockout.jsにはサーバサイドレンダリング機能はありませんが)。SPAであれば気にしなくて良いことなのかもしれませんが、やはり実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。
|
10
10
|
|
11
|
-
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトをロードさせて何でもかんでもJSでやろうとする新しい考え方が古いWeb技術とのギャップが大きすぎるためになんとなく不安になるという状態
|
11
|
+
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトをロードさせて何でもかんでもJSでやろうとする新しい考え方が古いWeb技術とのギャップが大きすぎるためになんとなく不安になるという状態を避けることができると思ったからです。
|
12
12
|
(要するに安心が欲しい)
|
13
13
|
|
14
14
|
ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQueryを使う必要がなくなりAjaxについてはfetchを利用するというような新しい方法で開発することを余儀なくされる点も含まれていると思います。
|
15
15
|
|
16
|
-
そこで色々考えた結果、
|
16
|
+
そこで色々考えた結果、jQuery環境を残しつつサーバサイドレンダリングが行える環境を実現するため、独自モジュールを作ったりもしました。その独自モジュールは従来の良くあるテンプレートエンジンを利用したHTML出力なのですが、HTMLにサーバサイドで利用したテンプレートの一部をキャッシュさせクライアントサイドで特定の範囲を再レンダリングできるというものです。
|
17
17
|
|
18
|
-
個人的にはサーバサイドで行なっていたテンプレートを利用したHTML出力をクライアントサイドでもUI更新のタイミングでもう一度行いたいだけだったので、今のところこの独自モジュールで満足していたりします。Reactな
|
18
|
+
個人的にはサーバサイドで行なっていたテンプレートを利用したHTML出力をクライアントサイドでもUI更新のタイミングでもう一度行いたいだけだったので、今のところこの独自モジュールで小さなプロジェクトでは満足していたりします。Reactのような大げさなものはいらない..と。
|
19
19
|
|
20
|
-
しかしこの独自モジュールはアプローチが異なるため、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成するためのものではないため、コンポーネントの必要性に迫られた時には困ってしまうんだと思います。
|
20
|
+
しかしこの独自モジュールはアプローチが異なるため、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成するためのものではないため、もしもプロジェクトが大きくなっていってコンポーネントの必要性に迫られた時には困ってしまうんだと思います。
|
21
21
|
|
22
22
|
(話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか)
|
23
23
|
|
4
文章を短縮
title
CHANGED
File without changes
|
body
CHANGED
@@ -13,16 +13,16 @@
|
|
13
13
|
|
14
14
|
ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQueryを使う必要がなくなりAjaxについてはfetchを利用するというような新しい方法で開発することを余儀なくされる点も含まれていると思います。
|
15
15
|
|
16
|
-
そこで色々考えた結果、それらのモジュールを利用せずに自分でモジュールを作
|
16
|
+
そこで色々考えた結果、それらのモジュールを利用せずに自分でモジュールを作ったりもしました。その独自モジュールは従来の良くあるテンプレートエンジンを利用したHTML出力なのですが、HTMLにサーバサイドで利用したテンプレートの一部をキャッシュさせクライアントサイドで特定の範囲を再レンダリングできるというものです。
|
17
17
|
|
18
|
-
個人的にはサーバサイドで行なっていたテンプレートを利用したHTML出力をクライアントサイドでもUI更新のタイミングでもう一度行いたいだけだったので、今のところこの独自モジュールで満足していたりします。Reactなんて大げさなものはいらない..と。
|
18
|
+
個人的にはサーバサイドで行なっていたテンプレートを利用したHTML出力をクライアントサイドでもUI更新のタイミングでもう一度行いたいだけだったので、今のところこの独自モジュールで満足していたりします。Reactなんて大げさなものはいらない..と。
|
19
19
|
|
20
|
+
しかしこの独自モジュールはアプローチが異なるため、データバインディング系(またはWebコンポーネント化系?)のツールとは違ってコンポーネントを作成するためのものではないため、コンポーネントの必要性に迫られた時には困ってしまうんだと思います。
|
21
|
+
|
20
22
|
(話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか)
|
21
23
|
|
22
|
-
|
24
|
+
そういった意味ではやはり独自のものは使わず、なるべくメジャーなモジュールを使いたい...そう思っているのですが、どうにも多すぎやしませんか?今日、Riot.jsというものの存在を知ってもう意味わからんと思ってます。これら独立したモジュールに対してそれぞれ互換性のないコンポーネントがたくさん作られているんですよね...?ちょっとゾッとします。
|
23
25
|
|
24
|
-
やはり独自のものは使わず、なるべくメジャーなモジュールを使いたい...そう思っているのですが、どうにも多すぎやしませんか?今日、Riot.jsというものの存在を知ってもう意味わからんと思ってます。これら独立したモジュールに対してそれぞれ互換性のないコンポーネントがたくさん作られているんですよね...?ちょっとゾッとします。
|
25
|
-
|
26
26
|
そこで、Web Componentsの実装が着実に進んでる(かどうか知りませんがw)ようで、ふと思ったんですが、Web Componentsが実装されたらコンポーネントとしてはやはりブラウザ標準ものの方が良いわけで、ReactやVueなどで作られたコンポーネントは互換性を持たないと勝手に思っているのですが実際どうなのでしょうか?
|
27
27
|
|
28
28
|
主要ブラウザのWeb Componentsの実装が進むにつれてReactやVueなどはいらない子になってしまうのでしょうか?
|
3
修正
title
CHANGED
File without changes
|
body
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
数年前からReactについて意識し、実際にReactに関する書物を購入してHello Worldの実装なども行なっていたのですが、どうもReactは癖が強い気がして(JSXなど)今までテンプレートエンジンを利用してウェブサイトを作成していた自分には、Reactの素晴らしさがまだ実感できていません。
|
2
2
|
|
3
|
-
Knockout.jsなども試したのですが、複雑なことをしようとするとどう書いて良いか分からず、ドキュメントを何度も読み返してなんとか実装できたのですが、ふとプロジェクトから離れて再度戻ってみるとコードが複雑すぎてよくわからない状態になって勉強をし直すといったことがありました。
|
3
|
+
Knockout.jsなども試したのですが、複雑なことをしようとするとどう書いて良いか分からず、ドキュメントを何度も読み返してなんとか実装できました。それで、Knockout.jsすごい便利だ!とも思ったのですが、ふとプロジェクトから離れて再度戻ってみるとコードが複雑すぎてよくわからない状態になって勉強をし直すといったことがありました。
|
4
4
|
|
5
5
|
どうにも最近よくあるデータバインディング系(またはWebコンポーネント化系?)のモジュールは単純明快なものが少ないように思います。
|
6
6
|
|
@@ -8,16 +8,16 @@
|
|
8
8
|
|
9
9
|
そもそも、自分がこれらのモジュールを利用しようとした理由はサーバサイドレンダリングに魅力を感じたからです。SPAであれば気にしなくて良いことなのかもしれませんが、やはり実際に仕事としてウェブサービスを構築するとなるとSEOについて議題になることが多く、後から対応するようなことが経験上多かったのです。
|
10
10
|
|
11
|
-
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトをロードさせて何でもかんでもJSでやろうとする新しい考え方が古いWeb技術とのギャップが大きすぎるためになんとなく不安になる状態から
|
11
|
+
そのため、サーバサイドレンダリングの技術を身につけておけば、SPAで作っていたサービスを後からSEOについて色々言われて破綻するというようなことを避けることができるし(これは初めからSPAで作らないということですが)、コンテンツの含まれないサイトをロードさせて何でもかんでもJSでやろうとする新しい考え方が古いWeb技術とのギャップが大きすぎるためになんとなく不安になるという状態から逃げることができると思ったからです。
|
12
12
|
(要するに安心が欲しい)
|
13
13
|
|
14
14
|
ただ、これらのデータバインディング系(またはWebコンポーネント化系?)のモジュールは開発環境を劇的に変化させてしまうことが多く、jQueryを使う必要がなくなりAjaxについてはfetchを利用するというような新しい方法で開発することを余儀なくされる点も含まれていると思います。
|
15
15
|
|
16
16
|
そこで色々考えた結果、それらのモジュールを利用せずに自分でモジュールを作ることにしてみました。その独自モジュールは従来の良くあるテンプレートエンジンを利用したHTML出力なのですが、HTMLにサーバサイドで利用したテンプレートの一部をキャッシュさせクライアントサイドで特定の範囲を再レンダリングできるというものです。
|
17
17
|
|
18
|
-
個人的にはサーバサイドで行なっていたテンプレートを利用したHTML出力をクライアントサイドで行いたいだけだったので、今のところこの独自モジュールで満足していたりします。もちろん
|
18
|
+
個人的にはサーバサイドで行なっていたテンプレートを利用したHTML出力をクライアントサイドでもUI更新のタイミングでもう一度行いたいだけだったので、今のところこの独自モジュールで満足していたりします。Reactなんて大げさなものはいらない..と。もちろんこれはモデルを更新したら自動的にUIが更新されるわけではないので、ReactやKnockoutやVueやAangularなどに比べたら面倒なものですが単純なテンプレートであることから、わかりやすさを実感しています。
|
19
19
|
|
20
|
-
(
|
20
|
+
(話は逸れますが、サーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか)
|
21
21
|
|
22
22
|
もちろんこの独自モジュールはアプローチが違うため、データバインディング系(またはWebコンポーネント化系?)のツールとは異なりコンポーネントを作成するためのものではないため、コンポーネントの必要性に迫られた時にはこの独自モジュールでは力不足になると思っています。
|
23
23
|
|
2
訂正
title
CHANGED
File without changes
|
body
CHANGED
@@ -15,7 +15,7 @@
|
|
15
15
|
|
16
16
|
そこで色々考えた結果、それらのモジュールを利用せずに自分でモジュールを作ることにしてみました。その独自モジュールは従来の良くあるテンプレートエンジンを利用したHTML出力なのですが、HTMLにサーバサイドで利用したテンプレートの一部をキャッシュさせクライアントサイドで特定の範囲を再レンダリングできるというものです。
|
17
17
|
|
18
|
-
個人的にはサーバサイドで行なっていたテンプレート
|
18
|
+
個人的にはサーバサイドで行なっていたテンプレートを利用したHTML出力をクライアントサイドで行いたいだけだったので、今のところこの独自モジュールで満足していたりします。もちろん、モデルを更新したら自動的にUIが更新されるわけではないので、ReactやKnockoutやVueやAangularなどに比べたら面倒なのかもしれませんがただのテンプレートなのでわかりやすいと実感しています。
|
19
19
|
|
20
20
|
(そもそもサーバサイドレンダリングって言葉面白いですよね?テンプレートエンジンを利用したHTML出力って実はサーバサイドレンダリングじゃないですか。これってSPAが流行ったためにあたかも古い技術が新しい技術のように名前を変えて誕生したみたいに思っているんですが僕だけでしょうか)
|
21
21
|
|
1
訂正
title
CHANGED
File without changes
|
body
CHANGED
@@ -23,6 +23,6 @@
|
|
23
23
|
|
24
24
|
やはり独自のものは使わず、なるべくメジャーなモジュールを使いたい...そう思っているのですが、どうにも多すぎやしませんか?今日、Riot.jsというものの存在を知ってもう意味わからんと思ってます。これら独立したモジュールに対してそれぞれ互換性のないコンポーネントがたくさん作られているんですよね...?ちょっとゾッとします。
|
25
25
|
|
26
|
-
そこで、Web Componentsの実装が着実に進んでる(かどうか知りませんがw)ようで、ふと思ったんですが、Web Componentsが実装されたらコンポーネントとしてはやはりブラウザ標準ものの方が良いわけで、ReactやVueなどで作られたコンポーネントは互換性を持たな
|
26
|
+
そこで、Web Componentsの実装が着実に進んでる(かどうか知りませんがw)ようで、ふと思ったんですが、Web Componentsが実装されたらコンポーネントとしてはやはりブラウザ標準ものの方が良いわけで、ReactやVueなどで作られたコンポーネントは互換性を持たないと勝手に思っているのですが実際どうなのでしょうか?
|
27
27
|
|
28
28
|
主要ブラウザのWeb Componentsの実装が進むにつれてReactやVueなどはいらない子になってしまうのでしょうか?
|