Vue vs React vs Angular YouTube動画>1本 ->画像>8枚

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/

---

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

使いやすさのVue
先進性のReact
引くに引けない人とIonic派だけが使うAngular

Reactってそんなに先進的かねぇ
考え方的にはVueの単一ファイルコンポーネントと同じようなものだと思うけど

覚えてしまえば
どれも似たようなもん

vueとかネットで騒がれてる
わりには、文法が難しくて取っ掛かりに
時間がかかるんだが！！！個人でVSコードの
デバッグやwebpackの
設定をやるとなると、手間が掛かりすぎるのも原因の
一つかな。色々とファイルを配置するのに、時間とpcのスペックを
費やすから手軽さにかける。
simple & bestの虎の巻きでもあればいいけど
個人がこの言語を公にすればいいのに、趣味や趣向が入りすぎて
「誰も特しない言語」になってる

なってない。vueは言語じゃないから。

>>5
翻訳すると、「わたしバカですー」ってことか

Laravelで使うかLaravel-Mixを移植して使うのがベターだと思う

Nuxtのおベンベン始めたけど、メンドクサー
PHPのゴミのようなフレームワークと一緒で、学習コストかかりすぎ

Reactはどうなん？
Vueやめよっかなー

2018年 は 脱React の年だった。 オワコン React
http://2chb.net/r/hp/1545879649/

>>9
nuxtはreactとangularに比べるとシンプルで分かりやすいほうだぞ
これダメなら他やってもダメだろな

vue自体を学ぶのは、Vue CLI 3でプロジェクトを作成した状態から始めちゃうほうが、コンポーネントとか理解しやすいなと思った。

Reactってなれないうちは一番面倒くさいんじゃないかと思うよ
vueならv-modelでできる簡易な事も結構大掛かりだし

そのVueよりも普通にHTML書いたほうが早いってなｗ

<span>Hello HTML</span>

ほらなｗ

SSRと思いついた時点で、シングルページじゃなかったことに気付いてほしかった。

SSRってレアなん？

ここでは Vue.js 対 JQuery の議論は御法度？

SPAってかっこいい単語だけど昔からはびこってるものと何ら変わらんのだよな
ASPやJSPやPHPでJSなりCSSなりイメージなり使わなければSPAなんだし

jQueryカスは来るな

来るなと言われましても、すでに捕捉済みですしｗ

基礎から学ぶ Vue.js、mio、2018/5/29

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、
花谷 拓磨、2018/10/17

Node.js超入門、掌田津耶乃、2017

Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口 将人・倉見 洋輔、2017


入門 React ――コンポーネントベースのWebフロントエンド開発、2015

Reactビギナーズガイド ――コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017
https://github.com/stoyan/reactbook

初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017

いまどきのJSプログラマーのための Node.jsとReactアプリケーション開発テクニック／クジラ飛行机
Reactの本として見るとReduxとか不足してて微妙だけどNode.jsとかWebpackの本としてはそこそこ良かったと思う

React入門 React・Reduxの導入からサーバサイドレンダリングによるUXの向上まで (NEXT ONE)／穴井宏幸、石井直矢、柴田 和祈、三宮 肇
Reduxに関してはこれが一番詳しく載ってたかな

Nuxt.jsビギナーズガイド

これ半分くらい読んだけど、PHPのフレームワークが
次々出てきてはゴミになってるけど、同じ道を辿るだけだと思ったよ

実際のサイト制作は規約でガチガチだとソースがカオスになって重くなるだけ

Vue.js, Nuxt.js, React, Electron, Android アプリなどの、
ライフサイクルメソッドは、どのアプリでも普遍的

これを時間的に進む方向を、一方向だけに限定したルールは、使いやすい

Rails と同じ。
全員が同じ規約に従った方が、作りやすいし、わかりやすい

異なったやり方・各個人独自のやり方は、わかりにくい

jsはフレームワークがどれだけ出てきても
フレームワークの介入の無いほうが汎用的に作れるようになるよ
パフォーマンスという観点だとその辺に溢れかえってるフレームワークはゴミにしかならんし

>>23
nuxtとかゆるゆるやんけ

>>25
結局便利で手軽で簡単な jQuery に回帰するという事なのかな。

jQueryもフレームワークだし
やれることはwebに動きつけるぐらいじゃん

jQueryもなくなりそうな勢いだしね

いやフレームワークではないだろ…
色々余計な機能付いてるが（そして最近は減らしていっているが）自称の通りDOM操作ライブラリだろ良くも悪くも。
怪力でノンサポートのハンドル自力で切っといてこれがパワーステアリングだ！と言ってるようなもん

>>30
jQueryはJavaScriptのフレームワークだよ

コーディングスタイルを縛るもんじゃないからどちらかと言えばクラスライブラリじゃない？

その点で行くと.NETもフレームワークと言うよりはクラスライブラリに近いけど

>>32
いや、.NETはランタイムも含んでるから

>>31
フレームワークっていうのは呼び出し側のことなので
jQueryはフレームワークに当たらない
あえて言うならブラウザそのものがフレームワーク
ブラウザがイベントを発行し、jQueryはその中を書くだけ

>>34
ｗｗｗ

>>34
呼び出し方を同じ言語で簡素化してるのがフレームワークなのだからjQueryは間違いなくフレームワークだなw

誰も簡素化の有無を焦点にしてないんだが？

全てのライブラリは簡素化するものです。
簡素化だけを条件にしてしまったら
ライブラリ全てがフレームワークってことになってしまう

フレームワークは利用者が何も書くことなく、
このような形で呼び出されるから、こういうものを用意しなさいと
決まってしまうもの。

jQueryはそんなものは決めないので、フレームワークにはならない

ここはjQueryスレじゃねえんだから出ていけ！！！！！

>>37
お前の言葉そのまんまだと
フレームワークは呼び出し側のことなのでjQueryはフレームワークに当たる
VueやreactやAngularも同じ

> フレームワークは呼び出し側のことなのでjQueryはフレームワークに当たる

え？jQueryの何処が呼び出し側に見えるの？
フレームワークは呼び出し側のことというならば、
その根拠があるはずだよね。言ってみて

jqueryがフレームワークじゃないってやばい

理由は言えないけど、やばいって言っておけば
勝てるだろう。やばいやばいやばい。どやぁ。

> 声闘(ソント)とは朝鮮人の古くからの風習で声の大きさで相手の言論を封じること。
> 人と議論をするとき、議論の内容は関係なく、ただ大声で早口で居丈高に話し、
> 相手が何も言い返せなくなれば勝ち、というしきたり。

みたいなことは止めてねｗ

jQueryバカは他でやれ！！！

http://jquery.com/

> What is jQuery?
> jQuery is a fast, small, and feature-rich JavaScript library.

公式サイトで、ライブラリって書かれてるのに
それを覆えそうとする勇気に敬服する（皮肉）

>>36
呼び出し方を同じ言語で簡素化してるのがライブラリなのだからjQueryは間違いなくライブラリだなw

オブジェクトモデルでいうなら
フレームワーク→ベースとなるクラスを継承してメソッドをオーバーライドするスタイル
クラスライブラリ→自作のクラスのメンバーなどにライブラリのクラスを導入していくスタイル

あと勘違いしないで欲しいのは別にフレームワークだから凄いとかフレームワークじゃないからヘボいとかそういうわけではないということ

だからなんでこのスレでjQueryの話してんだよボケ！！！！
テメーらクズどもは巣に帰れ！！！！！

ライフサイクルっていう概念が結構重要だよね

>>48
jQueryもフレームワークだって言ってる人がいる
ここで話しても良いのでは？（皮肉）

一部の部品として容易に組み込めるのだから公式が言っている通りライブラリだろう
導入のしやすさ、構成への制限の少なさはフレームワークよりライブラリの方が優れている

htmlフレンドリーなMVCフレームワーク(spring, asp.net, etc...) + vue(static js)

この組み合わせが最も簡単で理解しやすくトラブルも少なかった
node+npmを使ってビルドまでやると対応できる作業者が急激に減る

npm対応できない業者ってどんだけ低レベルなんだよ

WordPressしかやらないところとかじゃない？

そんな会社ないと思うじゃん？
あるんだなコレが

>>53
業務系の派遣さんはほぼ全滅
node知らない人も少なくない

業務系の派遣がnode使うわけないじゃん
javaパーだろ

npmでインストールする類のcliは中々いい本ないもんね
市販されてる本だと大体型落ちだったりするし
webpackとかbabelとか

だからといって旧世代のバージョンに合わせてからやるんじゃ折角新しい技術を覚えようという目的に本末転倒になってしまう
結局わりと頼りになるのがQiitaっていうオチ
まぁQiitaに固着し過ぎるとQiita以外なら簡単に見つかるものを見落とすって事もあるけど

モダンなツールなら英語の公式ドキュメント読めばOK
昔と比較して本にかける金が激減してありがたい

>>56
nodeとnpmを覚えるとすごく楽になるのにな
git使ってると余計にね

>>58
公式とgithubのissue見る
キータも古いのが多いからいつの間に非推奨になってるライブラリもけっこうある

そういやgithubもたまに入ってるexampleがちゃんと動かないヤツとかあるよね

「2018年最新のReact構築法」みたいなの参考にしてみたが内容がすでに古いのと書き方間違ってたり
公式が変わったのにそれに対応されていなかったりってのが多かった
ライブラリ使う場合は公式だけでは足りないから、ライブラリの公式みたり
とにかくどこか一つにまとまってるのはない
あるのは俺のPC内だけ笑

正攻法に関しては確かにGithubなんだろうだけどビルド時とかに依存関係で謎のエラーが出た場合とかね

>>58
npmに本なんか要らないだろ
ガイジかよ

>>65
だからnpm自体じゃなくてそれ経由でインストールするwebpackとかbabelとかって書いてるじゃん

>>66
それも要らんだろ
npmで自作パッケージをインストールできるようにするにも本なんか要らない
初級エンジニア程度のレベルなら誰でも簡単に使える
mavenやgradleに本なんか居るか？
それと同じだわ

フロントエンドは特に変化も早めだしネット上で情報漁れんとな
というか本よりまず公式のドキュメント読めよって思う

あと自分ができるできないの話じゃなくて
>>53,55,56
の状況に対しての話ね

だから結局フロントエンドフレームは多数はにはならずｊQueryはフレームワークだって言い張る輩も居なくならないって話

公式のドキュメント読んだってわからないこといっぱいあるよ

>>70
公式ドキュメントってリファレンスも兼ねてるのにそれで理解できないって逆にヤバい
エンジニアとしてよりも人間としてな

フロントエンドのwebpackの設定なんか、ケースバイケースで、
プラグインの組み合わせとかいろいろあるわけだし、
人それぞれなものを公式サイトが書いてあるわけないじゃん

>>72
具体的に

上に話のようにインストールやら基本なら
まず公式、エラーや組み合わせ等なら他を漁ればいい

漁っても無いものはリファレンス見て自分で書くことになると思うが

公式見ればいいだけなのに公式すら見ずに文句言う奴らはなんなんだ？

>>75
ただの妄想

公式見ればいいだけなんて言ってるやつこそが公式を全然読んでないやつだと思う

なんで俺ができてお前ができないの？

誰もまともに本書かないから、未だにnpm install --saveとか書いてるやついるし
時代遅れの情報がいつまでも残っちゃってる

>>78
でYouは具体的に何を使っててどれくらいのものが作れるのさ？

>>80
基本的にReact使ってるサイト
state管理にreduxは使ってる
その他axiosとかルーティング管理用のライブラリとか
そもそも必要であればライブラリはなんでも使えるけど
どのくらいのものが作れるかって、仕様と時間と金があればなんでも作る

今はtypescriptが当たり前になってきているから、typescriptを絡めることで本を作りやすそうなのになあ

typescript推しはIE信奉者でMS狂信者しかいないと思ってる

で？キミらはどのくらいのことができてどのくらいのものが作れるの？

>>83
AngularはGoogleだけどな

>>85
angularはjavascriptで書かれたオープンソースのフロントエンドWebアプリケーションフレームワークなんだよな

べつにGoogleがIE信奉者でもいいじゃない。

>>86
えっ？

はは、結局お前らフレームワークに振り回されてるだけじゃん

jQueryの過去の資産を大事にする方針を
見習ったほうが良いぞ

es6+バベルでええやんけ

フロントですでにエンディングかよっていう。

スルーするな
キミらはどのくらいのことができてどのくらいのものが作れるの？

>>92
ああスマンスマン

バックにLaravel置いてVue(Vuex、vue-router、axios、Bootstrap-Vue)とReact(Redux、react-router、SuperAgent、React-Bootstrap)入れた二種類のセット
それぞれ一通り機能確認するデモサイトをローカルに作ってみたって程度だよ実戦投入するのはこれから

あとNuxtとAngularはcliからプロジェクト生成してどこに何を書いて機能追加していけばいいか分かったって程度
Angularとかはコンポーネントの数多すぎて細かいところは全然

フロントエンドフレームワーク去年の後半から始めたばかりだから流石にまだまだ>>81みたいなんでもできるとは言わないよ

公式って結構公平だからサード製のモジュールに関してはこれ使えみたいな事あんま言わないじゃん
その辺に関してはやっぱ新ジャンルに手を出すなら書籍１〜２冊読んだ方が効率いいと思うんだよね

>>89
jQueryを使い続けるとしても設計指針としては参考になる事柄は相当あったと思うよ
何もやらなきゃいずれは時代遅れな挙動のサイトしか作れないって事になる

せめてHTML5のAPI集くらはちゃんと読んでおいた方がいいと思うよ

>>93
React-Bootstrapってv3だよ？
今さら使う意味なくね？

そしてReactstrapはまだまだ開発中

俺としてはBootstrap Nativeをオススメするなあ
自分でコンポーネント作ることにはなるけど、むしろ使う部分だけコンポーネントにするから余計なstateないしスッキリ

>>95
npm install react-bootstrap@next bootstrap
@nextって付ければv4でいけるけど
https://react-bootstrap.netlify.com/getting-started/introduction

ありがとうBootstrap Nativeはちょっと調べてみるよ


ところでReduxとreact-router連携するのって何使うのがベターなの？
パっと調べた範囲で
react-router-redux
redux-first-router
connected-react-router
くらいがあるけど選定するための基準がなんとも

別にv3で困らなきゃそれでいいじゃん。

Bootstrap Nativeってパッケージはなかったけど
これの事？
↓
Native JavaScript for Bootstrap

ReactNativeのNativeじゃなてNativeなJavaScriptって意味のNativeか

>>97
V4はV4で何かと機能増えてていいもんだよ

>>96
v4はまだ開発中だしね…

あとrouterはconnected-react-routerがいい
react-router-reduxは非推奨になったから
https://github.com/reactjs/react-router-redux
>Project Deprecated

書籍ではreact-router-reduxを推してるから注意だね

>>98
そうNative JavaScript for Bootstrapのこと
どのコンポーネントライブラリも中途半端で開発中だしissueみたらバグ多いからまだ使うべきではないと思う

それより儂のチンポをしゃぶってくれんかのー

今は、npm よりも、yarn を使うことが多い

npmのバージョンアップにより
yarnのメリットはなくなったんじゃないの？

世界では圧倒的にnmp優勢だよな

とりあえず
npm, react, babel あたり使って開発してみたらいいんじゃないかね。
それらの使い方やドキュメントの漁り方になれれば他に移るのもやりやすいでしょ。

Ionic+Angler使い続けてるけど
そろそろ乗り換えるべきか悩みますね

乗り換えに理由がない時点で何使っても駄目なんじゃね？

>>106
釣られたな
Anglerだけに
なんちって

vueはマジで独学は難しい。
あたかもjQueryより手軽で簡単みたいな事を謡い文句に
なってるけど絶対そんなことないと思うわ。アルゴリズムと
データ構造をカジッてないと
細々とした機能が何のためにあるのか、どうやって
道具として使われるのかが判らん。多分これはReactやAngularでも
いえることなんだろうけど。

宣言型のjQueryとは考え方が違うからね。
CSSも宣言型なので、宣言型ベースで考えてると
オブジェクト指向のvueが使いにくく感じるのは当然

>>108
まぁjQueryの様には行かないわな

他のフレームワークよりも導入しやすい点を挙げるとするなら
制御対象のDOMを<div id="app">〜</div>で囲めば元のhtmlを活かしたまま使えるって事くらい
ReactやAngularの場合はイニシャル掛けた時点でその内側のDOMはフレームワークに定義したルートコンポーネントに差し替わってしまうからね

Vueをオブジェクト指向だって言うのは別におかしくないよ

vueが難しいならこれからウェブアプリの標準的な実装方法になるReactはもっと難しいことになる

しかもjQueryより楽と言われているから脳みその思考の仕方が違うんじゃねえの

思考の仕方が違うってのはあると思う

手続き型でめちゃくちゃ複雑なスパゲティプログラムを間違いなく書けるほど高度な情報処理能力を持ってるのにオブジェクト指向、関数型、宣言的プログラムはからっきしダメという人
逆にそれらを使いこなして洗練されたコードをかけるけど、手続き型のスパゲティプログラムを処理しきれない人

どっちが賢いとかではなく
たぶん脳の基本構造が違うのだと思う

フレームワークだとDOM APIと違う方法を使うことになるので
新たに覚えることが多い

jQueryが楽なのはライブラリでフレームワークとしてはDOM APIと
同じだから標準を知っている人は単にAPIを置き換えただけ（と感じる）

とはいってもjQueryは宣言型なので、それを活かした書き方をしなければ
本領は発揮できない。具体的にはCSS（セレクタ）でHTMLの構造を定義して
（CSSの）クラスベースで設計する。

だけどそんなことは構わずDOM APIを置き換えただけとしても使えてしまうので
そういう人ほどjQueryは不要って言ってしまう。

まあ要するにフレームワークだと最初に覚えることが多いから敷居が高いが
やり方が強制されるのでよく理解してない人でもそれなりのコードになる。
jQueryだと（DOM API標準を知ってる人なら）APIの置き換えから入れるから
敷居は低いが、効率いい書き方にしようと思えば、宣言型であることを理解して
自分でCSSのクラスベースで設計しなければいけないということ

いつまでjqueryの話ししてるの？

Vue では、単一ファイルコンポーネント(SFC)と言う、独自フォーマットがあるので、
HTML, CSS, JavaScript(JS) を、1つの.vue ファイルにまとめられるから、
この3つの組み合わせを探す手間がなくなる

普通だと、各HTML, CSS, JS ファイルから、該当する組み合わせを探すのが、ものすごい手間

スコープ付き(Scoped)CSS で、他のファイル・コンポーネントと被らない、ユニークなdata属性が付く

<span class="title" data-v-aaaaaa>あ</span>

span.title[data-v-aaaaaa] { color: red; }

>>116
違いがイマイチ分からんってヤツに違いを教えるのもこのスレとしては優位意だと思うがな

結 論

中 規 模 開 発 を 謡 っ と き な が ら

中 規 模 開 発 の 本 も サ イ ト も な い。

あることにはあるが

細々としたシステムは説明されてるが

実際に使ってみると対外「チンパン」する

>>117
> HTML, CSS, JavaScript(JS) を、1つの.vue ファイルにまとめられるから、
> この3つの組み合わせを探す手間がなくなる
まとめたほうが本当に便利かというとそうとは限らない。

サイトのデザインを変更する時は一箇所だけじゃなくて全体を変更する必要がある
例えばお正月用デザインとかクリスマス用デザインとか。
コンポーネント一つを変えれば良いわけじゃない
それに対して標準的なやり方をしていれば1ファイルだけ変えれば良くなる

ブログサイトのように、サイトごとにデザインが変わる場合は、コンポーネント側で
デザインを矯正できないから、結局CSSはコンポーネントの外に出す必要がある。
HTMLに関しても、コンテンツすべてをSFCに入れられるわけじゃない。
というかコンポーネントとは汎用的なものだからコンテンツはSFCの中に入れない。
1つの.vue ファイルにまとめられるが、1つの.vue ファイルにまとるわけじゃない
まとめる場合と、まとめない場合が混在する。

そもそもCSSであっても適切に（CSSの）クラス設計をして
クラスごとにファイルに分ければ、探す手間なんていらない
このコンポーネントは、このファイルと決めるわけだからすぐに見つかる。
だけどそのためには設計能力が必要になる。

ただ>>115でも書いたが、そんなことは構わずに使うことも出来る。
だから最初の敷居は低い。ただし適切なやり方をしなければ本領は発揮できない。
それに対してフレームワークだと最初に覚えることが多く敷居は高いが、
やり方が強制されるのでよく理解してない人でもそれなりのコードになる。

長い。３行で頼む。

普通、SCSS は、10個ぐらいのフォルダに、種類ごとに分けて入れる

サイト全体のデザインなら、sight とか、
ページ固有のデザインなら、pages とか

components と、全体のデザインは、分けないといけない

scssをフォルダ別けするかね普通
scssフォルダ一つでいいじゃん

>>123
その辺の派閥でVue派とReact,Angular派に分かれるんだと思う

>>124
でも会社で使うなら、派閥起こしてる場合じゃなくね？

会社ならそれこそ会社で何使うか方針決めるんじゃない？

>>126
それは上が決めること

だから会社で方針が決まれば別に会社内部で派閥が分かれる事はないだろ？
それでいいじゃん何に対して突っかかってんの？

フレームワーク使いたいって言ってるのに
上に今までのやり方（jQuery）でいいやろ？って言われて
理解してくれないって突っかかってるんじゃねーの？

やるべきことはここで愚痴を垂れるんじゃなくて
「これからはフレームワークの時代なんです！」
以外のまともな理由を言うってことだよ

フロンエンドフレームワークの導入しやすさってバックエンド何使ってるかにも依るよね

どのサーバーサイドフレームワークでもREST対応、JSON対応してるんだから
バックエンドがアプリケーションサーバーならどれでも大差ないだろ。

ただ単なるウェブサーバーだと、クライアントでフレームワーク導入する必要はないだろうな

>>130
はあ？それはねーだろ
お前は無能晒して恥ずかしくねえの？

フロントフレームワーク使うことが即座にバックエンドがREST ONLYに繋がるわけではない
MVCとVueの組み合わせはかなりいい感じにまとまる
でもJSPやWebFormsでは全くミスマッチだろう

>>131
データのやり取り以前に初期導入時の敷居の違いの話

>>134
そもそもバックエンドなくてもフロント作れるのがフロントフレームワークなのだが？

>>135
そんなシステムとして完結してないモノを見せて凄いでしょ？とか言うヤツばっかりだからjQueryのシェアが強いまんまなんだよ
XSSやらずにバックエンドのDBとどうやり取りすればいいかとか説明できんだろ？

>>136
説明できんだろ？とかテメェ何様なんだよ？
XSSごときで偉そうなカス野郎www

>>137
話の主題はXSSじゃなくてデータベースの読み書きについてだが
>>135の言い分だとproxy設定とかロクに書いたことないだろ？

ぷろきしｗｗｗ

フロントのスレだしリバースプロキシまで書かないと意味伝わんないんじゃないかな

分からない人にはリバースプロクシって言ってもやっぱ分からないんじゃないかと思うけど
入門ならそんな事しなくてもいいLaravel-Mixが楽でいいと思う

いやそこの分離は本質だろ。

最終的には分離開発するにしても導入検討時から分離を強制してちゃ検討も進まないから結局導入されない

vueのテンプレート作成
ジェネレーターみたいなモノはないよな。(๑´ڡ`๑)
簡単な文法からVueライクなHtmlタグ入りのソリューションを提示してくれるような奴

いくらでもありそう

>>144
vue template generator
でググったらそれっぽいのあったよ

それらしきモノって「ieoman」のことかな？
windowsの解説サイトが無くてフォルダーは手動で構築したけど
なんか半分ぐらい動く感じになった。文法は簡素な感じだけどGroovyやってる感覚になる。

yo mcs:component

ポチッとやたけど、成功パターンがそんなに
判らんので、実用的か、どうかも判らん

yeomanだろWwwWwWw

なんて読むの

>>149
https://dictionary.cambridge.org/ja/pronunciation/english/yeoman

宇宙兄弟かな

今のプロジェクトでangular使ってるけどvue使ってみたかった
まだangularの事全然知らないけど、コンポーネントがts,html,cssでそれぞれ別れてるせいでファイル数膨大になるのが嫌だ

Vueは小規模、Angularは中規模以上
という感じがしたな。手間的にも。
Angularの方がアプリ的な作りとして
しっかりしててわかりやすいかな
ただちょっとしたことですぐに動かなくなる
Vueもちゃんとルール決めして作れば
短期間で作れるしよいね
Reactはやってないからわからん…教えて

Angularを開発しているGoogleチームの敵は
別のGoogleチームかもしれない

Google、FlutterアプリをWebアプリへ変換する「Hummingbird」発表
https://www.publickey1.jp/blog/18/googleflutterwebhummingbirdwebdartflutter_live_18.html

Reactで静的サイト作るならGatsbyが素晴らしいよ
モダンなSSR、Webpack、GraphQL対応してるし
かっこいいサイトのテンプレートも充実してる
Reactの勉強用として使い始めたけどGatsbyハマったわ

SPAフレームワークでSSRってなんか目的を見失ってませんか？
従来のMVCフレームワークでいいじゃないですか

イエス。サーバーサイドフレームワークとjQueryで十分

お前ら例に漏れずgatsbyの「SSR」を勘違いしてトンチンカンなこと言っててワロタｗｗｗｗｗ
ヒント： gatsbyは「静的」サイトジェネレータ

もうflutterでええやん。

>>155
サイトのテンプレートって
デモサイトどこかにある？

Markdown方式（超簡単）で記事かけたりとまじGatsbyいいよ
>>160
https://www.gatsbyjs.org/starters/?v=2

>>161
ありがと
トップページからだと
ここまでたどりつけんかった

今大手サイトのフレームワーク利用状況ってどうなんだっけ？

ニコニコ、pixiv、Amazon辺りがReact使ってた気はするけど

Netflix。サービスページほぼすべてに採用。
一部ランディングページから軽量化のためにlodashなどとともに取り除かれた際はアンチから「NetflixがReactやめたｗ」とデマ流されるほど。
あとTwitter。
https://www.infoq.com/jp/news/2017/02/twitter-react-mobile-stack
あと当然Facebook。

そのサイトで使ってるかどうかはfirefoxのプラグインとかで分かるけどたしかにトップページにはないみたい
利用規約では検知した

任天堂SwitchのeShopがReact
ZOZOがVue
という記事を読んだことある

大手サイトじゃなくて、大手企業のフレームワーク利用状況を知りたい
特に自社で何かしらのサービスを提供してない会社の


ほぼゼロであることはわかっていってますがなにか？ｗ

JSF使ってます
SPAはオモチャみたいなアプリにしか使えないから大手企業は採用しないと思います

twitterはともかくfacebookおもちゃかあれ？
すごいアプリ製作してるんだね。

Amazonって欲しいものリストの部分だけReact入ってるみたいだね

WappalyzerっていうChrome拡張入れるといいよ
サイトでReact使ってたら素晴らしいしReact+Gatsby使ってたらナカマだし、違った見方でネットブラウジングできる
jqueryのみだとダサってなる（実際サイトの用途にはよるし使ってる人ごめんなさい）
他にも使ってるサーバーとかDBとかWordPressだ〜とかわかるよ

vuetify使ってる人いない？

公式のマニュアルが説明不足で全然わからんのだけど、
どこで情報仕入れてる？

formのresetボタンすら動作しない
もっと見やすくてわかりやすいUIはないものか

vuexに依存しないvueコンポーネントってどうやって作ってる？
頑張ってpropで渡すか、コンポーネントextendsしてメソッドオーバーライドするしか
思いつかないんだけどみんなもっと上手いことやってるの？

てかなぜvuex使わないのか

全般的にUIコンポーネントって部品の説明不足だよな

>>174
書き方が悪かったかも知れん。現状でもvuexは使ってる。

例えばvuexにstore/user/flowerFlag:boolean がある
flowerFlag === trueなら ボタンコンポーネントの色を花っぽくにするって時にどうしてる？

1.propでflowerFlagを渡す
2.コンポーネント内にgetColoer()メソッド作って個別にextend/overwriteする

この2つの方法以外にももっといいやり方あるんかな？

UIコンポーネントは自作すればいい

flowerFlagって名前が気に入らない
何をするフラグなのかさっぱり分からない
useFlowerTheme: boolean とかにしろや

shoriKbnFlg

makeBrainFlower === true

havingDirtyFireworks = true;
https://www.urbandictionary.com/define.php?term=Dirty%20Firework

SPAフレームワークでSSRが醸し出す、一周回ってMVCフレームワークに戻ってきた感が笑える

そう思いたくて必死なのが笑えるｗｗｗ
そうやって得た安心は妄想だぞｗｗｗｗ

Rendertronを使ったダイナミック レンダリングの実装手順をGoogleが解説
https://www.suzukikenichi.com/blog/google-explains-how-to-implement-dynamic-rendering-with-rendertron/

Reduxってムズイよな

どのへんが？

Vueに乗り換えます
じゃあな

めっちゃIDがReduxっぽいけど

ここvueスレでもあるけどよくわからんがさよなら

スレタイのやつ3つとも触ったことないままAureliaってやつを採用しようと思ってるんだが、お前らの評価はどんな感じ？
採用の理由としてはVueが選ばれるのと同じだと思う

調べてみたら3年くらい前にちょっと流行ったみたいだけど
未だに話題になってないって事はそういう事なんじゃない？

流行り廃れでフレームワークを選ぶんじゃねえ！
自分に一番合ったフレームワークを選ぶんだ！

そうするとjQueryでいいということになる

https://jquery.com
jQuery: The Write Less, Do More, JavaScript "L i b r a r y".

ライブラリであることに負い目でもあるのかな？ｗ
フレームワークの流儀を押し付けられず、どこでも好きなように自由に使えるのがライブラリの強みだと言うのに。

どこ見て負い目があると感じたんだ？
ライブラリだからライブラリって書いてあるだけだろう

angularはwebエンジニア以外の血が流れてるんじゃないのか？ゲームエンジニアでhtmlもjavascriptも経験がなかったときの俺には非常に使いやすかった。
web関連の経験値がたまってきた今となっては大がかりに感じちゃってあえて使おうという気はでないが…

フレームワークと言われるのがウゼーから強調してると思うが
Reactもライブラリって名乗ってるな

結局MVC+jQueryが一番バランスとれてんだよな
SPAなんて作る側にも使う側にも画面遷移が超早いぐらいしかメリットねえもん

>>197
それは流石にSPA作った事無いやつの暴論

jQueryの功績は確かに大きい。その次の世代として仮想domありきのvueやreactなんだから、jQueryとの比較は意味が無い思う。

大雑把にいうとライフサイクルメソッドみたいなイベントとか状態管理などの枠組み含むものがフレームワークで
枠組は使用者が作って機能を呼び出すのがライブラリだろ

>>199
> 仮想domありきのvueやreactなんだから、

仮想DOMはメリットじゃないよ

フレームワークの設計上どうしても遅くなるという問題を
回避するための手段でしか無い
遅くなければ仮想DOMなんて無いほうが良い

そういやスタイル側のフレームワークって何がいいの？
基本はBootstrapなんだろうけど

やりこめば
やるこむほど
思うけど、vueは簡単じゃあないと思う。

reactとvueどっちがむずいのかね

よう分からんけど、日本じゃ wasm は話題にならないね。
情報が遅れてるんだろうか？

javascriptが十分に速いから

wasm盛り上げたいgoogleもjs速くし過ぎたと後悔してることだろう

wasmが必要となるようなものは、
ウェブじゃなくてアプリにするから

なるほど、日本では、「JavaScript を高速にしたもの」と思われている段階なんだね。
アメリカではパラダイムシフトが起きると思われているらしく、色々と恐れられて
いたりもするらしい。

ﾜｯﾁｮｲがVueやんけ

>>209
パラダイムシフトと言っても所詮
ウェブがアプリに追いつくぐらいの意味でしか無いから

C#がクライアントで使えるようになるだけでもかなり有り難い
Microsoftなら開発者に優しいエコシステムを提供してくれる

あんなもの昔の時代へのパラダイムシフトでしかないだろ
負の遺産を再び抱え込むだけだよ

>>212
wasmでは、C#は使えるようにならないはず、一生。

NaClが出始めの頃や、なんならActionScriptやSilverlightのRIAでもパラダイムシフトだのなんだの言われてたな。

>>214
すまん。既に使えるらしい。
.Net 仮想マシンを、wasm に移植したのかな。

WinForm か WPF か知らないけど、そういう標準的な作り方をしたC#が
ブラウザでそのまま動くということではなくて、Razorを使って専用に
作らないといけないらしいね。

JavaのGUIの場合、Swingは、完全にJavaで書かれていて、OSに
依存せずに全部自前で書かれているので、Java仮想マシンさえ動けばどんなOS
でも完全にGUIアプリが動く。
でも、C#の場合はライブラリがWin32 APIなどを呼び出しているから、そうは
行かないみたいだね。よく知らないけど。

razorてメチャメチャ容量大きくなっちゃってまだまだ使い物にならないんでしょ？モバイル用にでも使えるくらい小さいの吐いてくれないかなぁ…

webの技術にパラダイムシフトって言われるような変化起こすにはjavascriptの標準仕様が劇的に変わるか、革命的なブラウザが出てきてとんでもないシェアを握るってパターンしかないという理解だわ。

無理して既存の資産をwasmに移植するメリットはないと思うね
最初はへんな抽象化せずにDOMによく馴染むHTMLフレンドリーなライブラリをC#で実装してくれればいい
なんならjQuery.Netみたいなパクりでもかまわない
手を出しやすい土台を作って欲しい

wasmって既存の資産を移植するためのものだよ？
最初から作れるのならJavaScriptを使えば良いわけだし

>>219
Blazorな

HTML5によってFlashなどのプラグインが死んでいったり
JavaScriptからカメラやマイクにアクセス出来るようになったりとそれなりに影響があった
WebAssemblyはそれらをさらに強化する

JavaScriptでは限度があった動画/音声データのリアルタイム解析なども可能になる
プラグインが死んだUnityも今はWebGL+WebAssemblyで動く

プラグインでバラバラ対処してたことが標準化されたって感じかね
劇的に変わる、と言うのはちょっと違う気もするが

HTML+CSS+javascriptでの開発って他の分野に比べると独特だから実は参入障壁高いんだよね。使いこなせないだけなのに技術そのものがショボいと言いだす。
だからwebフロントエンド以外の開発者がwebフロントエンドの開発したくなったときにいろんな手法を見つけて何とかしようとするんだけど、なれてくると別にHTML+CSS+javascriptでいいやってなる。
そんなイメージ。

メモリの扱いというかデータの受け渡しがだるいから、TypedArrayに対して高速に計算するだけの何かを導入してくれたほうがマシだった

wasmってiOSとAndroidに対応してる(する)の？

>>226
これ。

>>227
もちろん
Web標準やで？

んなことよりpush通知実装しろ。iOS safariテメーのことだ。

>>225
JVM の代わりとなる仮想マシンと考えた場合、C++ で書けることは重要なんだ。
C++は型があるので、ミスをコンパイラが発見してくれる事が多いから。
例えば、JSだと関数の引数が多くても少なくてもエラーにならない場合がある
と思うけど、C++では敢えて分かっていてそうする場合以外は必ずエラーになる。
C++ では整数型を受け取るつもりの仮引数に浮動小数点型の実引数を渡すだけでも
エラーになる。ところが、JavaScript ではエラーにならない。

このようなことがあるので、JavaScirpt は大規模アプリをC/C++で組んだことの
有るプログラマからは嫌われている。特にアメリカで。

TypeScript使えばいいだけじゃね？

JavaScript だと、プロパティーには文字列と数値、Objectのどれでも入れられるので
単に書き間違えているだけなのに、エラーにならないので原因不明の不具合が直らずに
困る可能性がある。例えば、1,2,3 の 3つの数値を用いて、何か3種類を区別する
目的でプロパティー aaa を作ったとしよう。
aaa = 1;
aaa = 2;
aaa = 3;
と書くことをプログラマは想定している。ところが間違って、
aaa = "x";
と文字列型を入れてしまった場合、どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書いてしまった行を探し出すのに苦労することになる。

こういう間違いが、C++ では、魔法のようにコンパイラが発見してくれる。だからC++は
安全で安定性が高いために人気がある。

テスト書くんだからすぐ見つかるでしょ？

>>232
その言語を多くの人は知らない。ずっと古くからC言語があり、とても人気があって、
その後継にC++があって今でも続いている。アメリカではC/C++経験をつんだ
プログラマが日本よりも沢山いるためか(?)、C/C++ で wasm が使えることで
game changer, pardigm shift などと喝采が起きているらしい。

>>234
なぜ、C/C++ が型を書いているかは、言語が古いからではなく、まさに
エラーチェックのためなんだよ。

typescriptはもう半数が使ってるくらいの感じでしょ

>>234
テストで結果が異常であると分かっても、どこに原因があるかが分からないことがある。
だから、細かく実験していく必要があり、それには時間がかかる。
型の間違いをコンパイラが見つけてくれるだけでもミスが判明することが
かなり多くあり、開発時間の節約・短縮に大幅に貢献することになる。

ミスったときには、型や引数の個数まで間違っている確率は意外と高いので、
それだけでも8割くらいの単純ミスは発見できてしまう。

>>237
Webプログラマから入った人にはそう思えるかもしれないが、昔からの
普通のデスクトップアプリを作ってきた人はそうではない。

C++ソース（型がある）→コンパイル（型情報に基づきエラー）→バイナリ（型はない）→ネイティブ実行

Type Script（型がある）→トランスパイル（型情報に基づきエラー）→JS（型はない）→ブラウザ実行

あんま変わらん。
wasmが出てきてから聞かなくなったけどJSはWebのアセンブラとは言い得て妙だったな。

>>235
> その言語を多くの人は知らない。

大丈夫。TypeScriptはJavaScript＋αだから
α（型）の部分を除けばJavaScriptそのもの

>>238
> テストで結果が異常であると分かっても、どこに原因があるかが分からないことがある。

十分にモジュール化されてればすぐに分かるよ

>>240
TypeScript という言語自体を今までの大部分のプログラマは知らない。
言語はなるべく1種類を学ぶだけの方が楽だから、C/C++ という事になる。

逆だな。javascriptをすごく理解してるWebプログラマのほうがjavascriptで粘ってて、
javascript理解しがたいと思ってる人らがtypescriptに救いを求めて移行した感じがある

>>241
そこまで頑くなに　C/C++ を拒絶する理由がない。
C/C++ を1つ覚えるだけで組み込みから何から何まで作れるようになり、
速度も現存する高級言語の中でTOPな上に、エラーも少なく、安全。
過去からの資産も多い。例えば、画像処理、AI、音声解析、文字認識、
3D描画、物理計算、何から何まで C/C++ は存在している。
敢えて後から出てきた言語を覚えるの無駄。

>>244
でも、ハイレベルなプログラマはそうは思ってないと思うよ。
実際に作った作品で勝負したら C/C++ の圧勝だと思う。
機能面でも速度面でも安定性も品質も。

>>243
js抜きにしてもtypescriptの型システムは良くできててC系文法の型システムとはこうあるべしといったお手本みたいだけどな。
c++の型システムは継ぎ足しキメラの失敗作だけど今さらどうしようもできねえしな…

>>247
仮に TypeScript に色々良いところがあったとしても、今迄から高い定評の有る
C/C++をまず、覚えてしまうほうがずっと将来性がある。
だから、人々はC/C++を覚えようとしてきたし、少なくともアメリカのプログラマ
はそうしてきた。いったんC/C++を習得すると、それだけでほとんどあらゆることが
簡単にできて、成果物の効率や速度もとても高く、エラーも少ないものが出来る。

その状態で敢えて、TypeScriptを覚えるのは非効率。だから、C/C++ が
ブラウザで動くのはすごく魅力的な話という事になる。

S： もうかなり時間がたったしね、C++ が時間の無駄だということにはほとんどの人が気がついたとは思うけど、でも当初予想していたよりはずいぶん時間がかかったな。

I： 具体的に何をどうやったのかな。

S： 最初はほんの冗談のつもりでね、みんながあの本を真に受けるとは思ってもみなかったんだ。脳みそが半分でもあれば、オブジェクト指向プログラミングが非直感的で、非論理的で、非効率なことくらいはわかるよね。

I： え？

S： それに「コードの再利用性」ときたら…。どこかの会社がコードを再利用したなんて話を聞いたことがある？

I： いや、実はないんだけども、でも…。

>>245
> そこまで頑くなに　C/C++ を拒絶する理由がない。

C/C++は開発効率が悪いから。
ポインタを使うのに、std::auto_ptrを使わないといけない
そして世界が混沌としていて、ポインタという基本的なものでさえ
時代が変われば使い方がガラッと変わってしまう（皮肉）

>>250
>ポインタを使うのに、std::auto_ptrを使わないといけない

5ch/2ch の言うことを真に受けるとそうなるが、普通に、

BYTE *ptr;
TYPE *ptr;

で済む。昔から、C++ といえばこのスタイルで、auto_ptr 自体はずっと後発で、
C++ ではないといっても過言ではない。

>>248
> だから、C/C++ がブラウザで動くのはすごく魅力的な話という事になる。

既存のC/C++の資産をJavaScriptから使うのに便利だよね〜

>>251
今どきそんなコード書かないよ？
既存のライブラリのソースコード見ろよ

>>250
>C/C++は開発効率が悪いから。

そんなことはない。メモリリークのことを気にしているなら、デストラクタの
中で解放するように1行書くだけで、ほとんどの場合はリークしないし、
危険なこともない。

>>253
ネットはおかしい情報が多い。
ちゃんと本を見たほうがいいよ。

>>254
デストラクタの中で解放する1行を書き忘れた場合、それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書いてしまった行を探し出すのに苦労することになる。

ミスったｗ

デストラクタの中で解放する1行を書き忘れた場合、それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えて書き忘れた行を探し出すのに苦労することになる。

>>253
std や auto_ptr を使うから難しく感じるんだよ。
何度も言うが、それは C++ ではない。これはマジ。
今の std:: 系のライブラリはSmalltalk の信者が作ったものらしい。
C++ の標準化委員会がおかしなことになっていて、もはや、本来のC++
ではなくなってきており、だから、C++が難しいと感じる人が増えている
気がする。

>>258
え？お前C++使いこなせないの？

>>257
クラスが 100種類の場合、デストラクタは 100 個しかない。
だから、ソースが数10万行あっても、100箇所を調べるだけで済むよ。

>>260
調べる箇所が100箇所でも
何を解放し忘れたかを確認するのは大変

>>259
日本だと auto_ptr みたいなのが C++ だと思ってる人がいるけど、
勘違いだよ。

stdなんちゃらを使わなかったら
バッファオーバーランで脆弱性になるし
それでも動くから
どこかで不具合が起きるだろうが、ソースが何10万行も有る
プログラムの場合、この間違えた行を探し出すのに苦労することになる。

>>261
だから新しい言語を次々に覚えて C/C++ だけは覚えないで過ごしてきたのかな、
あなたは？
数十の言語を覚えるより、C/C++ を1つ覚えるだけが良いと思うよ。徹底的に
それだけを学んだほうが良い。

>>262
勘違いとかそうでも良いわｗ
auto_ptrが使えて、実際にauto_ptrが使われるがC++だから

>>264
はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね
いろんな言語の機能をキメラのように組み合わせた言語ですから
人によって書き方がぜんぜん違う

auto_ptrを使ってるだって！？これC＋＋じゃないよ！
って言う人がいるぐらいだから

だから開発効率が悪い

さもTypeScriptが競合であるかのように突っかかってきてるが全く的外れ。

TypeScriptのトランスパイルターゲットはJS。
競合はその他AltJS。
この中では既に天下取って安泰。

C++のコンパイルターゲットはWASM。
競合はRust、Kotlin、.NET、、、どんどん増えるぞｗ
がんばってな！ｗ

もちろんナマのJSはWeb界のグルー言語として残り続けるよ。
シェルスクリプトが性能を理由に消えないようにね。

>>263
そうならないように、C から C++ に進化してきたんだ。
そのために、コンストラクタ、デストラクタの概念が導入された。
それだけでも十分に安全で簡単に書ける。
逆に、std ライブラリは構造が理解しにくいので難しく感じるんだろう。
auto_ptr とか使おうとすると、C++ は一気に煩雑で嫌いになってしまうと思う。

だから、auto_ptr も std:: 系ライブ来も SmallTalk 信者が作ったものであって、
C++ の流儀とは全く異なる異質なもの。C++ で SmallTalk をやろうとするので
めちゃくちゃ複雑になってしまっている。

>>266
>はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね
C++98 まで覚えれば大体C++の基本は習得できていて、それはそんなに大変
ではない。

・auto_ptr 系は、uniq, smart など沢山ありすぎるので、初心者には難しく、
　下手に使うと、生ポインタより危険かも知れない。これらはかなり後発のものなので、
　最初は覚える必要はない。
・std:: 系ライブラリは後から習得すればよい。

>>229
マジで？！
だって公式のデモはiPhoneだと動かへんで？

>>270
まさかSafariとか使ってないよね？

C/C++は使うべき場面が決まってるから他の言語と揉めたりしないと思ってたんだが。

なんかSafariだけで動くwasmの代替品独自に作ってなかったっけ？

>>271
SafariもWasmはサポートしてると読んだけど、確か。

TypeScript って、MSの独自言語なんだよね、知らないけど。

>>261
例えば、VS の VC++ で C++ ソースをデバッグモードでビルドして、できたバイナリを
デバッガで実行すると、そのアプリの終了時に、メモリーリークが起きているか
どうかがIDEの Output Pane に出力されるようになっていて、その際、どのソースの
何行目で new TYPEしたオブジェクトが解放し忘れているかが、ずらずらと一覧表示される。

で、その場所が分かったら、多くの場合は、そのポインタをメンバ変数に「持っている(have a)」
class のデストラクタに、1行、delete ptr; と書くだけで、メモリーリークは直る。

例外として、複数のポインタから同じオブジェクトを参照していて、かつ、そのポインタ
が永続的にグローバル変数や、何らかのクラスのメンバ変数に格納されている場合には、そこまで
単純には行かない。その場合は、プログラマが頭で考える必要がある。

C++の方向性は最初から何も変わっていない
ctor/dtor, RAII, ムーブとより整理されていっただけ

1985 C++ / TYPE *　(Cfront 1.0)
1986 C++ / (実装予定のtemplateなどの説明した文書が公開)
1991 C++ / T*　(template可能, Cfront 3.0)
1992 C++ / auto_ptr　(STL実装, 例外導入, RAII)
1998 C++ / (最初の標準化, C++98)
2011 C++ / unique_ptr (ムーブセマンティクス, C++11, auto_ptr非推奨化)
2015 Rust / 言語レベルで所有権システムを導入 (デフォルトがムーブ, Rust 1.0)

wasmに絡むとはいえスレチ気味で
しかも古いやり方の話を何レスしてるんだか・・・

>>274
カバーしてる範囲が他のブラウザーに比べてかなり狭い

このスレ的にはわざわざC++使うんじゃなくてTS→wasmじゃないの

tsnativeかts.net来ないとwasmにはコンパイル出来ないだろ。
せっかくAltJS戦争に勝ってブラウザのjsに対する忖度パワーをすべて手に入れたのにわざわざwasm戦争に参入する必要はないだろ。
c++の構文が古くさすぎ冗長すぎで嫌、rustの構文はキモすぎて嫌と言うならkotlinかc#にすれば。

>>249
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

VuexとReduxってどっちがムズイの？

もしかして考え方同じ感じ？

Angularってwikipediaには「フロントエンドWebアプリケーションフレームワーク」って書かれてるけどまさにその通りだよな。javascriptのフレームワークって感じではないわ。
HTMLとCSSとjavascriptの技術を採用したwebサイト開発フレームワークって感じ。

Reduxのほうがムズいけど、これからやるならReduxがいい

>>284
JavaScriptのフレームワークって感じではないって意味がわからんぞ。

普通はJavaScript製のフレームワークって意味だろ
○○（何かしらの言語）製のフレームワークなのだから
AngularはJavaScript（製）のフレームワークだ

別の言語なら、〇〇（言語）のフレームワークなんてものが存在するのか？

angularとReact、Reduxってどっちが簡単？

学生時代、英単語の暗記が得意だったやつはangular、数学が得意だったやつはreact

>>286
なるほど。
ピュアjavascripで書いたら大変な記述をちゃちゃってやってくれるからスレタイの3つとかjqueryとかはjavascript(の)フレームワークって呼ばれてると思ってたんだがとんだ勘違いだったのね。

冷静に考えれば>>289はライブラリか。

jqueryとreactは自称ライブラリ、vueとangularは自称フレームワーク
公式サイトのトップを見た限り

>>289
それを言ったら、jQueryで使うのはピュアJavaScriptだし
Angularで使うTypeScriptやReactで使うJSXは
ピュアJavaScriptではないけどさ

react捨てるにしてもreduxの考え方は学んどいて損はないよ。

hook apiとcontext apiデフォで使えるようになるから個人ユースの規模ならredux必要なくなるよ。

>>284
Angularと比べるならVueとよりもNuxtと比べる方が合理的だな

>>286
コーディングはすべてTypeScriptだけどね

ものは試し
初心者だがAngular勉強してみるわ

reactにしとけ

React勉強したがやっぱりウェブサイトの殆どには適用できない技術だな
例えばニュースサイトにReactを導入するメリットはないだろう

融通が利くのはVue

MVC+Vueが世界最強

>>299
画面遷移がなくなるからメリットはありだろ

Reactにした
Angularバージョンで詰みそうになる感じだし
学習リソース少ないし

潰しの効かなさを除けばAngularが一番いいと思う。ガッチリした設計な分だけ迷わずに使えるしプロジェクト管理もしやすい。
ただ習得してもキャリア的なメリットが薄そうだから自分で選択する気になれん。

当分は問題ないだろうけどAngularは将来的にはどうなるんだろうな
同じくGoogle製でしかも競合となるFlutter/Hummingbirdのリリース準備が進んでるみたいだし

世の中的にはReactが主流

>>302
画面遷移をなくせなんて誰からも要望来てないんだが？

VueもReactもAngularも将来性はないよ

近い将来にWebComponentに
置き換わることが決定している

>>308
逆って聞いたけど

逆って今WebComponentがないのに
今WebComponentを使ってるわけ無いだろ

>>307
お前バカだろ？
だいぶバカだな

結局ピュアjavascriptを真面目に身につければOK？

ピュアJavaScript + jQueryだな

https://w3techs.com/technologies/history_overview/javascript_library/all
73.8%に増加。今でもjQueryのシェアは圧倒的で伸び続けている。

どうせwpだろｗｗｗ
railsが使われてるからrubyが死にきれないのと似たようなもんｗｗｗ

だから「本当にやりたいこと＝WordPressでできる範囲のこと」なんだから
フレームワークもいらんし、どうせjQuery使われてるからjQueryでいいってことなんだよ

需要と供給

いくらすごいことができるようになっても
求められてないんだよ。

間違ってないと思うがなぜwpのスレに籠らずこんなスレ来て啓蒙活動してるのかｗ
他人が勉強するのが不安で怖いんだろ？ｗｗ
そんな女の腐ったようなセコい性格だからいつまでたっても童貞なんだよｗｗｗ

wpを持ち出してきたのお前じゃん？
頭大丈夫か？

論理に破綻はないが？wp圧倒してるの事実だし。現状に安穏としたいならしてれば？俺らは勉強するから、ってこと。図星刺されて恥ずかしくなっちゃったのかなｗ
お前のやってることってテストの前に勉強してるやつをガリ勉・ダサいとレッテルはって集団でみんなで堕落しようとセコい行動する女みたいなんだよｗ
男でそれじゃダメだよ。

angularは勧めんな。railsもそうだがああいう丸ごと全部なものになれると
それ以外なんもできなくなる。

wpしか使えない底辺カスは死ぬまでjquery使ってろ

>>319
> 論理に破綻はないが？wp圧倒してるの事実だし。

wp圧倒してるの事実である根拠は？
事実だとしてそれがjQueryにどれだけ影響してるの？
wpのシェアなんてウェブ全体からすればたいしたことないじゃない

新しいフロントフレームワークが出た時に丸ごとすげ替えれるならなんでもいいよ
俺はMVCがベストバランスの正解だと思うがね

backboneを勉強した人は無駄になった。
Angularも1系を勉強した人は無駄になった。
jQueryは登場してから13年使われ続けている。

これが現実やで

wpの保守死ぬほど大変だけどな。てかフレームワークとwpは全く別物だろうよ。ブログのフレームワークと言えない事も無いが。

>>322
ビルトインされてるよ。テーマによってはwpビルトイン版と競合を避けるため他のバージョンを別に導入する場合もある。
そしてwpのシェアはcms中では60%、全Web中では33%
だからwp除くならjQueryは40%程度だなｗ

> だからwp除くならjQueryは40%程度だなｗ

圧倒的シェアじゃないか！

最初からシェア小さいとは言ってないだろｗ
増加してるのはwpのシェア増につられてだろうと予測しただけ。
おそらく合ってるなｗ
jQueryバカが威張るのは滑稽。

jqueryしか使えないバカが多い
バカのくせにバカを賛美している

所で仮想DOMのアプローチって本当に速いのかな？

仮想DOMはDOMを触らないって言うけど、
結局最終的な形にするためにDOMを構築するでしょう？
そのときに要素を作ったり削除したり

そんな事しないで、CSS使って要素を隠したり表示したほうが速いない？
jQueryはDOM操作が得意なわけだけど、DOMを作ったり削除したりするんじゃなくて
classを変更して見た目を変えることで擬似的にDOMが表示されたり消えたりするって
いうのがベストプラクティスだと思ってる。この場合はDOMの構築をやらないので
仮想DOMのアプローチよりも速いんじゃない？

cssのが早いのは当たり前だろ…
お前、こういうスレ来るのは10年早いよ。
真摯に勉強しろやマジで。スレタイ読まずに荒らしてないでさぁ

VuexとReduxって難易度変わらない？

どちらも単に面倒くさいだけじゃないの？

正直Reduxとか使うよりも、カスタムイベントを使ったほうが楽だと思う

マジでお前来るなよ
スレチクソキチガイが
テメーの妄想なんかどうでもいいんだよ
勝手にjqueryスレ立ててそっちでやれバーカ

だが断る

>>304
そういう観点ならNuxtでもいいと思う

Vueが最強なんじゃね？
仕事ならReact

仕事でもnuxtつこてるわ
angularとreactは敷居が高め
他のメンバーが嫌がるのよ

そういやVueでもjsx使えるとかVueの和書の一番厚い本に書いてあったな

reactのために作ったってだけである種類の関数の入れ子をxml風に記述できるというだけの独立した仕組みだからreact関係なく使えるよ。

>>337
そうなのか。興味湧いてきたのでちょっとNuxt試してみます。

ReactやVueやる奴らは当たり前だがフロントデザインやUXできるんだよな？

>>330
仮想domのメリットは最終的にはリアクティブ。その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、リアクティブでは単に変数をfalseするだけになる。
複雑な入力フォームも恐ろしく作りやすくなるから、一度vueの公式見るといい。

勉強しなくていい言い訳探しに来てる奴に何言ってもムダ

>>344
> その例で言えばjQueryは要素を消すのに.hide()して直接domを操作するが、
あー、それがお前の根本的な間違いなんだよ。
お前っていうか、世間一般？使い方間違えてるんだよね。
そういうDOM操作なんてしません。

jQueryでは単にHTMLのclassの（例えば）activeをdeactiveにするだけになる。
複雑な入力フォームも作れるし、classを変えるだけで全く違った表示にすることができる
そのフォームを使ってる間JavaScriptは全く使用しない。
デザイナが自由に好きなデザインで作ることができる。
そしてjQueryではclassの値を変えるだけになる。

>>343
むしろそっちのが専門や

jQueryのhideはdisplay: noneだろ。
active、deactive（笑）に至っては意味不明。
jQueryではそういうときはactiveクラスをtoggleClassで付けたりはずしたりするんであって、active外してdeactive（笑）つける、deactive（笑）外してactive付ける、なんてマヌケなことはしません。
やっぱりね、自分が勉強したくないもんだから他人の足を引っ張ろうとするような女の腐ったような童貞は自分が上げてるライブラリもまともに使いこなせないｗｗミジメ過ぎｗｗｗｗｗ

jQueryからreactならそこまで乗り換えコストかからんと思うけどな。

>>347
合格

>>348
ん？お前俺が言ったことと大差ないよな？

activeクラスを 付けるor 外す ことで表示の切り替えを行うから
そんなことでDOM操作なんてしないってことだろ？

でそれが>>330で書いたことにつながるんだよ。
仮想DOMは最終的にDOM操作をするから遅くなるが、
jQueryではCSSによって見た目を切り替えるだけだから速いってこと

いやDOM APIを通じて操作するんでしょ

>>352
そりゃVueやReactだって最終的にはDOM APIを通じて操作するよ
ただしその操作の内容を、DOM要素の削除や追加じゃなくて
クラス名を変えて表示を切り替えるだけにすると速いってこと

Angularの方が難しいの？　Reactの方が自由に構成決めたりコーディングしたり出来る分、
自分で決めなきゃいけない事が多くなって逆に難易度高いって聞いたけど。

Angularの方が環境構築も規約も全部世話してくれるから楽だって聞いたからAngularから入ったんだけど。もしかして騙された？

>>354
英語などの単語の暗記が得意だったならangular
数学が得意だったならreact

さすがjQueryバカ。伊達に名前にバカって付いてないな。
クラスの付け外しも厳然たるDOM操作。
そんなことも分からないとは…使われるjQueryもかわいそうだ。

そもそもjQueryのコア機能はDOM操作なんだが…
DOM操作しないならjQuery要らねーよ。
贔屓のライブラリの存在理由否定してどうする。

>>357
DOM操作のうち、class属性を変えるだけにするということ
そしてCSSでブラウザにネイティブ処理させるから速いんだよ
要素の追加や削除は必要最小限にするのが鉄則

>>354
自分がやりたいことと、フレームワークが提供してくれる機能とのバランスだよ

業務アプリみたいに複雑なインターフェースのアプリをガッツリと大量（＝画面数が多い）に
作らなきゃいけないならAngularがいいだろうけど、そうでもないなら
Reactで適当にデータ管理してやれば楽ってこと
Angularはいろんなことを面倒見てるけど、そこまでやることないじゃん？って思うならReact

更に言うならウェブサイトみたいなものはjQueryで十分ってこと

> ネイティブ処理させるから速いんだよ

だったらネイティブのDOM API使うわｗ
You Don't Need jQuery!
https://blog.garstasio.com/you-dont-need-jquery/dom-manipulation/

>>360
それもバランスの問題だな。
そこ見ても分かるだろ？いずれの例もjQueryの方が短く書けている
開発効率の高さがあるからjQueryのほうが良い訳

せっかくだから日本語版
jQueryは必要ない（You Don't Need jQuery）
https://github.com/nefe/You-Dont-Need-jQuery/blob/master/README-ja.md

フレームワークの欠点は単純なウェブサイトでは
生産性を落とすという大きな問題があるってこと

ついでだから、jQueryは必要ない（？）から一例を抜粋

8.7 slideToggle

スライドを伴って、エレメントの表示・非表示を切り替えます。

// jQuery
$el.slideToggle();

// Native
let originHeight = '100px';
el.style.transition = 'height 3s';
let { height } = el.ownerDocument.defaultView.getComputedStyle(el, null);
if (parseInt(height, 10) === 0) {
el.style.height = originHeight;
}
else {
el.style.height = '0px';
}

css tricksのYou Might Not Need jQuery
https://css-tricks.com/now-ever-might-not-need-jquery/

その翻訳
https://coliss.com/articles/build-websites/operation/javascript/now-ever-might-not-need-jquery.html

DOMにノードを追加すると、DOM APIと直接対話するVanillaを1回呼び出すだけで済みますが、jQueryは多くの操作を実行します（スタックが長すぎて画像に収まりません）。違いは明らかです。

Vanilla：4ミリ秒
jQuery：95.3ミリ秒
Vanilla Javascriptは、追加時のjQueryよりも約25倍高速です。

>>367
いや、だからそんなことをしないで、クラスの書き換えだけを
やることで高速化できるって言ってるんだよ
話ついてきてね

>>359
使い分けって言いながらフレームワーク要らないって言うから意味不明になるんだよ
「自分の仕事では」要らないって話だろ？

>>368
class追加するだけでもjqueryより10倍速いんですが？

削除はともかく、追加がクラスの書き換えだけの訳ないわな。その書き換える対象がまだ無いんだから。

jQueryはネイティブに比べて遅い上にサイズも大きすぎる。
画像でもないのに数十kBとかアホか。
短く書けりゃいいのならnanoなど代替ライブラリもある。
nanoのコード例：
$(".someClass").css("background-color:green;").html("Hello World");
$('#c').animate('2.3', '1.2','0','1','1','0','0', '0','0','1').css('background-color:red').text('Hello');

$("#a").on("click", function(){

$("#someDiv").css("background-color:green;color:#fff;");

})

nanoは0.6kB。
jQueryは100倍もコード容量かけて何やってんのｗｗｗｗｗ

ボコボコでワロタｗ
我が物顔でスレチ荒らしするからこうなるｗｗ

>>372
じゃあnano使えば良いんじゃないですか？
フレームワークよりも大幅に小さいし

ウェブサイトではフレームワークは重すぎで生産性を下げるという
大きな問題があるが、jQueryやnanoはDOM APIの冗長性を省くだけだから
生産性は上がるしか無いというのが大きなメリットなんだよ

まあjQueryがいらないのは確かだね。
要素のstyle操作程度ならなおさらね。
「DOM操作しない方がいい」って言ってたし、じゃあDOM操作ライブラリのjQueryはいらないねｗ
え、やっぱりDOM操作したい？そして短く書きたいって？
100倍軽いnanoがあるよｗ

nano信者か・・・

そういやzeptoとかもあったけど、
今までの経験上、軽いだけの代替ライブラリは
結局本家を超えることって無いんだよな
nanoが普及すると良いね

すまん、ガチで話についていけてないんだが、>>351でjQueryは速いって書いてあるからjQueryは速いのか！って思ってたんだけど結局遅いの？

何をもって速いとするかに依る

>>380
速さを求めるときに使うもの？

GitHubがjQuery辞めたので https://ushirock.hateblo.jp/entry/2018/07/28/013507

jQuery が DOM 操作の際に eval() を多用しているため CSP を safe モードで使えないらしい

これは jQuery の核になる部分の仕様らしく、 .html() はどんな時でも任意のコードを実行する可能性があると

やっぱり jQuery といえば Sizzle でのセレクタ解析が遅いとか（querySelectorが使える場合優先されるらしい）ネイティブへの置き換えとかに目が行きがちだけどもこういう深い話でのデメリットもあるんだなと

>>379
jQueryが速いなんて言ってないんだが？
ファイルサイズではフレームワークよりも小さいから
初回ダウンロードは速いだろうけど。

速いって言う話はDOM操作で要素を消したり作ったりするよりも
classを変更するだけにしてCSSで表示したり見えなくしたりするほうが
速いだろうってこと。

jQuery。それは、

・遅い

・重い

・アンセキュア

なDOM操作ライブラリ。

>>382
ソースコードざっと見たけど、evalが見当たらないんだけど何行目にある？
https://code.jquery.com/jquery-3.3.1.js

jQueryを使うのって、速さ云々より一つのコードがどんな環境でも同じ様に動くって所なんじゃないの？

ブラウザの種類やバージョンでJavascriptの挙動の違いがあるから、それを吸収する為にjQueryを使うんじゃない？

>>381
はっきり言ってjQueryが遅いとは思わない
熟練した人が地道に管理すれば十分速い

それが手間じゃねぇの？ってのがフレームワークの意義

>>384
jQueryってDOM APIを使ってるだけなのに
なんでアンセキュアになるの？

>>383
そうか、なんかすまん。

>仮想DOMは最終的にDOM操作をするから遅くなるが、
>jQueryではCSSによって見た目を切り替えるだけだから速いってこと

この部分読んで仮想DOMは遅くてjQueryは速いのか！って解釈しちゃったんだが仮想DOMに比べて速いだけでjQueryも速くないんだな。

>>387

>>367の結果だけ見ると遅すぎ(10回やると1秒！？)って思っちゃったんだが……

webは基本的には静的コンテンツだから気にならない世界なのかな。

とりあえず俺にはこのスレの会話を理解する能力が足りないっぽい。

まあ1つの処理に4ミリ秒って時点で衝撃的な遅さだしweb開発の世界はそんなもんなのか。

jQuery使うと100ミリ秒になるけどなｗ

vue.jsが
やたらめってら、もてハヤサれる昨今だけど
ぶっちゃ毛v-forが仕様としてオワッテると思うわ。
それとuidの生成パターンをC言語なら「ポインターが理解でないワケ」や
「ポインター徹底攻略」、、、JAVAならデザイパターン本みたいな
分厚い本で説明しなきゃ
いけないのに、それを全くやってないよな。
俺が考えるvue.jsが広まらないワケだよ。コンポーネントをどうユーザーが
受けとるべきかも、簡単な再帰などを使ってイラストレートしなきゃいけないのに
これも全くやってない。細々としたシステムは売り込んでるけど
vueの長所が全くされてない

早い遅いじゃなくて開発効率の話だろ。domを直接指定して操作云々はもう止める、最小限にするて事。今後確実にそうなるのは皆分かってると思うが。

実行速度の話をしてる人たちに、いきなり開発効率の話をしだすのは草。なんの関係もないじゃんw

実行速度については、DOM要素を作成したり削除したりするよりも
CSSで表示したり隠したりしたほうが速いんじゃないかってだけのこと
それをやるにはVue/React/AngularよりもjQueryの方が楽ってこと

DOM操作がネイティブよりも速いなんて話はしてない。
CSSによる表示切り替えの方が速いって話をしてる。

そのCSSによる表示切り替えを楽にやる（開発効率が良い）のは
jQueryってだけのこと

DOM要素の追加削除とCSSの表示切り替えって役割が違わね？

CSSの表示切り替えは既に存在する要素に対して行うのに対してDOM要素の追加は動的に要素を追加するためにやるもんだと思うんだが。
この2つは比べるべきものなの？

スレタイの3つとかはSPAのような高性能なブラウザアプリを作成するものでしょ。例えばofficeとかslackとか。CSSの切り替えだけでいけるの？

相手せんでええよキチガイだから。

>>354
難しいというより学習コストが高い＝最低限として覚えなきゃいけない事が多い
その反面必要な機能をサードパーティーから探してくる必要性がかなり低い

>>379
普通にUIとして使う分にはそんなに気になるほどの事でもないけど
Canvasに連続的に描画とか行う場合はダイレクトにその遅さが目立つってくらいかな

早いからじゃなくて便利だからjQueryを使うんだろ。なんで今更速度の話になってんの？

最近ブラウザでWebRTCとかやるのもわりとあるケースだし遅いってのは無視できない問題でもあるよ

>>403
jQueryは仮想DOM操作より早いと信者が言い出したから。

>>405
デマ乙

>>330を見れば分かるが仮想DOMよりも
classの変更で表示・非表示の切り替えをしたほうが速いって言ってる

もう一度聞くけど、classの変更でできることって限られてるでしょ？見た目の操作だけかな？
それが仮想DOMより速くてもどうしようもなくないか？役割が違うんだから。
なんか自分の間違いを認めたくないから無理やり話をすり替えようとしてるようにしか見えないんだが…

>>406
仮想DOMだって属性の値にしか差分がないことがわかったらそれだけ反映するようにはできるだろ。
これなんかわかりやすい。
https://kuroeveryday.blogspot.com/2018/11/how-to-create-virtual-dom-framework.html

スレタイから逸脱しすぎてると思ったらjQueryと比較してる奴がいるのか。。もう何年も前に通り過ぎた話題だぞ。前見ようぜ。

ReactとかVueすら使えない超低レベルなクソジジイが騒いでるだけだから

>>407
> もう一度聞くけど、classの変更でできることって限られてるでしょ？見た目の操作だけかな？

要素の追加削除の代わりに見た目を変更するっていうのは、
単に要素を追加削除するコストだけではなく
イベントハンドラの設定のコストも減らせる

もともとjQueryはデリゲートが簡単にできるから、要素が増えたり減ったりしても
イベントハンドラは最初に一回だけ設定すれば良いんだが、
それを使わなくても例えば要素のonclick属性とかに直接やる場合でも
要素が追加したときに新たにイベントハンドラを設定しなくてすむ

仮想DOMではDOM操作を最適化して必要な場合だけ実行するが
速度の話をするならそもそもDOM操作自体を減らそうという発想にしたほうが良いと思う
要素ごとにイベントハンドラを設定するよりも、
要素の親に一つだけイベントハンドラ設定したほうがいいわけだし

こっちでやったら？

Webフロントエンドで脱jQueryを目指すスレ
http://2chb.net/r/tech/1547896353/

使える使えないと使う使わないは別のこと
jQueryが殆どの場合最適解でSPAが勝てる領域はかなり狭いという事実を見失っちゃいかん

SPA、シングルページアプリケーションであって
シングルページウェブサイトじゃないからな

アプリケーションの時点で、ならネイティブアプリにしろよって
言われる時代

勝手にそんな時代を作るな

まぁ正直フレームワークは知らなくてもいいかも知れんがNodeを知らないと確実に困る時代にはなってくると思う

ネイティヴアプリは環境差異とデプロイメントがめんどくさいんだよね
dockerがGUIをサポートしてくれたら乗り気になるかもしれんがな

>>417
それはウェブでも変わらん。カメラ使おうと思ったら
ブラウザごとに使うAPIは違うし、端末ごとに対応してる
解像度も違うし散々だったぞ

dockerってLinuxの話してる？ それならSnapsやFlatpakなどが登場してる。
Dockerはあくまで開発者向けで自分で作ったアプリをデプロイするときに使うもの。

一般ユーザー向けにアプリを配布するならSnapsなどを使う
GUI対応でディストリ非依存のパッケージ管理システム

>>417
ネイティブの面倒なところはそこよりも
OSの差異で動かなくなったりするところだな特にiOSとか

>>418
Snapsってdockerのように依存関係や実行時の環境もカプセル化してくれんの？

>>419
その差異をブラウザは吸収できないんだよね
だからみんなネイティブアプリにする

みんなって誰だよ
勝手に決めるな

>>411
具体例をお伝えした方がいいのだろうか？
例えばサーバーのDBに対して検索かけてとってきた要素を並べてコンテンツだすとかclassだけでなんとかなるの？
そもそも要素を出したし消したりでなんとかなるような簡単なものにReactとか使わないものじゃね？

サービス提供する側としてはネイティブよりSPAの方がよいケースはままあるでしょ。
例えばインストーラーが不要、そもそも技術者がいない、今までの資産をそのまま流用できる、とかとか。
ハードを限定しないソフトウェアの提供形態って殆どの場合は都合できまるもんだと思う。

ネイティブはストアにリリースすんのがイチイチめんどくさい

jqueryしか使えない無能の自己紹介はいらん
消えろカスジジイ

Angular習得した後にjQueryで書かれたコード見たら吐き気がしてくるわ。

「こんなコードわざわざ書かなくても取ってきたデータバインディングすりゃ良いのに」って思う箇所が多々ある…。

まぁ、古いブラウザでも動くようにしなきゃならないからjQuery使ってんだけどね。

>>427
Windows7のサポートが切れればなぁ

>>427
お前が書くコードがクソなだけｗ

>>428
サポート切れてても「壊れてないから」とか「投資できる余裕がない」とか「基幹システムが新しいOSに対応していないから」って理由で
古いOSと機械を使い続ける客もいるんだよなぁ。あんまりよろしくは無いんだけど。

>>429
jQueryベースでデータバインディングみたいなコード書けるん？
書けるなら書き方教えてくれや。こちとら嫌々でもjQueryとは付き合っていかなきゃなんねーんだよ。

イベント使え

>>430
使ったことないが、backboneやKnockoutやらのIE7でも動くライブラリ使ってみれば？ただ今更勉強する意義を考えると辛いなあ。。

旧ブラウザサポートはお高くなりますよ？
これでほとんどの客が黙る

やっすい案件ほどクソ要求してきやがる。

>>430
少なくともイントラではなグローバルサイトではサポート切れたOSの対応は打ち切っていいだろ

Androidだとサポート切れといっていいOSはどれ？

>>433
最新バージョンのreact使ってるけどIE11で問題なく動作しとる

正直互換性の点ではIE11よりもEdgeの方が癖があるんだよね
まぁEdgeもChromiumベースになる計画があるらしいしEdgeのChromium化とWindows7のサポート打ち切りが来ればパブリックサイトは随分シンプルになるんじゃないかと思う

chromiumになってもなんかしらイレギュラーがありそう
信用できない

フロントエンドなんてそんなもんだとしか言いようがない。

逆に言えば進化の余地ありありと言うこと。でもフレームワーク競争もひと段落して数年は安定じゃないかな。ブラウザもChromiumとSafariに収束されつつあるし。あとはiOS safariにpush通知実装されればなあ。

プログラマには、Apple機がなくなった方が楽になると思われている。
IEが消滅して言ったのと同じ状況がApple機に対しても起きつつあると思う。
iPhoneは売れなくなった。

フロントエンドは端末とブラウザの進化の影響をもろに受けるからねぇ…。

クロスプラットフォームの分野でも、SPAが技術的に枯れる前にどんどん新しいフレームワーク出て来るからな。最近だとFlutterとか。

SPAだけでも選択肢多いのに、xamarinだのcordovaだのFlutterだのと。
こっちとしては「クロスプラットフォームアプリ開発するなら結局どれ選べばいいんだよ」的な状態だわ。

結局、大きい組織が作ったものを使っていくようになるんだろう。

Apple機さえ無視すれば、プログラミングが色々便利になる。

>>443
どれでもいい
フロントは使い捨て
簡単に乗り換えできるようにビジネスロジックと疎結合に作る
そこだけ死守すればなにを使ってもいい

cordova使うならIonicでいいんじゃない？
最近はAngularだけじゃなくVueにも対応したらしいし
そういやReactNativeにもVue版出てたな

vueはreactパクってばっかだな。
storybookもパクってなかったか？
nuxtもnextのパクりだろ？
さすが中国人プロジェクトｗ

別にパクっていてもそれで良くなるなら別に何でもいいけど。ただvueは元Google社員とはいえ中国人でしかも個人開発だろあれ。

いつ開発が止まるかもわからない、信用のない国の人間が作ったもんを率先して基礎にしたがる奴なんているのかな。

vue使いたがる奴なんて、vueを使いたいから使うんじゃなく、技術力低いからvueしか選択肢が無いんじゃないかと。

技術力低くても使えるなんてコスト低くて最高だな

どうせWebComponentsが完成したら
またガラリと世界が変わるんだから
どれ使っても一緒