Vue vs React vs Angular
■ このスレッドは過去ログ倉庫に格納されています
実際どうなん? Vue https://jp.vuejs.org/ React https://reactjs.org/ Angular https://angular.io/ VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured SPAフレームワークでSSRが醸し出す、一周回ってMVCフレームワークに戻ってきた感が笑える スレタイのやつ3つとも触ったことないままAureliaってやつを採用しようと思ってるんだが、お前らの評価はどんな感じ? 採用の理由としてはVueが選ばれるのと同じだと思う 調べてみたら3年くらい前にちょっと流行ったみたいだけど 未だに話題になってないって事はそういう事なんじゃない? 流行り廃れでフレームワークを選ぶんじゃねえ! 自分に一番合ったフレームワークを選ぶんだ! https://jquery.com jQuery: The Write Less, Do More, JavaScript "L i b r a r y". ライブラリであることに負い目でもあるのかな?w フレームワークの流儀を押し付けられず、どこでも好きなように自由に使えるのがライブラリの強みだと言うのに。 どこ見て負い目があると感じたんだ? ライブラリだからライブラリって書いてあるだけだろう angularはwebエンジニア以外の血が流れてるんじゃないのか?ゲームエンジニアでhtmlもjavascriptも経験がなかったときの俺には非常に使いやすかった。 web関連の経験値がたまってきた今となっては大がかりに感じちゃってあえて使おうという気はでないが… フレームワークと言われるのがウゼーから強調してると思うが Reactもライブラリって名乗ってるな 結局MVC+jQueryが一番バランスとれてんだよな SPAなんて作る側にも使う側にも画面遷移が超早いぐらいしかメリットねえもん >>197 それは流石にSPA作った事無いやつの暴論 jQueryの功績は確かに大きい。その次の世代として仮想domありきのvueやreactなんだから、jQueryとの比較は意味が無い思う。 大雑把にいうとライフサイクルメソッドみたいなイベントとか状態管理などの枠組み含むものがフレームワークで 枠組は使用者が作って機能を呼び出すのがライブラリだろ >>199 > 仮想domありきのvueやreactなんだから、 仮想DOMはメリットじゃないよ フレームワークの設計上どうしても遅くなるという問題を 回避するための手段でしか無い 遅くなければ仮想DOMなんて無いほうが良い そういやスタイル側のフレームワークって何がいいの? 基本はBootstrapなんだろうけど やりこめば やるこむほど 思うけど、vueは簡単じゃあないと思う。 よう分からんけど、日本じゃ wasm は話題にならないね。 情報が遅れてるんだろうか? wasm盛り上げたいgoogleもjs速くし過ぎたと後悔してることだろう wasmが必要となるようなものは、 ウェブじゃなくてアプリにするから なるほど、日本では、「JavaScript を高速にしたもの」と思われている段階なんだね。 アメリカではパラダイムシフトが起きると思われているらしく、色々と恐れられて いたりもするらしい。 >>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を使えば良いわけだし HTML5によってFlashなどのプラグインが死んでいったり JavaScriptからカメラやマイクにアクセス出来るようになったりとそれなりに影響があった WebAssemblyはそれらをさらに強化する JavaScriptでは限度があった動画/音声データのリアルタイム解析なども可能になる プラグインが死んだUnityも今はWebGL+WebAssemblyで動く プラグインでバラバラ対処してたことが標準化されたって感じかね 劇的に変わる、と言うのはちょっと違う気もするが HTML+CSS+javascriptでの開発って他の分野に比べると独特だから実は参入障壁高いんだよね。使いこなせないだけなのに技術そのものがショボいと言いだす。 だからwebフロントエンド以外の開発者がwebフロントエンドの開発したくなったときにいろんな手法を見つけて何とかしようとするんだけど、なれてくると別にHTML+CSS+javascriptでいいやってなる。 そんなイメージ。 メモリの扱いというかデータの受け渡しがだるいから、TypedArrayに対して高速に計算するだけの何かを導入してくれたほうがマシだった wasmってiOSとAndroidに対応してる(する)の? んなことよりpush通知実装しろ。iOS safariテメーのことだ。 >>225 JVM の代わりとなる仮想マシンと考えた場合、C++ で書けることは重要なんだ。 C++は型があるので、ミスをコンパイラが発見してくれる事が多いから。 例えば、JSだと関数の引数が多くても少なくてもエラーにならない場合がある と思うけど、C++では敢えて分かっていてそうする場合以外は必ずエラーになる。 C++ では整数型を受け取るつもりの仮引数に浮動小数点型の実引数を渡すだけでも エラーになる。ところが、JavaScript ではエラーにならない。 このようなことがあるので、JavaScirpt は大規模アプリをC/C++で組んだことの 有るプログラマからは嫌われている。特にアメリカで。 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万行も有る プログラムの場合、この間違えて書いてしまった行を探し出すのに苦労することになる。 ミスったw デストラクタの中で解放する1行を書き忘れた場合、それでも動くから どこかで不具合が起きるだろうが、ソースが何10万行も有る プログラムの場合、この間違えて書き忘れた行を探し出すのに苦労することになる。 >>253 std や auto_ptr を使うから難しく感じるんだよ。 何度も言うが、それは C++ ではない。これはマジ。 今の std:: 系のライブラリはSmalltalk の信者が作ったものらしい。 C++ の標準化委員会がおかしなことになっていて、もはや、本来のC++ ではなくなってきており、だから、C++が難しいと感じる人が増えている 気がする。 >>257 クラスが 100種類の場合、デストラクタは 100 個しかない。 だから、ソースが数10万行あっても、100箇所を調べるだけで済むよ。 >>260 調べる箇所が100箇所でも 何を解放し忘れたかを確認するのは大変 >>259 日本だと auto_ptr みたいなのが C++ だと思ってる人がいるけど、 勘違いだよ。 stdなんちゃらを使わなかったら バッファオーバーランで脆弱性になるし それでも動くから どこかで不具合が起きるだろうが、ソースが何10万行も有る プログラムの場合、この間違えた行を探し出すのに苦労することになる。 >>261 だから新しい言語を次々に覚えて C/C++ だけは覚えないで過ごしてきたのかな、 あなたは? 数十の言語を覚えるより、C/C++ を1つ覚えるだけが良いと思うよ。徹底的に それだけを学んだほうが良い。 >>262 勘違いとかそうでも良いわw auto_ptrが使えて、実際にauto_ptrが使われるがC++だから >>264 はいそうですね。C/C++は数十の言語を覚えるのと同じぐらい苦労しますもんね いろんな言語の機能をキメラのように組み合わせた言語ですから 人によって書き方がぜんぜん違う auto_ptrを使ってるだって!?これC++じゃないよ! って言う人がいるぐらいだから だから開発効率が悪い さもTypeScriptが競合であるかのように突っかかってきてるが全く的外れ。 TypeScriptのトランスパイルターゲットはJS。 競合はその他AltJS。 この中では既に天下取って安泰。 C++のコンパイルターゲットはWASM。 競合はRust、Kotlin、.NET、、、どんどん増えるぞw がんばってな!w もちろんナマの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 だけに 限定するってことは、他の人がそれをめちゃくちゃにしないってことで、 ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい 「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる