Vue vs React vs Angular Part.3

**デフォルトの名無しさん** · 2019/06/12(水) 19:04:55.46

実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.2
https://mevius.5ch.net/test/read.cgi/tech/1552136553/
※前前スレ
Vue vs React vs Angular
http://mevius.5ch.net/test/read.cgi/tech/1545395856/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください

**デフォルトの名無しさん** · 2020/06/08(月) 00:09:04.78

PHP、JSP、ASPなどはHTML風のタグ付き文字列の中にプログラムを埋め込む。
これは文字列の切り貼りで済ますなら速いから。
でも決定的な問題点はコンポーネント化に弱い事。
もちろん、それぞれコンポーネント化できるように頑張ってはいるけど、所詮文字列の切り貼りなので、楽ではない。
もっとシンプルにうまくできるのではないか？
そんな風に考えてとりあえずパーサーを書いてみたわけです。

**デフォルトの名無しさん** · 2020/06/08(月) 00:09:30.68

>>760
ちょっと待って探してみるわ。

**デフォルトの名無しさん** · 2020/06/08(月) 00:11:37.73

>>760
あったわ。
https://mevius.5ch.net/test/read.cgi/tech/1547549448/l50

たしか、質問とかにも答えてくれたと思う。
レスポンス悪いけど。

**デフォルトの名無しさん** · 2020/06/08(月) 00:13:02.06

>>761
満足できるものが無いんだ。

**デフォルトの名無しさん** · 2020/06/08(月) 00:20:36.67

>>762
c++のwebアプリケーションフレームワークを作るってこと？？

**デフォルトの名無しさん** · 2020/06/08(月) 00:22:04.06

>>763-764
ありがとう、旅に出て来るわー

**デフォルトの名無しさん** · 2020/06/08(月) 00:27:04.32

フレームワークではなくて、C++らしく部品だけ作りたい。
テンプレートがあるので、出来るだけ組み合わせによって、機能が組み立てられるように。
たとえばTreeの実装はまだ一つしかないんだけど、DOMのように木としてのみアクセスできるTree、木としてもアクセスできるけど（イテレータで巡回中に開始タグと終了タグが現れるような）ノードのリストとしてもアクセスできるようなTreeといった二つの実装を考えてる。
CSS風のアクセス関数を用いる場合、イテレータを通して、どのような実装でも受け入れられる。
そういった自由度の高い部品の一群があると大変便利ではないか？
どうだ！べんりではないか！ふぉおおおおお！

**デフォルトの名無しさん** · 2020/06/08(月) 00:27:26.38

>>767
戻って来いよーーー！！

**デフォルトの名無しさん** · 2020/06/08(月) 00:29:05.02

ちなみにリストとしてもアクセスできる木は名前だけ考えた。
命名tag_tree。

**デフォルトの名無しさん** · 2020/06/08(月) 00:33:41.96

Treeに対して行きがかり順、あるいはレベル順でアクセスできるイテレータ・アダプタも作ってみた。
行きがかり、レベルの変更は、スタックとキューを入れ替えるだけなので、そのまま素直にテンプレート化した。
テンプレート引数は、木のイテレータ、スタック化キュー。
つまりどのような木でもこのアダプタで巡回できる。
というSTLに染まりきった発想ですよ。

**デフォルトの名無しさん** · 2020/06/08(月) 00:36:38.38

まだ作っていないんだけど、DOM木のテキストノードだけを選択的に巡回し、逆参照が文字を返すイテレータもアイデアとしては考えてる。
これで、木に対してstd::regexが使えるんじゃないかと。
作ってないから知らんけど。

どや？べんりやろ？

**デフォルトの名無しさん** · 2020/06/08(月) 02:22:01.75

>>772
ぜんぜん便利だと思わない
C++みたいな生産性の低い言語をwebで使う意味がないから
web frameworkがほとんどないんでしょ

webでやりたいことはほとんどC#でできるはず。
レガシーASPではなくASP.net Coreね
TypeSafeで速くてC++に似てるものといったらC#になる

>>762 みるとレガシーASPしか知らないようにしか見えない

**デフォルトの名無しさん** · 2020/06/08(月) 02:24:56.57

ほお、どんなことが出来るのかね。

**デフォルトの名無しさん** · 2020/06/08(月) 02:34:42.66

Ruby on Rails では、Stimulus が多い。
data-属性で指定する、規約だけのフレームワーク。
ビジネスロジック・HTML の組み立ては、サーバー側だけ

一方、React, Vue.js を使うと、
ビジネスロジックが、クライアント側にも分かれてしまうのが難点

SPA には、Turbolinks という、Pjax(History API のpushState + Ajax)を使う。
Bootstrap を使うには、jQuery, Popper.js が必要

世界最速。この瞬間表示されるサイトも、Rails製！
https://dev.to/

**デフォルトの名無しさん** · 2020/06/08(月) 03:37:31.86

それ速くしてるのはフロントの技術じゃん…

**デフォルトの名無しさん** · 2020/06/08(月) 04:10:32.40

次スレはjQuery禁止で
c＋＋などの他の言語も禁止

**デフォルトの名無しさん** · 2020/06/08(月) 05:55:07.29

>>774
はいどうぞ
ASP.net Coreは進化した
https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcore-3.1#pivot=core

**デフォルトの名無しさん** · 2020/06/08(月) 06:26:59.24

Windowsのサーバー使ってるサイトみるとうわぁって思っちゃうよね

**デフォルトの名無しさん** · 2020/06/08(月) 06:27:35.33

思うだけでそれ以外何も言うことはないけど

**デフォルトの名無しさん** · 2020/06/08(月) 07:46:18.40

なぜ？

**デフォルトの名無しさん** · 2020/06/08(月) 11:10:04.42

>>775
js書かれてる時点でクライアントでもビジネスロジック持ってるんじゃないの？

**デフォルトの名無しさん** · 2020/06/08(月) 12:42:45.82

AD必要ないとこで使ってもお金かかるだけでは。

**デフォルトの名無しさん** · 2020/06/08(月) 13:57:17.63

IT掲示板群 ttp://x0000.net/forum.aspx?id=15

学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net
数学物理学化学生物学天文学地理地学
IT 電子工学言語学国語方言など

simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0
UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0
連続と離散を統一した！
ttp://x0000.net/topic.aspx?id=3709-0
4Dエンジン（画像有り）
ttp://x0000.net/topic.aspx?id=3677-0
matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0
ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0
SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0

PS malloc / free を実装してみた (C#)
ttp://up.x0000.net/files/TMallocTest.zip

**デフォルトの名無しさん** · 2020/06/08(月) 15:33:15.83

ReactのJSXのsyntax気持ち悪いと思って毛嫌いしてたけど
世間の評価は圧倒的にReact >>> Angularみたいだな
理由はどの辺？
エコシステムの充実度
Facebook関与の安心感
React Nativeとかのcross platform対応、あたり

Mobile appまでやりたいとなるとReact Native魅力的だから
Reactやろうかな

**デフォルトの名無しさん** · 2020/06/08(月) 16:01:44.49

理由はAngular1と2で互換性がなくなったせい
ReactもWebComponentができたら互換性なくなる可能性が高い
たとえなくならなくても、作り直しに近いレベルになる

**デフォルトの名無しさん** · 2020/06/08(月) 16:24:12.25

AngularもIonicとやらでモバイルアプリ作れるらしいけどあれどうなん？

**デフォルトの名無しさん** · 2020/06/08(月) 22:47:15.10

>>785
JSXって食わず嫌いで見ると相当ガバガバにJavaScriptとHTMLを混ぜてるように見えるかも知れないけど
実際触ってみれば相当厳密かつロジカルにそれらを混ぜてるって事に気付けると思う

**デフォルトの名無しさん** · 2020/06/08(月) 23:23:04.23

本当に食わず嫌いだったわ
使い始めて如何に理に適っているか痛感した

**デフォルトの名無しさん** · 2020/06/08(月) 23:27:30.20

というだけで、具体的にどこがどう理にかなってるのかを言えないｗ

**デフォルトの名無しさん** · 2020/06/08(月) 23:41:11.35

>>762
Ruby のテンプレートエンジン・ERB では、<%= Rubyの式 %>
と書くだけで、< > などのHTML特殊文字がエスケープされるので安全

テンプレート内では、サイトで共通の、ヘッダー・フッターなどの部分テンプレートを読み込む。
つまり、React, Vue.js と同じく、部分ごとに作っている

SASS も同様で、パーシャル

Vue.js では、HTML・CSS・JavaScript が、1つのファイルになっている点が異なる

>>768
libxml2・sax2 などのイベントベースの木が使いにくいから、

Ruby のNokogiri みたいなパーサーができた

**デフォルトの名無しさん** · 2020/06/09(火) 00:51:32.15

>>786
WebComponent対応で大幅に変わるというアナウンスあったの？

古いAngularの互換性の問題は聞いたことがあった。

JavaScript関係はほかのライブラリ、Frameworkも5年後には存続してるか
わからないし、あったとしても大幅な書き直しなんじゃないのかな

**デフォルトの名無しさん** · 2020/06/09(火) 00:57:45.90

ReactはMVCでいうところのViewだけらしいけどReactで
MySQLとかのRDB使うWeb Appを作るためにはどの辺が必須になるの？

Reduxで状態管理
Router?でルーティング、くらいはわかった。
他に習得必須いえるようなReactまわりのライブラリ、フレームワークはある？

**デフォルトの名無しさん** · 2020/06/09(火) 01:04:46.52

Ruby on Rails では、Stimulus が多い。
data-属性で指定する、規約だけのフレームワーク

SPA には、Turbolinks という、Pjax(History API のpushState + Ajax)を使う。
Bootstrap を使うには、jQuery, Popper.js が必要

React, Vue.js も使う

**デフォルトの名無しさん** · 2020/06/09(火) 01:47:24.03

はい？ちがいますよ？
これからはHTMLパーサーの時代です。

**デフォルトの名無しさん** · 2020/06/09(火) 07:18:30.40

>>791
お前は一生バックエンドのテンプレートエンジン使ってろ

**デフォルトの名無しさん** · 2020/06/09(火) 08:53:48.06

>>793
バックエンドは好きな奴を使えばいい
俺は非同期API通信にはaxios使ってる
firebase使えばもっと楽かも

**デフォルトの名無しさん** · 2020/06/09(火) 09:38:30.45

かよちんかわいいよなちんちんいれたい

**586** · 2020/06/09(火) 10:10:11.13

かよちんって、

>>586
の、プログラミング未経験で、Ruby on Rails でポートフォリオを作った娘か？

ひょっとして、ポートフォリオではなく、可愛いから受かっただけかもw

**デフォルトの名無しさん** · 2020/06/09(火) 11:00:57.58

>>797
Thanks. axios調べてみる。

firebaseってクラウドか
クラウドに高いかね払うのもったいないしDBも自分で設定して運用したい
サーバー設定できない企業増えてるのかね
クラウドサーバー、トラフィック極小でない限り維持費高すぎると思うわ

**デフォルトの名無しさん** · 2020/06/09(火) 11:15:33.79

>>799
面接でセイコウした理由は言ってる
https://www.youtube.com/watch?v=mEOq2H2WX-c

**デフォルトの名無しさん** · 2020/06/09(火) 12:46:38.84

>>796
君の頭が悪いのは仕方がないことなんだけど、せめてそれを自覚して大人しくしててくれないかな

**デフォルトの名無しさん** · 2020/06/09(火) 16:52:47.12

JavaApplet復権の日は近い

**デフォルトの名無しさん** · 2020/06/09(火) 19:12:23.43

公式みたけどVueはcross platform対応がない
TypeScriptも対応してないようだし
中長期では人気は落ちる一方じゃないかなあ

Vueの強みがよくわからん

**デフォルトの名無しさん** · 2020/06/09(火) 20:46:49.49

cross platform対応とは一体…

ネイティブ対応っていいたいの？

**デフォルトの名無しさん** · 2020/06/09(火) 21:01:47.11

Vue3でts書きやすくなるといいなあ

**デフォルトの名無しさん** · 2020/06/09(火) 21:51:18.91

C++ HTMLパーサーおじさんのはどんな機能があるの？
入力がHTML文字列で出力がDOMツリー？
HTMLって一部のタグを省略できたりするじゃん？
出力されるDOMツリーが正規化される（省略されたタグが適切に構成される）ならちょっと興味がある
あと入力されるHTML文字列自体がおかしい場合はどうなる？

**デフォルトの名無しさん** · 2020/06/09(火) 21:52:40.32

ついでに既存のHTMLパーサー・フォーマッターと比べてのメリットは？

**デフォルトの名無しさん** · 2020/06/09(火) 21:54:42.37

>>807
そこを仕様通りの実装にした。
仕様通りという部分が重要だったんだよ。

**デフォルトの名無しさん** · 2020/06/09(火) 22:03:38.41

仕様通りで良いのかどうかという議論はまだ残っていると思うが。
とにかくブラウザが実装する仕様と全く同じ通りに動作するパーサーが出来上がった。
いまはその状態。

**デフォルトの名無しさん** · 2020/06/09(火) 22:08:45.48

>>805
ネイティブ対応とはちがうよ
cross-platformといったら
iPhone app, Android app, Windows appなどにも対応できること。

cross-platformはNative Appと同義ではない。
「Nativeの動作ではないけどAndroidなどで動く」とかいうのもcross-platformに入る。
IONICとかで開発されるhybridとか呼ばれるアプリみたいなやつ。

IONICならAngularとReactは正式に対応してる。
まあReactならReact Native使えるからIONIC選ぶ必要あるかは不明だけど
https://ionicframework.com/

**デフォルトの名無しさん** · 2020/06/09(火) 22:22:40.60

ちなみにHTML5仕様は<pre>の後に続く二つの改行を一つに縮小したり、<head>が現れるまでの空白文字を無視したり、</body>以降の空白文字を前に移動したり、もしすると不都合な項目もあるけど、それも仕様通り。
そして、よく使われているChromeも仕様通りの実装となっている。

**デフォルトの名無しさん** · 2020/06/09(火) 22:23:29.14

>>810
どんな特徴付けをしたかったから自分で作ったの？
Chromiumとかからパーサー引っこ抜いて来なかった理由が知りたいな
単なる車輪の再発明なら安定性の面で不安があるし使いたいと思う人もいなさそう

仕様通りに作っただけでホントに何の特徴もないの？

**デフォルトの名無しさん** · 2020/06/09(火) 22:25:14.27

adoption agency algorithm や省略されたタグの補完ももちろん仕様通り。
つまり、Chromeと同じ動作。

そこが俺的に重要だった。

**デフォルトの名無しさん** · 2020/06/09(火) 22:26:12.36

>>813
STLのような組み合わせられる部品というのが重要だからさ。

**デフォルトの名無しさん** · 2020/06/09(火) 22:26:32.00

質問に何一つ答えない。つまり実装することが目的だったからだ

**デフォルトの名無しさん** · 2020/06/09(火) 22:27:12.58

An HTML5 parsing library in pure C99
https://github.com/google/gumbo-parser

**デフォルトの名無しさん** · 2020/06/09(火) 22:27:54.14

Fast C/C++ HTML 5 Parser. Using threads.
https://github.com/lexborisov/myhtml

**デフォルトの名無しさん** · 2020/06/09(火) 22:28:31.86

>>813
HTMLのような論理的でない仕様は使われなければ安定性を得られない。
これはChromeであろうと、オレオレパーサであろうと事情は同じ。
もちろんChromeは実績があって安定してるけど。

**デフォルトの名無しさん** · 2020/06/09(火) 22:29:16.85

Comparison of HTML parsers
https://en.wikipedia.org/wiki/Comparison_of_HTML_parsers

いろんな言語で50個ほど。そのうちHTML5対応は13個

**デフォルトの名無しさん** · 2020/06/09(火) 22:29:37.47

>>817
Gumboは研究した。
これは良いモノ！と言えるのは、使ったことが無い人だけだと思います。

**デフォルトの名無しさん** · 2020/06/09(火) 22:30:35.30

これだけは言える。
Gumboはキミのアプリケーションには使えない。

**デフォルトの名無しさん** · 2020/06/09(火) 22:31:00.66

HTML5でそれまでの（IEの）実装と矛盾なく厳密に仕様が決められた
不正なHTMLの扱いなど異なる解釈ができる余地を無くしたので
HTML5に対応するのは簡単。決められた仕様通りに作ればいいだけ

**デフォルトの名無しさん** · 2020/06/09(火) 22:31:27.41

>>822
> Gumboはキミのアプリケーションには使えない

実際にはお前が使えなかったんだろｗ

**デフォルトの名無しさん** · 2020/06/09(火) 22:32:37.11

>>824
もちろん俺は使わないよ。
だからパーサーを書いたんだよ。

**デフォルトの名無しさん** · 2020/06/09(火) 22:32:57.05

ライブラリなんて汎用的に使えるよう機能が揃っていることが重要で便利さは二の次だと思うけどな。使いやすさは各自ラッパー書いて整備すればいいし。
ライブラリそのものにゴテゴテ機能をのせると逆にわかりにくくなるイメージ。

**デフォルトの名無しさん** · 2020/06/09(火) 22:34:36.16

>>825
使わないんじゃなくて、お前に使う能力がなかったという話

**デフォルトの名無しさん** · 2020/06/09(火) 22:34:36.32

>>825
パーサーって言ってるけど、要はXMLパーサーをブン回す便利関数の集まりなんじゃないの？

**デフォルトの名無しさん** · 2020/06/09(火) 22:35:08.77

>>826
俺もその通りだと思う。
だから、組み合わせられる部品であるべきだと考えた。
アルゴリズムの部品化に何が必要か考えると、結局STLに行き着く。
非常にSTLと似たアプローチをとって実現した。

**デフォルトの名無しさん** · 2020/06/09(火) 22:35:19.44

>>819
うーん、ごめんね話が噛み合わないみたいだからおじさんのパーサーに興味持てなくなっちゃった
すごいね、くらいの乾いた感想しか出てこないです
もう興味ないからパーサーの話は終わりにしよう

**デフォルトの名無しさん** · 2020/06/09(火) 22:35:40.19

>>828
HTML5パーサーだって。

**デフォルトの名無しさん** · 2020/06/09(火) 22:36:02.94

>>830
はい、じゃあ終わりで。

**デフォルトの名無しさん** · 2020/06/09(火) 22:36:37.42

GoogleがHTML5構文解析ライブラリGumboをオープンソース化
https://www.infoq.com/jp/news/2013/08/google-gumbo-html5/

プロジェクトの説明ページによると、Gumboを公開する目的は、
軽量なHTML構文解析ライブラリを開発者たちに提供することだ。
Gumboは、外部に依存せず、大部分の言語から呼び出すことができる。
このライブラリは、ウェブページ検証、静的アナライザ、
テンプレート言語、リファクタリングツールなどに入れられるだろう。

**デフォルトの名無しさん** · 2020/06/09(火) 22:36:54.30

将来追加される機能の一部は以下の通りだ。

テンプレートタグをサポートするという最近のHTML5スペックの変更をサポートする
フラグメント構文解析をサポートする
フル機能を持つエラー報告
他言語と結びつける

**デフォルトの名無しさん** · 2020/06/09(火) 22:37:35.40

>>831
よくわかってないんだけど、HTMLパーサーってXMLパーサーにどんな機能が追加されてるの？

**デフォルトの名無しさん** · 2020/06/09(火) 22:38:34.73

すまん、gumboとやらの説明読んでくるわ

**デフォルトの名無しさん** · 2020/06/09(火) 22:39:51.76

>>835
HTMLはXMLとは違う。XMLはタグの規則が決まっているが
HTMLはその規則に従っていない

**デフォルトの名無しさん** · 2020/06/09(火) 22:47:22.81

>>837
すまん、なぜかずっとXMLはHTMLの上位概念だと勘違いしてたわ。歴史的な勘違いだわ。

**デフォルトの名無しさん** · 2020/06/09(火) 22:48:51.54

>>811
ブラウザで動くのだからすでにcross platformじゃん

**デフォルトの名無しさん** · 2020/06/09(火) 22:54:35.06

>>838
HTMLは必要ないタグの省略ができるなど手書きする上で便利なマークアップ言語だった

それをある時コンピュータで処理しやすくするために、便利な書き方をなくそうぜ！と言い出した。
そう言ってできたのがXHTML。←これは全くのやくたたずで廃止された
なぜなら人間が読むために作られたHTMLを機械で（生成することはあっても）処理することはなかったからだ

そして解釈の幅があったHTMLの規則を厳密に定めたのがHTML5

HTML5の素晴らしい点は、過去のブラウザにこれからはこの規則だから合わせろや！
と強制するのではなく（強制したのがXHTML）
過去のブラウザの実装を元に仕様を作った
だから古いブラウザ、特にIE6とかも実質HTML5対応と言える

**デフォルトの名無しさん** · 2020/06/09(火) 22:55:20.55

少し訂正

そして解釈の幅があったHTMLの規則を厳密に定めることで
コンピュータで処理しやすくしたのがHTML5

**デフォルトの名無しさん** · 2020/06/09(火) 23:01:09.63

>>839
ここweb frameworkのスレッドでしょ
web developerがcross platformといったらふつうはsmartphone appは最低限含まれる
Browserならどこでも動くがそのレベルでいい時代じゃない

使いやすさやperformanceを追求するとやはりBrowserでなくappになる
大手はだいたいsmartphone app出してるでしょ

>>838
XML対応してる、xhtmlとかいうのもあったな

**デフォルトの名無しさん** · 2020/06/09(火) 23:01:51.35

>>840
分かりやすい説明ありがとう
(・∀・)ｲｲﾈ!! +1

**デフォルトの名無しさん** · 2020/06/09(火) 23:06:43.15

今も覚えてるよ。2000年頃。俺が学生だった時代
XHTMLの勉強会だがセミナーだかあって言ったんだが
HTMLがXMLだとデータとして再利用しやすくとか言っていたが、

当時XMLからXHTMLにXSLT（これ自体もXML）で変換して
データからHTMLを作るぞーって、面倒なだけで何もメリットねーじゃねーか
って知ってた俺は、

そのセミナーの話を聞きながら、うん。でもHTMLには広告とか入っていて
XHTMLをデータとして再利用するなら、最初からXMLを提供したほうがいいよね
HTMLがXMLである必要性はないよね思ってた。

それから数年後HTML5が登場して、俺の考えは正しかったことが証明された。

**デフォルトの名無しさん** · 2020/06/09(火) 23:15:23.10

htmlは歴史的にはsgmlで定義されてからな
まあ目的ちょっとちがってきたしな

**デフォルトの名無しさん** · 2020/06/09(火) 23:25:27.45

>>842
独自定義なら先にそう説明してね

**デフォルトの名無しさん** · 2020/06/09(火) 23:45:58.07

初歩から学ぶHTML講座をやっていると聞いて

**デフォルトの名無しさん** · 2020/06/09(火) 23:56:51.88

HTMLとCSSの理解はjQueryを使うのに必須だからね
jQueryが使いづらいって言ってるやつほど
HTMLやCSSを理解せずDOM操作を使って実装しようとする

jQueryの本質は宣言的言語であるということ
セレクタが使えるだけじゃない、
書き方そのものがCSSと類似している
例えば

.alert { color: red; } というCSSをjQueryでやるなら
$('.alert').css({color: 'red'}) となる（念の為に言うと直接CSSを定義するのは推奨しない）

CSSと同じでクラスに対して一括して属性を適用している。
この宣言的であるCSSと同じように、イベントハンドラも一括適用できるわけ

VueなどのフレームワークはDOM操作を簡単にするものだが
jQueryはDOMを操作するのではなく宣言的に
記述できるライブラリと言ったほうがより正確だろう
だからHTMLとCSSへの理解がより重要になる

**デフォルトの名無しさん** · 2020/06/10(水) 00:16:48.50

いや、これからはHTMLパーサーの時代ですよ。

**デフォルトの名無しさん** · 2020/06/10(水) 00:22:12.77

jqueryではWebアプリは作れないのでWebアプリを作るためにReactやAngulerを使うべき
ゴミクズjqueryなんか議論するまでもない

**デフォルトの名無しさん** · 2020/06/10(水) 00:26:05.60

なんでウェブアプリを作らないといけないと思ってるんだろうｗ

**デフォルトの名無しさん** · 2020/06/10(水) 00:27:28.29

うめ

**デフォルトの名無しさん** · 2020/06/10(水) 00:27:41.07

うめ

**デフォルトの名無しさん** · 2020/06/10(水) 00:27:59.11

うめ

**デフォルトの名無しさん** · 2020/06/10(水) 00:28:32.43

マルチポストではありません

**デフォルトの名無しさん** · 2020/06/10(水) 00:28:43.92

マルチポストではありません

**デフォルトの名無しさん** · 2020/06/10(水) 00:28:58.94

すまん、誤爆してた…

**デフォルトの名無しさん** · 2020/06/10(水) 00:30:02.23

最後までやれや

**デフォルトの名無しさん** · 2020/06/10(水) 00:38:26.80

いけないってなんだよ？
作らない奴に用はねえからここに来るな

**デフォルトの名無しさん** · 2020/06/10(水) 01:49:21.69

>>846
いや、各社のサイトでその表現つかってるし独自でもない

browserならなんでも動くわけだからcross platformといったら
applicationだと気が付くのが普通

**デフォルトの名無しさん** · 2020/06/10(水) 07:14:53.99

>>791
イベントベースのHTMLパーサーというのは、本来有り得ないんだよ。
一度木を作っているか、もしくはHTML仕様を満たしてていないはず。

**デフォルトの名無しさん** · 2020/06/10(水) 07:41:14.43

マークパンサー