20/12/26 17:25:22.32 3y5CuLti.net
>>660
だから、言語を選ぶ条件なんて様々だろうに。言語自体の機能、開発しやすさ、環境、あるいは開発者を
集めやすいとか過去の資産の継承とか。
それらを踏まえたうえで要求を満たせる言語ならスクリプトとかそうじゃないとかこだわる必要はないと思うが。
>メリットないのにベンチマークで遅いとわかってる言語を選ぶ理由はないでしょう
そこでベンチマークという指標だけを特別視する理由があるのかということと、そもそもそのベンチマークの
成績がどれだけあればいいのかとか、そういう基準をもって選択しているのかと。
672:デフォルトの名無しさん
20/12/26 17:25:26.09 Y46mRX42.net
C#はJSの2倍程度しか早くないですよ。
Cなら一桁違う事もあるけど
673:デフォルトの名無しさん
20/12/26 17:26:02.76 nir8tHzM.net
>>654
JavaはポストCOBOLのポジションだからもう生産性やパフォーマンスを期待してはいけない
ちなみにC#は非同期処理が得意な言語の筆頭だよ
非同期処理を実用レベルの高生産性まで最初にもっていった言語はC#
JSやその他の言語がイベントドリブンのコールバック連鎖で気持ち悪い非同期処理をシコシコ書いてた時代にC#では真っ先にReactiveExtensionやAsync/Awaitを実装した
C#はライブラリの非同期対応も最も充実している言語の1つだ
JSやその他の言語では未だに非同期ライブラリがコールバックしかサポートしていないといったことも珍しくない
674:デフォルトの名無しさん
20/12/26 17:28:35.04 nir8tHzM.net
>>662
言ってることは間違ってないけどどの要素をとってもC#が最強なのでな
675:デフォルトの名無しさん
20/12/26 17:37:12.79 3y5CuLti.net
最初から「俺はC#が好きだ」って言ってればそこで終わってた話。
足りない頭でもっともらしい理屈をつけようとするからおかしなな話になる。
676:デフォルトの名無しさん
20/12/26 17:37:18.38 A5wLytvy.net
>>661
C#とJavaを引き合いに出したいのなら、ハマーぐらいかな。
確かに頑丈だしそれなりに走るけど、それが要るかと聞かれれば疑問符。
俺もC#はよく使うが、楽さは全然違うぞ。
Goとかと比べると、遥かにC#はめんどくさいし、そもそもC#は.net coreでAOTかけてても起動遅い。
677:デフォルトの名無しさん
20/12/26 17:40:22.14 abA8NdUG.net
>>667
Goも楽で速いがC#とは方向性が違うので共存できる
678:デフォルトの名無しさん
20/12/26 17:42:22.62 nir8tHzM.net
いずれにせよバックエンドでスクリプトを使うメリットは
ない
679:デフォルトの名無しさん
20/12/26 17:45:37.56 UNoc468U.net
ジャッジが居ないから結論が出ないんだよね。
・>>1が進行役のMCやる。
・MCがジャッジを三名指名する。
・棄権も許容して、ドローになる場合クラウドにゆだねる。
・MCは、クルーが大技を繰り出してきたとき、Yeah! や WoW! HoHo! など適切に合の手を入れる。
・7 to smoke ルールで、7勝した奴が勝ち。
680:デフォルトの名無しさん
20/12/26 17:49:44.17 vt3FfngW.net
おまえらphpもスクリプトだってこと忘れて議論してるな
メリットなかったら普及しないだろ
681:デフォルトの名無しさん
20/12/26 17:50:33.74 BjZvExSE.net
C#おじさんは狭い知識から屁理屈捏ねて勝利宣言繰り返すだけの人だから。お手本通りの老害
682:デフォルトの名無しさん
20/12/26 18:11:05.74 nir8tHzM.net
>>671
当時は高級言語の選択肢が少なかっただけだ
683:デフォルトの名無しさん
20/12/26 18:14:32.55 UNoc468U.net
Windowsで使えた、レンタルサーバで使えた。
需要にこたえていた。
我わ正義なり我に従えってRubyより流行ったのは当たり前だった。
684:デフォルトの名無しさん
20/12/26 18:22:33.03 A5wLytvy.net
>>669
使いこなせません、と言うことだな。
それはC#が好きなんではなくて、C#しかできないんだろ。
C#に謝れ。
685:デフォルトの名無しさん
20/12/26 18:30:08.64 bYNEuO+K.net
C#おじさん邪魔だからBlazorでも使ってろよ
686:デフォルトの名無しさん
20/12/26 18:35:47.28 T66JFeJq.net
Blazorスレと似たような展開だが、あっちはスクリプト系クソ
こっちはC#,Javaクソ
理由はどちらもパフォーマンスや生産性が～
これはもう宗教だな
687:デフォルトの名無しさん
20/12/26 18:41:30.60 abA8NdUG.net
>>675
使うメリットがないと言ってる
日本語わかる？
688:デフォルトの名無しさん
20/12/26 18:45:16.11 UNoc468U.net
Javaはライブラリの勝利じゃないだろか。
企業で使う場合、認証が一番厄介な部分だと思うけど、Javaはそこがしっかりしてた。
GlassFishを試用してみたけど、軽くは無かったな。
689:デフォルトの名無しさん
20/12/26 18:47:15.38 Xky1/n2X.net
C#は別にクソじゃないよ。一人で狂信者やってるC#おじさんがクソなだけ。
使ってる用語や説明の仕方に癖があるからわかりやすい
690:デフォルトの名無しさん
20/12/26 18:49:31.55 T66JFeJq.net
>>680
癖があってわかりやすいんですか！
691:デフォルトの名無しさん
20/12/26 18:53:53.93 A5wLytvy.net
>>678
メリットを知らない、と言うことだなって言ってるの。
逆に言えばC#のメリットも、本当に両方で作った上でメリットを感じた事があるかどうかすら怪しいもんだ。
知らない物は、無いに等しいわなって単純な話で、おっさんが哀れなだけだよ。
だからC#に謝れって言ってるんだが。
日本語わかる？
俺もC#好きで、それこそFW2.0の時に「良くも切り捨てやがったな…」とか恨んだレベルで年季入ってるけど、他の言語のメリットもちゃんとプロダクト出すレベルで使って判断できるつもりだぞ。
692:デフォルトの名無しさん
20/12/26 18:55:06.83 rNbO8nf2.net
>>646
そうだよ
693:デフォルトの名無しさん
20/12/26 18:56:22.81 abA8NdUG.net
>>682
メリットがないといってんだ
無いもんを知ってるわけ無いだろ
ないんだから
694:デフォルトの名無しさん
20/12/26 18:57:06.62 A5wLytvy.net
>>684
可哀想な人だな。
C#のデメリット言ってみ。
無いと言うならもう言う事は無い。
695:デフォルトの名無しさん
20/12/26 19:08:20.63 UNoc468U.net
1万円のBluetoothより300円の有線のほうが音良いからね。
696:デフォルトの名無しさん
20/12/26 19:12:49.05 8Nevj14A.net
C#おじさんBlazorスレでも鼻つまみ者じゃん……
697:デフォルトの名無しさん
20/12/26 19:16:07.29 UNoc468U.net
安くてもシャープはシャープ（腐っても鯛みたいな感じで）だけど、安いソニーはアイワだからね。
698:デフォルトの名無しさん
20/12/26 19:16:17.08 abA8NdUG.net
技術の話から逃げる連中ばっかりだなここは
699:デフォルトの名無しさん
20/12/26 19:23:32.52 T66JFeJq.net
C#のメリットデメリット
script系のメリットデメリット
向き不向きを知った上で正しい技術選択をすべきだな
Blazorは出来たてほやほやなので、フロントをやるとしたらjs系言語一択になるだろう。
サーバーもjs系言語にした方が技術者も集めやすいというのが一番のメリットだとおもう。
ただ、重ためのバッチ処理が入るような企業向けシステムには向かない。
エクセル管理してたものをWebシステム化する程度のものに向いている。
どうだ！
700:デフォルトの名無しさん
20/12/26 19:28:33.38 wnNA/ljl.net
>>689
お前さんが一番技術の話して無いじゃん
701:デフォルトの名無しさん
20/12/26 19:35:53.32 A5wLytvy.net
>>689
自己紹介ですか？
デメリットは？
702:デフォルトの名無しさん
20/12/26 19:42:12.23 BjZvExSE.net
685がわざわざ明確な評価基準出してくれてるのに無視してて草
>>690
> エクセル管理してたものをWebシステム化する程度のものに向いている。
それって個人の感想ですよね？
クックパッドがNext.js採用したそうですよ
703:デフォルトの名無しさん
20/12/26 19:47:23.61 Me3WzmOr.net
そういえばvueの人気が低下してきてせっかく抜いたangularに逆転されそうってマジですか？
704:デフォルトの名無しさん
20/12/26 19:53:47.56 T66JFeJq.net
>>693
個人の感想だよ
間違ってたら訂正してくれ。
クックパッドのサイトは条件に合うデータとってきて表示するくらいの要件だよね
あと個人が一件一件データを出し入れするだけの要件なら向いてる
裏で大量データの計算したり、帳票生成したりするのに向いてないのではなかろうか。
（個人の感想です）
705:デフォルトの名無しさん
20/12/26 20:01:15.31 A5wLytvy.net
>>695
帳票作成、最近うちはnodeベースのpuppeteerでPDF書き出すものを試験的に作ったけど、めっちゃ良いよ。
言うほど重くない上に、そこそこのクオリティの帳票が描ける。
というかクオリティに対する重さが極小なのと、帳票作成のしんどさが相当軽減されてる。
iTextSharpとか使ってたのが地獄だったかのような感じ。
ただどうやっても背景が透明ではなく、白い板になってるのがなんとかならんかなって思ってる。
706:デフォルトの名無しさん
20/12/26 20:05:37.15 BjZvExSE.net
>>695
でもクックパッドは凄いアクセス数を捌いてるよ？
> あと個人が一件一件データを出し入れするだけの要件なら向いてる
クックパッドのページ見てから語ろうね
というか貴方はC#のデメリットをちゃんと答えてあげなよ。Blazorが時期尚早なんて濁した回答してないでさ
707:デフォルトの名無しさん
20/12/26 20:16:33.93 BjZvExSE.net
>>696
puppeteerにそういう使い方あるのか。
スクレイピングと自動化にしか使ってなかったわ。
良いこと聞いた
708:デフォルトの名無しさん
20/12/26 20:22:06.40 q2RopqqH.net
JavaやC#はaws lambdaやgcp functionsのwarm startが遅い。ランタイム重いからね。
nodeはちょっぱや。
goは速くてしかもシングルバイナリだからgoというのは分かるがJavaやC#はダメダメだね。
709:デフォルトの名無しさん
20/12/26 20:22:56.55 q2RopqqH.net
立ち上げっぱなしだとaws lambdaやgcp functionsの意味ないからね
710:デフォルトの名無しさん
20/12/26 20:24:09.16 A5wLytvy.net
>>698
そうそう。特に単票はWeb版と同じAPIでHTML出して、帳票向けのcss当てて出力するだけだから、劇的に楽。
page.pdf()で完結。
悩むとしたら集計系とか、連続帳票のヘッダとフッタぐらいかな。
そのへんは小細工してcss書くのは諦めて、素直に複数ページ描画した。
手書きで心を込めた罫線の描画命令を書く必要もないし、クリレポ職人も要らないし、もちろんライセンスも要らない。
711:デフォルトの名無しさん
20/12/26 20:47:51.69 BjZvExSE.net
>>701
新しくAPI切ったりしなくて良いのは楽だなぁ。
前社で楽に帳票作るためにC#でxslxのテンプレートにデータ焼き込んでた怠惰な俺向きだわ
712:デフォルトの名無しさん
20/12/26 20:49:22.36 T66JFeJq.net
>>697
いやおれは要件が合えばscript系に移行することもかんがえてるC#erなんだよ
ていうかここのスレの意見聞いてたら弱点なんか全くないじゃないか
713:デフォルトの名無しさん
20/12/26 21:11:43.91 A5wLytvy.net
>>702
xlsxも綺麗に刷ろうと思うとCOMになるから、プロセスが落ちなかったりすると面倒だし、非UIのサーバアプリではやるなってのがMSの公式見解だしで、どうにかしようと行き着いたのがHTML帳票だった。
>>703
自分が知ってるC#の弱点は？
俺は色々思い浮かぶけど。
714:デフォルトの名無しさん
20/12/26 21:27:19.36 T66JFeJq.net
>>704
そもそもBlazorは未完成なのでSPAが作れないという感想
他は…
VisualStudioが重たい
.NETのサポートが短くなった
技術者を集めにくい
MSがフレームワークを作るだけつくって非推奨とか言い出す
言語というか、環境まわりだな
代わりにスクリプト系言語の弱点教えて
715:デフォルトの名無しさん
20/12/26 21:51:25.33 A5wLytvy.net
>>705
C#の弱点を聞いてて、Blazorの弱点を聞いてるんじゃない。
その全てはだいたいnodeと今時のJSのフレームワークで解決出来るんじゃないかな。
スクリプト系言語の弱点は、デプロイがちょっと面倒な事と、ランタイムが必要な事だと思う。
その辺はコンテナとか周辺技術で解決かな。
まあ、.net coreのSCDで解決しようとして未だに燻ってる所だよ。
716:デフォルトの名無しさん
20/12/26 22:12:05.25 Ii8YlEBO.net
>>656
彼が馬鹿だからさ！
717:デフォルトの名無しさん
20/12/26 22:24:59.74 T66JFeJq.net
>>706
C#の弱点はぱっと思いつかないな…
いろんな言語のいいところをパクって尚且つ非破壊だから
言語としてはひどい目にあったことはない
ADO.NETとかWebFormにはひどいめにあった
パフォーマンスや生産性がC#&ASP.NETと同等、それ以上なら前言を撤回する
以前どこかのスレに金融系のガチガチシステム、計算処理やエンドユーザー向けに大量の帳票吐く要件がある何十人ものメンバーでつくるようなシステムでスクリプト系言語使えるか聞いたらやめた方がいいって言われたことがある
718:デフォルトの名無しさん
20/12/26 22:29:52.08 aPjFRcaw.net
fastlyのcompute@edgeやcloudflareのworkersなどのエッジコンピューティングプラットフォームにC#でデプロイしてみなよ
719:デフォルトの名無しさん
20/12/26 22:36:31.82 A5wLytvy.net
>>708
いくらでも思いつくぞ。
GCがイケてない。
古いAPIが残りすぎ。
スレッドプールの使い方が下手。
最近ValueTaskが出てさらに無茶苦茶になった。
新機能がとことんシンタックスシュガーで、awaitするだけで暗黙のメンバ変数が生まれて寿命が長くなる。
いっぱいある。
それ以上だよ。少なくとも生産性に関しては。
既存資産という意味では。
規模が増えてきたら静的型付き言語でやりたくなるのはわかるけど、別に動的型付け言語でも普通にできる。
言われた事があるだけで、やってみて駄目だった訳じゃない時点でお察しだぞ。
まずは一人で、次はチームで、次はプロダクトでやって見ればいいじゃん？
720:デフォルトの名無しさん
20/12/26 22:59:58.77 T66JFeJq.net
>>710
ここに来てやっと有用な情報が出てきた…
どっちもやったことのある人の意見を聞きたかった。
スクリプト系総じてくそ！で終わらせる奴もいるし。
会社でそういう技術を試すにも理由がいるんでな。
充分選択の余地ありだな
ありがとう。
721:デフォルトの名無しさん
20/12/26 23:24:34.97 A5wLytvy.net
>>711
なんでこんなに試し試されるような会話をしないといかんか考えてよ。
みんなわかってて、批判してるんよ。
ちゃんと聞こうよ。
722:デフォルトの名無しさん
20/12/27 00:04:05.78 +391sGQI.net
またそのうちC#おじさん湧いてくるだろうけど、マジで不毛なんだよね。全く懲りない反省しない
723:デフォルトの名無しさん
20/12/27 00:24:48.94 V6kYHqJF.net
AWS Lambda には、Ruby も採用されている
マネージドサービスを使っていれば、環境構築運用など何も考える必要ない。
バッチ、Lambda、SQS・キュー、SNS・通知を、一杯つなげるだけ
724:デフォルトの名無しさん
20/12/27 01:08:11.82 pJh4CuO4.net
新規案件でSPA作りたかったらサーバーサイドもフロントサイドもC#選ぶ理由なんてないってことだ
725:デフォルトの名無しさん
20/12/27 01:34:36.12 muwPWXFk.net
>>708
VitualStudio使わなきゃいけないってのはサーバーサイドやるには結構面倒
726:デフォルトの名無しさん
20/12/27 02:16:33.08 Ezs6G331.net
>>716
なぜ使わなきゃいけないと思った？
727:デフォルトの名無しさん
20/12/27 02:17:11.17 sH9shL9g.net
C#おじさん全くスレと関係ないことを書き散らかして
自演改行しまくるから本当に迷惑
728:デフォルトの名無しさん
20/12/27 07:40:53.11 bUn1CAUk.net
自演がヒドイしとだから...
729:デフォルトの名無しさん
20/12/27 13:35:21.05 JDlKWc3Q.net
>>620
tsはまぁ分かるがjsはちょっと
pythonは古い言語だから記述のもどかしさは多いね
import周りは迷走しすぎ
730:デフォルトの名無しさん
20/12/27 16:30:32.33 xvZc4lDU.net
es3の頃のバッドノウハウを一旦リセットしてes2017とかやるとだいぶ違うよ。
同じ動的型付け言語でもpythonなんかより言語として洗練されている。
731:デフォルトの名無しさん
20/12/27 20:55:15.37 sH9shL9g.net
pythonも型書けるからねえ
tsはなんか型パズルしちゃう人が多くてよくわからん
表現力が強すぎるのも考えもの
732:デフォルトの名無しさん
20/12/28 20:26:09.84 KNPSf2Ws.net
>>710
>GCがイケてない。
JSを含む多くの言語がGCを持っている
それらのGC実装比較して具体的にどうイケてないと感じた？
>古いAPIが残りすぎ。
後方互換性は明らかなメリット
JSを含む他の言語ではそんなに簡単に後方互換性が失われて破壊的変更が頻繁に行われるの？
>スレッドプールの使い方が下手。
.NETのスレッド(を含む非同期処理全般)はうまく出来ていて最小限の労力で各環境毎に高い効果を見込めるようにできている
具体的にどういうところが下手だと感じた？
>最近ValueTaskが出てさらに無茶苦茶になった。
基本的にValueTaskを選んでおけばOKになったのでむしろスッキリした
どういうところが無茶苦茶になったと感じた？
>新機能がとことんシンタックスシュガー
シンタックスシュガーにすることによりランタイムのバージョンアップを回避して高い後方互換性を維持することができた
このメリットに対して変数のスコープが少し伸びた事によって具体的にどのようなデメリットが発生した？
733:デフォルトの名無しさん
20/12/28 21:29:19.32 8HD9KuQx.net
配点も書いてくれよ
734:デフォルトの名無しさん
20/12/28 21:49:29.10 gLlPtDZl.net
レスないからって自演かよ
735:デフォルトの名無しさん
20/12/28 22:08:20.13 KhSNASG/.net
お、屁理屈C#おじさんじゃん
736:デフォルトの名無しさん
20/12/28 22:18:18.18 KNPSf2Ws.net
なんだ
具体的に答えられないということは
やっぱり適当にそれっぽく言ってみただけか
737:デフォルトの名無しさん
20/12/28 22:27:42.95 KhSNASG/.net
まともに回答しても屁理屈で答えるか図星を突かれたら無視するような奴に、色々教えて介護してやる気は無いよ
738:デフォルトの名無しさん
20/12/28 23:18:38.63 KNPSf2Ws.net
>>728
そういうのはまともに回答できるようになってから言いなさい
739:デフォルトの名無しさん
20/12/28 23:19:49.01 0DUA8XV/.net
そもそも自演だし
740:デフォルトの名無しさん
20/12/28 23:22:09.77 or9XXg+k.net
い、一体どのレスとどのレスが自演なんだ…？
741:デフォルトの名無しさん
20/12/28 23:25:52.59 KNPSf2Ws.net
自演って言ってみたかっただけだろう
742:デフォルトの名無しさん
20/12/28 23:58:25.36 w2tkTAcI.net
GO + wasm じゃダメでしゅか？
743:デフォルトの名無しさん
20/12/29 00:52:45.33 hwRKbE5U.net
よい！
744:デフォルトの名無しさん
20/12/29 01:01:09.47 X0m1jPo1.net
wasm自体はGCサポートしてないからGC言語のGoやC#は辛いぞ。
少なくともGCをランタイムに積まないといけない。
そんなわけでwasmにはRustやC/C++ばっか使われるのだ。
C#なんかGCどころかコードをwasmネイティブにすることもできずにwasmでﾄﾞﾄﾈﾄの中間言語インタプリタ動かしてるだけだからなｗ
745:デフォルトの名無しさん
20/12/29 01:31:07.52 xrSERZg5.net
>>723
世代を超える時の扱いが雑。Goは敢えて世代管理しないという方向で行ってるが、ほぼパーフェクト。
そのせいでs
746:tackallocとか作っててワロスって感じ。 古いAPIを残してる分には良いだろう。 Obsoleteもついてないってどう言うことよ。 なんでhttpアクセスすんのにあんなに方法あんのよ。HttpClientは罠実装だし。 うまくできてない。ConfigureAwaitメソッドなんか要らない、と言えるようになってから言え。 ValueTaskを選んでおけばという発想がおかしい。 stackallocと同じ方向性の解決法。 選択肢は解決ではない。ちゃんとコンパイラがやれ。 ランタイムのバージョンアップを回避する必要性がわからん。必要ならしろよ。 それは後方互換性とは言わんでしょ。 個人的にはその寿命が伸びる件で踏み抜いたので割と嫌い。
747:デフォルトの名無しさん
20/12/29 02:30:03.59 c62SKept.net
また来たよ
もう金渡すから消えて
748:デフォルトの名無しさん
20/12/29 06:47:47.18 awsGRXp2.net
wasmにGC載せる計画はあるみたいだけど、そのGCはおそらくJSのGCと同一だろう。ChromeではwasmがTurboFan上で動くのと同様に。
これが移植上ネックになることもあるのかな、と上のを見ながら思った
749:デフォルトの名無しさん
20/12/29 06:50:26.39 awsGRXp2.net
あと、C#の話する時はC#って書いてくれ。NGするから
750:デフォルトの名無しさん
20/12/29 07:25:05.07 iWtJxFHh.net
WebAssemblyをNGわーどにしたら？
751:デフォルトの名無しさん
20/12/29 07:35:42.01 ZrXqpCJW.net
ワッチョイ付ければNG楽になるよ？
752:デフォルトの名無しさん
20/12/29 09:33:32.36 KX/n8CkP.net
一時期ﾜｯﾁｮｲｽﾚもあったけどなんか毛嫌いするヤツが多かったんだよな
753:デフォルトの名無しさん
20/12/29 11:29:58.07 b5xW7Gve.net
>>736
>世代を超える時の扱いが雑
どういうふうに雑だと感じた？
Goは世代管理をしないと言うがJSやその他の言語はどんな実装になってる？
>Obsoleteもついてないってどう言うことよ
高い互換性おかげで問題なく動作するから無理して修正する必要がないからではないかな
次期バージョンで消える可能性すらない安定したAPIになぜお節介にもObsolateを付けた方が良いと考えたの？
>なんでhttpアクセスすんのにあんなに方法あんのよ
複数の方法が共存するのは言語が後方互換性を維持しつつ順調に成長している証拠
君の考えかただと新APIだけ残して古いAPIは削除して後方互換性破壊することになる
唯一のAPIを残して他を削除すべきと考えたのはなんで？
>ConfigureAwaitメソッドなんか要らない
ConfigureAwaitはプログラム文脈から機械的に判断できないコンテキストの切り替えをコントロールするためのメソッドだ
これがないとプログラマはコンテキストの切り替えをコントロールできなくなってしまう
なぜコンテキストの切り替えをコントロールできないほうが良いと思った？
>ValueTaskを選んでおけばという発想がおかしい。
なぜ発想がおかしいと考えた？
>ランタイムのバージョンアップを回避する必要性がわからん
古いプログラムをそのまま動作保証するのに最も確実で安全で低コストな方法がランタイムをそのまま維持することだからだよ
なぜ破壊的変更が紛れ込む可能性があるのに変えなくてもいいところまでわざわざ変えたほうがいいと考えた？
754:デフォルトの名無しさん
20/12/29 11:47:10.79 awsGRXp2.net
その毛嫌いしてたのってC#おじさんじゃね？
755:デフォルトの名無しさん
20/12/29 12:02:26.55 Fq3XcUlo.net
TypeScriptも互換性維持のために同じ運命を辿るのだろうか
同じ作者だし
いまイケてる言語、フレームワークもいつかはレガシーに
ナウなヤングは気付いたらおじさんに
756:デフォルトの名無しさん
20/12/29 12:32:52.41 awsGRXp2.net
そのへんはある程度はしゃーない。
そうなったらいかにナウなヤングの邪魔をしないようにするか、いかに限られたリソースでキャッチアップするか考えるさ。
それまでに沢山経験積んどかなきゃ……
757:デフォルトの名無しさん
20/12/29 12:39:50.65 Fq3XcUlo.net
>>746
みたいなバイタリティある人はいいけど
大半の人間は潰しが効かなくなるだろうね
フロントサイドしかやってない人とか特に…
758:デフォルトの名無しさん
20/12/29 12:41:22.77 k23+wtCh.net
Cordovaは、iOS, Andoid, macOS でJSで書いたプログラムをWebViewを
使ってAppStoreやGooglePlayに登録できるアプリとして作製できるが、
iOS 11 以上だと、Wasmも実行できるらしい。Androidでは当然出来る。
そして端末の独自機能にJSやWasmからアクセスできる。
ファイルアクセスなども可能。
仕組みはJSと端末との間で通信するブリッジを用意している。
つまり、Wasmとして出力したプログラムは、Cordovaを使えば
モバイルOSで、ファイルシステムや端末の独自機能をフルアクセス
できるようになるらしい。
HttpServerなどを使ってJSとnative APIとの間が仲立ちされているので
JSからnative APIが全て使用できるだろう。
759:デフォルトの名無しさん
20/12/29 12:49:48.81 k23+wtCh.net
>>748
nativeアプリの仕組みはこうだ：
1. 時間や乱数を利用してパスワードの様なセキュリティートークンを作る。
2. Posix Socketを使ってLocal Http Serverを作る。ポート番号を5000とする。
3. WKWebViewなどのWebViewを使ってHtml+JSのプログラムを起動する。
4. 2 や 3 を起動するとき 1 のトークンを2と3の両方に渡す。
5. JSが端末の独自機能を使いたい場合、fetchやXmlHttpRequestを使って
URLﾘﾝｸ(localhost:5000)機能名?トークン&パラメータ
の様なURLでLocal Http Serverにアクセスする。
6. Local Http Serverは、トークンが正しい場合にのみ動作するようにする。
機能名とパラメータに応じてファイルの読み書きや端末の独自機能のAPIを呼び出す。
7. APIの結果は、Http プロトコルの response で JS 側に返す。
8. JSは結果を受け取る。
760:デフォルトの名無しさん
20/12/29 12:54:14.36 4hVd0nGl.net
wasmってブラウザだけじゃなくK8SでもIo
761:Tデバイスでも動くわけだし モバイルでも動かしたいって欲求も当然出てくるだろうな そうなるとストアアプリの実装言語も将来的に何でもありになるのかもね
762:デフォルトの名無しさん
20/12/29 13:29:33.29 xrSERZg5.net
>>743
nodeなんかはインクリメンタルではなかったっけ。
Javaはアプリの仕様に合わせて好きに選べる。
awaitで寿命が伸びる件と相性が悪いけど、あまりにも世代1に行き過ぎ。
ライブラリ関数ではゼロアロケーション意識しないといかんレベル(ライブラリ関数でgcが起きるとgen0がライブラリ関数で尽きるので呼び出し元がgen1にあっさり追い出される)
.net coreでやっとある程度柔軟にはなったものの。
無理して修正する必要はない。
逆だろ。処理系のバージョンアップ側にメンテナンスコストかかり続けるじゃん。
それ言い続けて、限界を迎えたら.net core？
アホかな。
後方互換性を維持しつつ順調に成長してるならば、関数が変わるよな。
実のところ、本館、新館、別館と建て増した温泉旅館だよ。
古いAPIは2世代ぐらいで殺すべきだろ。
なんで.NET FWがあんなに亀レベルでしか成長できなかったと思ってんの。
コントロールできない方が良いんではない。
コントロールする必要があるのがアホかなって言ってる。
UIスレッドだけ特別扱いしてるところからわかるだろ。
中途半端。
発想がおかしい理由がわからんならもう黙れよ。
古いプログラムをそのまま動作保証するために必要なのは、互換性ではなく、そのバージョンをLTSにしてちゃんとパッチ出してく事だよ。
で、SideBySideできるようにするか、コンテナにするかどっちかだろ。
バージョンアップするけど(だいたい)互換性はありまぁすとか言ってるから、2020年なのに.NET FW 4以上に上げられん基幹系みたいな負の遺産を残すんじゃないか。
お前が言ってることはC#というか.NETを何度もだめな言語にしてきた老害の発想だからな。
C#が好きならちゃんと考えろよ。
763:デフォルトの名無しさん
20/12/29 13:57:14.43 Fq3XcUlo.net
すっげえわかる
MSってほんと最低な奴だよな…
764:デフォルトの名無しさん
20/12/29 14:21:44.49 xrSERZg5.net
ホントに他の言語やれと。
俺ずっとVue+JavaScript派だったけど、最近何周か遅れてReact+TypeScriptやってて、これはこれで確かにいいなと思ったりしてるぞ。
いろんな設計思想があるのは良いじゃん。最強で至高なんかねえよ。
めっちゃ叩いたけど、そのすぐ裏側はC#の良いところなのもわかってるからな。
765:デフォルトの名無しさん
20/12/29 14:36:53.53 EHaGj/ct.net
>>751
>Javaはアプリの仕様に合わせて好きに選べる。
結局のところアプリのメモリ使用特性に合わせて選択するのが賢いのであって特定の実装が良い悪いという絶対的な指針はないのだろうね
ではなぜ君は.NETのGCが絶対的に悪いような言い方をしたのかな？
>awaitで寿命が伸びる件と相性が悪いけど、あまりにも世代1に行き過ぎ。
awaitシンタックスシュガーで変数の寿命が伸びていたのは昔の話
少なくとも7年前には非同期を跨がない変数はキャプチャされなくなった
なお非同期をまたぐ変数の寿命が伸びるのは非同期処理の宿命でありawaitシンタックスシュガーは関係ない
なぜ君はawaitシンタックスシュガーが変数の寿命を伸ばすことを問題視したの？
>ライブラリ関数ではゼロアロケーション意識しないといかんレベル
C#のメモリ管理サポートは.NET Coreで急激に進歩している
他の多くの高級言語ではゼロアロケーションを意識しても難しいがC#ではそれほどでもない
これはパフォーマンス意識する上で非常に大きい
アロケーションを減らせるならGCの負荷も小さくなる
JSなど他の言語では機械的な最適化以外にメモリ確保そのものを大幅に減らす工夫はあるのかな？
766:デフォルトの名無しさん
20/12/29 14:37:48.66 EHaGj/ct.net
>処理系のバージョンアップ側にメンテナンスコストかかり続けるじゃん
いやいや処理系のメンテナスコストは低いよ
だって仕様が変わってないんだから
シンタックスシュガーのバージョンアップで変化するのはコンパイラのほうね
>それ言い続けて、限界を迎えたら.net core？
Coreへの移行はメンテナンスが累積して限界を迎えたから行ったわけではないよ
主な理由はマルチプラットフォームへの対応を迫られたから
>実のところ、本館、新館、別館と建て増した温泉旅館だよ。
>古いAPIは2世代ぐらいで殺すべきだろ。
その本館も新館も別館も安定稼働してお金を稼ぎ続けている
なのになぜむりやりお金をかけてまで閉じる必要があるのかな？
>なんで.NET FWがあんなに亀レベルでしか成長できなかったと思ってんの。
.NET FWというかC#の成長は速かったよ
いくつもの先進的な機能たとえばLinqだとかReactiveExtensionだとかAsync/Awaitだとかを生み出して
他の言語はC#を追いかけるように機能を模倣してきた
>コントロールする必要があるのがアホかなって言ってる。
コントロールする必要がなければデフォルトでいいよね
コントロールしたいときにできないのは大きな問題だとは思わないかい？
>UIスレッドだけ特別扱いしてるところからわかるだろ。
これは言語の問題ではなくOSアーキテクチャの成約ね
他の言語だってUIスレッドは特別なもの
もしコンテキスト切り替えをコントロールできない言語だと特別なスレッドのために他の関係ないスレッドがパフォーマンス上の不利益を被る
767:デフォルトの名無しさん
20/12/29 14:38:21.55 EHaGj/ct.net
>発想がおかしい理由がわからんならもう黙れよ。
わからないから説明をしてほしいのだけど？
根拠も理由もなく発想がおかしいというだけではまったく意見になってないよ
>古いプログラムをそのまま動作保証するために必要なのは、互換性ではなく、そのバージョンをLTSにしてちゃんとパッチ出してく事だよ。
.NET FWはそのあたり手厚いね
未だにWinアップデートで3.5のセキュリティパッチとか落ちてくるでしょ？
>で、SideBySideできるようにするか、コンテナにするかどっちかだろ。
.NETはSBSもサポートしているね
コンテナ化することをそのまま動作保証とは普通は言わない
>バージョンアップするけど(だいたい)互換性はありまぁすとか言ってるから、2020年なのに.NET FW 4以上に上げられん基幹系みたいな負の遺産を残すんじゃないか。
負の遺産ではなく未だに安定して利益を生み出す正の遺産だよ
負の遺産っていうのは言語のAPIが急にサポート切れになって大幅な改修を入れなければならなくなり開発コストで大損したみたいな場合ね
>お前が言ってることはC#というか.NETを何度もだめな言語にしてきた老害の発想だからな。
C#が駄目な言語になったことなんてないよ
VBという悲しい過去があるので.NET全体を称賛するわけにもいかないが
C#は常に成功してきたしこれからも成功する言語だと確信している
768:デフォルトの名無しさん
20/12/29 14:46:23.51 xrSERZg5.net
>>754
絶対的に悪い部分はあるだろ。
「挙動の変更不可」。
「GCの挙動が気に食わん」の解決法が「別のGCを選べる」というのは、GCの設計として正しい。
「気に食わんけど耐えるしかない or ワークアラウンドで対応」
これはなんの解決でもない。
非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの？
難しくないから、人間がやれば良い？
アホか？
じゃあGoみたく、ベンチツールにデフォでアロケーションカウンタついてるのか？
そうでもないだろ。
他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
769:デフォルトの名無しさん
20/12/29 14:54:23.36 xrSERZg5.net
>>755
高いよ。
お前あんまりミッションクリティカル系でC#使ってないだろ。
違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる？
特にPCL。あれで現に破綻しただろ。
安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
>>755
言語仕様は早かったな。
で、2016年まではawaitでキャプチャしてたとか、歪な形になってたわけだ。
その頃のアセンブリはもちろんその頃のまま。パフォーマンスもお察し。
さらに今のコンパイラでコンパイルしたものとILは異なるよな。
そのあたりで踏み抜くものが多すぎるんだよ。
コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
UIスレッドだけ特別視するのが悪いと言ってるんじゃない。
「UIスレッドはちゃんと勝手にConfigureAwaitできてるじゃん。お前らなんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの？」という話なんだよ。
手動設定信仰過ぎるだろ。
770:デフォルトの名無しさん
20/12/29 14:56:52.79 EHaGj/ct.net
>>757
>「挙動の変更不可」。
.NETもパラメータである程度の調整はできるようだが…
アルゴリズムを手軽に差し替えるような解決策が用意されている言語はどれほどあるのだろうか？
非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの？
難しくないから、人間がやれば良い？
アホか？
じゃあGoみたく、ベンチツールにデフォでアロケーションカウンタついてるのか？
そうでもないだろ。
他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
771:デフォルトの名無しさん
20/12/29 14:58:38.03 xrSERZg5.net
>>756
ほう、4.0と同時に入れられる4.xがあるなら手厚いと言えるだろうな。
コンテナ化する事を動作保証と言うぞ。
というか、完璧に構成管理してやっと動作保証できるものであって、コンテナ化に関しては理想型だろ。
安定して利益を生み出す、で履き違えるな。
負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
言語のAPIが急にサポート切れ、な。
いつ誰がやらかしたかな？
772:デフォルトの名無しさん
20/12/29 15:05:12.04 xrSERZg5.net
>>759
焦って途中でレスすんなよみっともない。
ほかのすべての言語はできるがC#だけは出来ない、と言ってるんではない。
C#が得意な事とそうではない事があることは認識しろ、と言ってる。
他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#なら、C#でも、ってのは、そりゃ原理上可能だろ。可能じゃなかったらチューリング完全でない。
ただ、向いてるかって聞くと、それぞれもっと向いているものを知ってる人間は居るってことなんだよ。
ちょっと冷静に考えろ。
C#は好きだが、議論の道具として叩いてて、反対側にはメリットもあるのはわかってんよ。
773:デフォルトの名無しさん
20/12/29 15:10:39.54 EHaGj/ct.net
>>757
>「気に食わんけど耐えるしかない or ワークアラウンドで対応」
>これはなんの解決でもない。
GCの差し替えができないならそうするしかない
C#は他の言語と違って安全なメモリ管理サポートが充実しているので「耐えるしかない」ということはない
>非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの
非同期を跨いで利用される変数のスコープが伸びることは必然だから問題じゃない
もし問題だというならそれはシンタックスシュガーのせいではなく非同期アルゴリズムの設計に問題がある
言語のせいではなく設計ミス
>他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
そうじゃない「他の言語でできないor難しいことが簡単に出来る」と言ってる
たとえばC#のref構造体やspanのように安全に低頻度のアロケーションをサポートするスクリプトが幾つあるだろう
774:デフォルトの名無しさん
20/12/29 15:24:29.79 EHaGj/ct.net
>高いよ。
>お前あんまりミッションクリティカル系でC#使ってないだろ。
処理系のメンテコストの話がミッションクリティカルでのC#利用経験の話になるのはなぜ？
>違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる？
>特にPCL。あれで現に破綻しただろ。
PCLは確かにあまりうまく行っていなかった
うまく行っていなかったからこそだ
本格的なマルチプラットフォーム対応のためのCoreでありStandard
>安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
>お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
もちろんメンテナンスは続けてるだろ
古いコード新しいコード両方が安定して稼働するからこそ安価にメンテナスが可能となる
APIが急になくなったらちょっとしたメンテナンスでも大騒ぎだ
>そのあたりで踏み抜くものが多すぎるんだよ。
多すぎるというからには何かしら数字が出てるのだと思うけど示せる？
>コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
すまん
正直意味不明なので説明を求む
>なんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの？」という話なんだよ。
その属性をつけるのは結局手動だろう？
自動化信仰も結構だが世の中全てを自動化できるわけではない
手動で解決してる理由は機械的、自動的に決定できないからだよ
機械的、自動的に決定できないものに対して取れる最もマシな方法は昔から決まってて
事故が起こりにくい方をデフォルトにする
どちらも安全なら統計を撮って利用頻度で決める
775:デフォルトの名無しさん
20/12/29 15:34:45.80 EHaGj/ct.net
>>760
>コンテナ化する事を動作保証と言うぞ。
いや言わない
基本的に今まで動作していた環境で同じように動作することを動作保証という
新しくコンテナに載せ替えるかどうかは動作保証とはまったく別のベクトルの話であって関係がない
>安定して利益を生み出す、で履き違えるな。
>負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
技術的負債のことを言いたいのだろうけど
古いAPIが全て負の遺産であるような認識は典型的な間違いだぞ
たとえ古いAPIを使っていてもテストが整備されていて設計が美しく開発環境の準備が難しくないならそれは借金でもなんでもない
>言語のAPIが急にサポート切れ、な。
>いつ誰がやらかしたかな？
.NETでは幸いなことにまだぶち当たったことがない
776:デフォルトの名無しさん
20/12/29 15:40:20.23 Fq3XcUlo.net
なげーなー
C#はSPAには特化してない
歴史的な経緯があるからそのせいで扱いにくいこともある
SPA作るなら特化しているReact+ts使った方が幸せになれる
ってこと？
777:デフォルトの名無しさん
20/12/29 15:43:25.20 EHaGj/ct.net
>>761
>焦って途中でレスすんなよみっともない。
うるせえな寒くて手が滑ったんだよ
暖房つけたからもう大丈夫
>C#が得意な事とそうではない事があることは認識しろ、と言ってる
C#より上手く特定の分野を実装できる言語はあると思う
しかしC#は各分野で最高とまでいかなくとも何でも得意で
C#が特別に苦手なことというのはない
そういう成績オール5 or 4的なところが気に入ってる
>他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#を使えるなら他を使う「積極的」なメリットは無い
他の言語が特別に得意な分野がどうしても必要なときに仕方なくその言語を使う程度の塩梅でおｋ
778:デフォルトの名無しさん
20/12/29 15:49:41.14 EHaGj/ct.net
>>765
>C#はSPAには特化してない
SPAについてはまだまだ黎明期
>歴史的な経緯があるからそのせいで扱いにくいこともある
新規に開発する分には扱いやすい
レガシーがモダンと比較して扱いにくいことがあるがそれはレガシーなので仕方がないこと
レガシーが安定して動作するよう後方互換性とセキュリティパッチが充実しているので
レガシーのメンテナンスを最小化することができる
>SPA作るなら特化しているReact+ts使った方が幸せになれる
人による
現時点ではReact+TSのほうが支持者が多い
779:デフォルトの名無しさん
20/12/29 15:51:29.01 xrSERZg5.net
>>766
全部言い訳だわ。
GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか？
IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う？
ケース知らなすぎるだろ。
他の事も色々間違ってるがもうそもそもおかしい。
C#は別になんでも得意じゃねえぞ。
オール3だよ。
C#でこれは4だなって思うのはLinqぐらいだ。それももう追いつかれた。
他の言語を知らんから、本当の5を知らんのだろ。
積極的なメリットは無い。知らないからそりゃそうだろうな。
それでC#が好きだとほざくな。
780:デフォルトの名無しさん
20/12/29 15:55:19.91 yginI0z/.net
・・・本当の5の言語って何や？
781:デフォルトの名無しさん
20/12/29 16:04:46.05 xrSERZg5.net
>>769
人とニーズによるだろうけど、Goの並行処理とか、
Erlangのメッセージパッシングとか、
F#の測定単位とか、
Lispのマクロとかかな。
JavaScriptも、あれはあれでとても良いと思う。
782:デフォルトの名無しさん
20/12/29 16:08:35.63 b5xW7Gve.net
>>768
>GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか？
大抵のことはGCで問題ない
クリティカルなところでのC#なら安全に比較的細やかにメモリ管理ができるので問題ない
>IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う？
当たり前だがDisposeするまでだろ
非同期挟もうが挟むまいが不要になった時点で速やかに破棄される
awaitを使ったからと言って必要もないのに無駄に変数の寿命が伸びることはないよ
伸びるのは非同期処理を実装するのに本当に必要な変数だけだ
>本当の5を知らんのだろ。
例えば？
783:デフォルトの名無しさん
20/12/29 16:11:47.13 Fq3XcUlo.net
>>769
5=GOなんだろ
ダジャレだよダジャレ
エスプリの効いたギャグをかましてくれたんだよ
784:デフォルトの名無しさん
20/12/29 16:24:08.58 Fq3XcUlo.net
>>770
これ特化してるところじゃん
あらゆる分野において平均以上かどうかなんじゃないの
ジェネラリストかスペシャリストか
785:デフォルトの名無しさん
20/12/29 16:24:33.75 b5xW7Gve.net
>>770
果たしてそれがメインの開発言語を乗り換えるほどの価値があるかどうかだよね
自分はとてもではないがそうは思えない
もし本当にどうしても避けられずそれが必要になったら局所的にその言語で実装してメイン言語から呼び出すって形にするだろうな
まあGoぐらいなら別にメインにしてもいいかなぁ…とは思うがね(実際にはしないだろうけど)
786:デフォルトの名無しさん
20/12/29 18:16:37.52 Hcyt9B7d.net
C#は素敵な言語だけどさすがにオール5は言い過ぎたねって話だね
787:デフォルトの名無しさん
20/12/29 18:29:46.92 Cpv18UIo.net
なんでこの人たちいつもC#の話してるの？
788:デフォルトの名無しさん
20/12/29 18:30:27.64 xrSERZg5.net
>>773
5ってのは、そういう事だと思うぞ。
4で、それが書きやすい、程度。
>>774
ニーズ次第じゃないかな。
789:デフォルトの名無しさん
20/12/29 18:44:00.86 awsGRXp2.net
オール5の言語なんてLispしかないよ！DSLで何にでも特化できるから！神はLispで世界を作ったんだぜ！（ぐるぐる目）
冗談はさておき、昔のJSはLispの匂いがして好きだった。今は（TSは）Lispの匂いほぼなくなって、万人ウケしやすい言語になったと思う。
790:デフォルトの名無しさん
20/12/29 19:19:37.56 xrSERZg5.net
>>778
ほんとにそれよね。JSはC構文のLispっぽくて好きだったけど、TSでどんどん静的な言語になってしまってる。
791:デフォルトの名無しさん
20/12/29 19:25:03.79 PuaagtBb.net
高階関数で関数型プログラミングの匂いはするがLispの匂いはしない
Lispって全部がリストになってるから
792:デフォルトの名無しさん
20/12/29 19:35:30.70 xrSERZg5.net
>>780
applyと分割代入あたりが、おおむね対応するんではなかろうか。
793:デフォルトの名無しさん
20/12/29 19:39:46.86 LSI+C1uB.net
C#をNGにしたら書き込み全部消えちゃった
794:デフォルトの名無しさん
20/12/29 19:41:55.81 xrSERZg5.net
まあ、作った人がScheme意識してるって言ってるからな。
URLﾘﾝｸ(brendaneich.com)
795:デフォルトの名無しさん
20/12/29 19:47:54.10 awsGRXp2.net
全部がListだったらそれはもう匂いがするどころではなくLispそのものだと思う。
Lisp脳だったのでTS始めた時は型演算そのものを(Lispみたいに)JSで書かせてくれと思ったよw
796:デフォルトの名無しさん
20/12/29 19:53:01.60 awsGRXp2.net
Lispの匂いといえばMozillaのlet式が没ったのは返す返すも残念だった。今はdo式に期待してる
797:デフォルトの名無しさん
20/12/29 21:12:55.98 LSI+C1uB.net
>>778
Lispのどこがいいんだ？
全てにおいて不便なだけな気がするのだが
798:デフォルトの名無しさん
20/12/29 23:06:44.05 awsGRXp2.net
Lispのデータとソースコードは全てListである。
Lispは主にListを操作してプログラムする。
Lispには文は無く、式だけがある。
LispのマクロはListであるLispソースコードの操作をLispで行う。
Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。あらゆるコードを抽象化できる。
スレ違いだからあとは調べてね。
これは個人的な所感だけど、
ありとあらゆる式文が作れる（抽象化できる）ってことはつまり俺ルールがまかり通って分断を招く言語って事だから、そりゃ一般向けじゃないやね
799:デフォルトの名無しさん
20/12/29 23:19:25.78 c62SKept.net
>>787
そのせいでクオートとか関数クオートみたいな邪悪な存在が生まれたのは無視かな？
800:デフォルトの名無しさん
20/12/29 23:26:15.08 Ba9B66hW.net
>>787
長々と書いてるがメリットってこれだけだろ？
> Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。
DSLを作りたいやつがどれだけいるか知らんが
DSLというのはただの関数に過ぎない
だからどの言語でも関数を作ることで簡単にDSLを作れるぞ
801:デフォルトの名無しさん
20/12/29 23:36:01.58 awsGRXp2.net
細かい反論はあるけど概ねご批判の通りだよ。
だから流行らない。俺は好きだけどね
802:デフォルトの名無しさん
20/12/29 23:38:23.99 Ba9B66hW.net
URLﾘﾝｸ(xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com)
> DSLは、大きく内部DSLと外部DSLに分類することができます。
>
> 内部DSL: 内部DSLは、汎用のプログラミング言語の書き方を工夫して、
> 見かけ上の構文を自然言語に近づけた言語です。
書き方を工夫するだけだからどの言語でも出来る
> 外部DSL： 外部DSLは、汎用のプログラミング言語とはまったく別の構文を持ったDSLです。
こっちはlispでも作りづらい
803:デフォルトの名無しさん
20/12/29 23:46:09.89 Ba9B66hW.net
内部DSLの場合、言語によって自然言語に近づけるといっても限界がある場合がある
えばC言語なら、 This("is", "a", "pen"); が限界だろう
これがRubyだと This "is" "a" "pen" となる
is とか a とか を定義すれば、This is a "pen" と書けるかもしれないな
だがシェルスクリプトであれば This 関数を作るだけで
This is a pen と書くことが出来る。
ダブルクォートでくくらなくても文字列として扱われるからだ
内部DSLを作るのに一番適した言語はシェルスクリプトだと思うが
それはそれとして、DSLを簡単に作れる言語の条件はリスト操作をしてるとかではなく
引数を () でくくらなくても良いとか最後にセミコロンがいらないとか
そういう言語ではないだろうか？自然言語は () でくくらないからな
804:デフォルトの名無しさん
20/12/29 23:52:22.87 Ba9B66hW.net
引数の区切りにカンマが不要ってのもDSLに適した言語の条件かな
805:デフォルトの名無しさん
20/12/30 00:05:32.15 TuVgzDLD.net
>>789
kotlinぐらいじゃないかな。
無茶めな構文が変わるレベルのDSLが作れるの。
S式として成り立ってればどんな構文すら作れるから、関数を作ることで作れるとか言ってるレベルじゃないぞ。
それが良いことかはおいといて。
806:デフォルトの名無しさん
20/12/30 00:08:13.49 Zk/FBUc0.net
どんな構文でも作りたいわけじゃない
「自然言語」に近い構文を「簡単に」作れるというのが条件
自然言語というのはシンプルで、単語を並べるだけなのだ
仮にkotlinでC言語の構文に対応できたとして
それはDSLとしてはふさわしくない構文
807:デフォルトの名無しさん
20/12/30 00:08:25.33 olxuh5fb.net
>>789
JuliaとRustはそこそこ無茶なこともできるしな
ASTレベルでの操作だし
Lispプログラム=実質的なASTと考えると何も変わらん
そこの優位性ももはやない
808:デフォルトの名無しさん
20/12/30 00:15:06.44 Zk/FBUc0.net
>>796
だからプログラム言語を作りたいんじゃなくて
DSL（自然言語風）を作りたいんだってばｗ
809:デフォルトの名無しさん
20/12/30 00:19:04.50 Zk/FBUc0.net
あと「簡単に」ってのも重要
作れるけど大変っていうのは簡単ではない
810:デフォルトの名無しさん
20/12/30 00:19:15.74 olxuh5fb.net
Lispは自然言語風ではないだろ
あの括弧なんとかしろよ
811:デフォルトの名無しさん
20/12/30 00:21:48.47 TuVgzDLD.net
DSLって別に自然言語に寄ってなくても良いんじゃないか？
ドメイン記述に便利な表記であればそれで良いかと。
昔ウィジェットツリーをそのまま書いたらマクロで展開されるとかそういうの書いたことあるけど、自然言語寄りではなかったな。
最近で言うとkotlinのankoみたいなやつ。
812:デフォルトの名無しさん
20/12/30 00:26:09.36 Zk/FBUc0.net
> DSLって別に自然言語に寄ってなくても良いんじゃないか？
それは正しいが「自然言語と異なる別のプログラム言語」を
覚え直さなければいけないのはナンセンスだろ
813:デフォルトの名無しさん
20/12/30 00:26:50.79 Zk/FBUc0.net
（なぜか「当分お断りしております。」が出たので分割して書き込み）
独自のDSLを作る場合、新たな言語を覚えなおさなくていいように
誰もが知ってる自然言語に近い構文にするのが普通
814:デフォルトの名無しさん
20/12/30 00:27:23.67 Zk/FBUc0.net
そうしないとDSLを使うことで
815:デフォルトの名無しさん
20/12/30 00:28:25.07 Zk/FBUc0.net
ぎゃくにこーどがわかりづらくなる
DSLの特徴である「ドメイン固有の処理を簡単に表現できる」に反してしまう
816:デフォルトの名無しさん
20/12/30 00:29:06.25 Zk/FBUc0.net
（なんで「ぎゃくにこーどが」を漢字とカタカナにしたら書き込めないんだ？）
817:デフォルトの名無しさん
20/12/30 00:30:13.27 Zk/FBUc0.net
「コ ー ド」をスペース抜いたら書き込めない
818:デフォルトの名無しさん
20/12/30 00:34:39.76 DCxLNcGT.net
こうやって言語機能そのものみたいな基本部分の重箱つついて、何かあるとすぐちゃぶ台返しして応用や発展的な話題出ないの最高に5chのプログラム板って感じ
819:デフォルトの名無しさん
20/12/30 00:35:42.82 olxuh5fb.net
そもそもすれ違いだぞ
820:デフォルトの名無しさん
20/12/30 00:41:11.57 Zk/FBUc0.net
>>807 そういうことじゃなくて「色々出来る言語」を過大評価しすぎってこと 簡単に目的を達成できる方が重要なのに 色々出来るんやでだからすごいっていう考えが古臭い
822:デフォルトの名無しさん
20/12/30 00:56:40.62 lXmFrXZN.net
コード
823:デフォルトの名無しさん
20/12/30 00:59:28.01 nb9M1V+x.net
>>810
どうやらブラウザ（ユーザーエージェント？）も関係あるっぽい
Chromeでは書き込めず、Firefoxなら書き込めた
その他の情報も見てる可能性があるな
IPアドレスは変えてもクッキー消しても意味はなかった
824:デフォルトの名無しさん
20/12/30 01:01:03.26 eKh3SvG1.net
スレ違いなネタでろくに知識もないのに平気で一人で盛り上がってる感じ、またC#おじさんかよ。NGすとこ
825:デフォルトの名無しさん
20/12/30 01:12:42.10 lGcdPzxm.net
>>812
９月２日から１０月１０日までレスが３つしか付かなかった過疎スレだったんだよね
テーマに沿って話して過疎るか雑談でスレを伸ばすかのどっちかで雑談でもいいと思う
でないと話すことなくて過疎る
雑談が嫌なら来なければいい
826:デフォルトの名無しさん
20/12/30 01:42:40.61 zA1s3IaL.net
なんでjs前提のスレで他言語について話してんだ○イジかよと思ったけど。もともと過疎スレだったのか。
フロントエンドFrameworkはすでに別にスレがあるから、雑談スレでもいいかもね。
827:デフォルトの名無しさん
20/12/30 01:56:29.40 Cptlqs6D.net
みんなどうやったら良いSPAが作れるか議論したいんじゃないの
今更だけどスレタイで技術を限定するのは世界を狭めていると思う
C#おじさんはうざいかもしれないがまがいなりにもSPAを作る技術があるわけで
828:デフォルトの名無しさん
20/12/30 02:08:36.28 sThloFfy.net
わいはSSRの方がすこだ！
829:デフォルトの名無しさん
20/12/30 03:37:46.36 olxuh5fb.net
C#おじさんの自演ここまでくると怖い
本当に年内に病院に行くべき
830:デフォルトの名無しさん
20/12/30 05:45:50.88 WuRkJ7SN.net
>>816
Next.jsなら今はSSG推奨
831:デフォルトの名無しさん
20/12/30 06:08:39.70 npFXMZqI.net
時代はISR
832:デフォルトの名無しさん
20/12/30 06:38:08.28 Kz0vlNp0.net
>>813
C#おじさんいっつも最後にはそれ言い出すな。荒らしが荒らして伸びるより過疎スレの方がどう考えたって健全じゃん。
スレが伸びることが何の免罪符になると思ってんだか
833:デフォルトの名無しさん
20/12/30 10:00:04.98 TuVgzDLD.net
まあアホみたいにC#に反論して悪かった。
そりゃそうでそもそもスレチだわな。
React今更やり直してんだけど、スタイルってどうやってる？
Vueみたいにコンポーネントごとに書いといたらcssが一本ドーンとできるみたいな仕組みが欲しいんだが、見た感じなさそう。
css in jsでインラインスタイルみたいな感じで当てまくるのが王道なの？
834:デフォルトの名無しさん
20/12/30 11:50:39.35 mn0czGQ5.net
react というかNext.jsってpagesの中でscssをimport する時って
各エレメントにclassName={hoge.kage} って手動でクラス名を紐付けないと駄目なの？
比較して申し訳ないけど、vueだとcss側に*{color:red}とか.main{border:1px;}、html側に<div class="main">と書くだけで
コンポーネント単位でdata-v-xxxx ってスコープ切って紐付けてくれるんだが、そういうのは無し？
前の人と多分同じネタかなこれ
835:デフォルトの名無しさん
20/12/30 12:16:17.47 TuVgzDLD.net
>>822
同じネタだと思う。
かつ、俺less使ってて、共通色とか基本サイズ数とかの定数値を、importしてるんだけど、これをきれいに解決する方法がわからん。
836:デフォルトの名無しさん
20/12/30 12:34:12.03 zA1s3IaL.net
横からだけど自分もそれ気になるなあ。
コンポーネントごとcssを別出しするとか色々あるみたいだけど、やり方が複数あって迷うなぁ。
Tailwind使ってるからスタイル自体そんなに充てないけども
837:デフォルトの名無しさん
20/12/30 12:54:00.12 mn0czGQ5.net
>>823
うーむ、Next.jsのgetServerSidePropsに惹かれて試してみたけど、こっちはVueと比べてCSSの考える事は多い感じかな
適当に書くけど、.main > * {color:red}とかやって、子コンポーネントに突き抜けたりしないだろうか・・・。
838:デフォルトの名無しさん
20/12/30 14:36:06.25 97VH6JZh.net
>>820
他人に過疎を味あわせたいというのは異常だし
おまえがこのスレに来なくて過疎を味わい他人がこのスレで雑談して楽しむのはwin-win
スレのテーマを話したい人がいるときに雑談で邪魔しないというマナーはある
839:デフォルトの名無しさん
20/12/30 17:44:12.92 zA1s3IaL.net
>>822
Reactだと、上記と同じことをするのはstyled-componentsかな。
エディタの補完が追いつくのかは気になるけど
URLﾘﾝｸ(qiita.com)
840:デフォルトの名無しさん
20/12/30 18:55:12.14 olxuh5fb.net
>>826
とにかくお前はC#スレに籠ってろ
他の勢いがあるスレに関係ないことを書き込みに来てるのはわかってるんだ
841:デフォルトの名無しさん
20/12/30 20:27:31.52 /bDJ6XEP.net
「過疎スレだから」がスレ違い宣伝荒らしの言い訳ならprologスレとforthスレを盛り上げてこい。これは命令だ。
842:デフォルトの名無しさん
20/12/31 00:25:02.74 QWe6530o.net
Next.jsってアップデートされたけどVercel使わないとまともに使えん的になってきてそこそこの規模でも有料だし
少し大きくなったら年間数万ドルもかかるとかやばくねえっすか？
843:デフォルトの名無しさん
20/12/31 00:48:49.82 ZOSFby6D.net
ちょっと調べたけどnextって今そんなことになってたんだ。面白ー。
まぁまだゆとり向けフレームワークのnuxtちゃんがいますし...
844:デフォルトの名無しさん
20/12/31 07:16:28.08 kXsKi0cH.net
画像最適化やISR等の一部機能がVercel依存なだけじゃないの？
Vercelも自分とこのプラットフォームを使ってほしいだろうけど、客寄せになるNext.jsの人気は必要だから無茶はできないし
845:デフォルトの名無しさん
20/12/31 17:56:20.15 v+HdWO16.net
ReactのNext.jsのgetServerSideProps() に相当する機能ってVueのNuxt.js には無い？
DBアクセスとか、必ずサーバー側で実行して欲しい処理を書きたい
846:デフォルトの名無しさん
20/12/31 20:12:22.49 n8r8zFZ6.net
ある
が基本的すぎてドキュメント読んでないのがバレるぞ
847:デフォルトの名無しさん
20/12/31 23:11:57.32 v+HdWO16.net
asyncDataやfetchだとrouter-link、nuxt-linkでページ遷移するとクライアント側で実行されちゃう認識だけど
それ以外にも必ずサーバサイドで実行される(ロジックの中でfs.readFileSyncが使える)方法あるの？
848:デフォルトの名無しさん
21/01/01 01:01:38.63 I6jeM+Zp.net
getServerSidePropsの意味するところを俺が誤認してたみたい失礼。
asyncDataをサーバ側に限定する方法はない
ServerMiddlewareを使えばサーバ側で動くAPIを作れるから、それをクライアント側から呼ぶ形が一般的
849:デフォルトの名無しさん
21/01/01 01:11:21.91 /+4IUuLb.net
やっぱりページごとにAPI作るのがNuxtの流儀か
管理サイト的なものを作っていて、9割のページがDBのデータを表示してるから
1ページごとにAPIを個別に作るのはしんどいんだよね
それか、router-link禁止で全部<a>タグでのみページ遷移するルールにするかって感じか
850:デフォルトの名無しさん
21/01/01 10:22:39.74 JSeY8OLT.net
>>822
普通にscssで書いてる
一般的なサイトと書き方変わらん
851:デフォルトの名無しさん
21/01/01 11:09:03.93 LgwM8ucz.net
>>838
コンポーネントにではなくて、サイト全体に書いてる感じ？
グローバルに効いちゃうって事？
852:デフォルトの名無しさん
21/01/01 12:13:22.88 JSeY8OLT.net
>>839
index.jsでsassをimportしてるからそんな感じ
といってもscssファイルはページ用とか変数用とかに分けてる
853:デフォルトの名無しさん
21/01/01 13:10:38.63 LgwM8ucz.net
>>840
なるほど。ありがとう。
となると、ちょっと設計方針変えないといかんな。
854:デフォルトの名無しさん
21/01/01 13:44:12.20 JSeY8OLT.net
>>841
あとビルドするときにscssをcssとして出力（package.jsonに記載）したほうがChromeのDeveloperで開発しやすいんでないかな
俺はそうした
jsにスタイル書くのって俺的には無理だったしscssの変数とかmixinどうすんのって感じだったから使ってない
855:デフォルトの名無しさん
21/01/01 20:12:23.69 /+4IUuLb.net
せっかくコンポーネントごとに分けてるのにグローバルな巨大cssを作るのもちょっとなぁ
scssだと入れ子が出来るだろうから素のcssよりゃマシだろうけど
856:デフォルトの名無しさん
21/01/01 22:01:26.56 7dc3kU9y.net
>>842
package.jsonに記載って何を記載するんですか？
857:デフォルトの名無しさん
21/01/01 22:03:44.11 gR0w6/3v.net
いいからガタガタ抜かさずemotion使ってみろってｗ
858:デフォルトの名無しさん
21/01/01 22:05:08.76 gOgGeOog.net
emotion は絶対にない。
linaria は許容できるけど
859:デフォルトの名無しさん
21/01/01 22:30:42.44 8TPOGttB.net
SPAで特定のページにnoindex付けたいんですがどうやるのが正解ですか？
今考えてるのは特定のページに入ったらjqueryでheadにnoindexをぶち込む方法です
860:デフォルトの名無しさん
21/01/01 22:34:56.11 JSeY8OLT.net
>>843
そうなんだけどさ、styled-componentの無理やり感が無理なのとjsがスタイルの記述ばかりになって見通し悪くなるし
あと使ったことないけどstyled-componentだとChromeのDeveloperToolでどうやって調整するんだろ
開発がWebアプリ系なら全体的にほとんど同じスタイルだからそれほど増えなくないかな
>>844
開発用パッケージにcss-loaderとsass-loaderとstyle-loaderをインストール
だったかな
861:デフォルトの名無しさん
21/01/01 22:40:09.79 HdS3p/N5.net
css in js だと goober が軽くてええな
862:デフォルトの名無しさん
21/01/01 22:43:08.73 gOgGeOog.net
styled component と emotion は全く同じ位置付けなんだけど。
styled componentが無理矢理でemotionが無理矢理じゃないのが理解できない。
dev toolpの問題は結構前に解消されてるでしょ。
css in js を使用する人は何を実現したくて使用するのか聞きたい
863:デフォルトの名無しさん
21/01/01 23:02:42.71 gR0w6/3v.net
emotionはstyled component形式でも書けるけどメインはcss prop形式だよ。
css prop形式使わないならstyled component使えばいい。
わざわざemotion使うからにはcss prop形式使うでしょ。
styled component形式は移行のためのサポートと思っとけばいい。
864:デフォルトの名無しさん
21/01/01 23:05:06.53 gOgGeOog.net
URLﾘﾝｸ(emotion.sh)
インターフェイスは styled componentと変わらないと思うけど
865:デフォルトの名無しさん
21/01/01 23:10:00.98 gOgGeOog.net
ちゃんと読まないでレスしてた
css prop形式だと余計に css in js 使う意味ないでしょ。
それだと classNameをconditionで操作してるのと変わらないでしょ
866:デフォルトの名無しさん
21/01/01 23:19:20.92 gR0w6/3v.net
あのねえ、styled componentより後発でたったそれだけのことで人気追い抜くわけないでしょ…
知らないならドキュメント読んで使ってみなさいよ
867:デフォルトの名無しさん
21/01/02 00:13:03.58 gKf/Fv60.net
時代はtailwindCSS
868:デフォルトの名無しさん
21/01/02 15:35:58.93 RXFdEIXY.net
tailwindかtacyonsどっちか迷ってる俺に推しの一言をどうぞ
869:デフォルトの名無しさん
21/01/02 17:42:37.50 wubIjlLH.net
URLﾘﾝｸ(i.imgur.com)
もはや比較の必要あるか？というレベルで大差付けてるけども
最近の人気で言うとTailwindCSSかChakra UIかという感じやな、chakraはreact専用だけども。
870:デフォルトの名無しさん
21/01/02 20:18:33.44 7UePDUod.net
tailwindとchakra uiはスコープだいぶ違うと思うが。
前者はCSSフレームワーク、後者はreact用uiツールキットでしょ
871:デフォルトの名無しさん
21/01/02 22:31:31.83 wubIjlLH.net
>>858
立ち位置は完全には同じでないけど、被ってる部分は結構あってサイト内にも比較ページがあるくらい意識されてるよ。
URLﾘﾝｸ(chakra-ui.com)
背景も使い所も全く別物なら公式がわざわざ用意しないからね
872:デフォルトの名無しさん
21/01/03 00:49:54.47 U3X4E4MI.net
うんそれoverview読むだけでまったく別物だって分かるね
873:デフォルトの名無しさん
21/01/03 01:01:48.04 p2kXTSH1.net
全く別物ではないな中身見てないだろ
もちろん範囲外のものもカバーしてるけども
874:デフォルトの名無しさん
21/01/03 01:12:57.13 p2kXTSH1.net
例えば
Tailwindなら
<div className="w-full mx-4 my-2"></div>
Chakraなら
<Box w="full" mx={4} my={2}></Box>
で同じ結果になる。
colorもレスポンシブも同様にあるしな。
まぁ全く同じもので厳密に比較しないと死ぬ病気だったらすまんな、忘れてくれ。
875:デフォルトの名無しさん
21/01/03 01:16:24.80 U3X4E4MI.net
あほくさ。
上は単なるcssクラス
下はreactコンポーネントじゃん。
下はJSXで書いてるから似て見えるだけ。
実態はJS関数じゃん。
いったいどこが同じなのかｗ
cssなんて基本要素も甚だしいんだからそれで似てる言ってたらWeb用のありとあらゆるライブラリが似てるｗ
876:デフォルトの名無しさん
21/01/03 01:21:20.90 WJLaDztK.net
知らんけど使用感のことを言ってるんでしょ？
内部構造が別だからってギャーギャーつっかかってもしゃあないやん...
877:デフォルトの名無しさん
21/01/03 01:27:19.26 j7drLdmA.net
このフレームワーク流行ってるのか
使ってみようかな
趣味プロダクトのデザインマジで面倒だ
878:デフォルトの名無しさん
21/01/03 07:17:12.46 77GCy5PB.net
まあ>>859が正しいわな
どちらを使うかで迷う人が多いから、わざわざ比較ページでピンポイント比較しているわけで
ただChakraは、使うのを止めるってなった時に地獄を見そうだな
react-bootstrapで地獄を見た私はそう思うぜ
879:デフォルトの名無しさん
21/01/03 16:18:33.59 sJkgD0sU.net
materializecssってオワコンなの？
880:デフォルトの名無しさん
21/01/03 19:55:53.47 p2kXTSH1.net
URLﾘﾝｸ(i.imgur.com)
そーす
URLﾘﾝｸ(2020.stateofcss.com)
これ見るとまだオワコンではないと思う、他が大きく下げたものが多いから順位は上げてる。
TailwindCSSが断トツではあるけどね。
881:デフォルトの名無しさん
21/01/03 20:16:55.01 DBWyzvd0.net
でもお前らのゴミみたいなセンスじゃ何使ってもどうにもならないじゃん？
882:デフォルトの名無しさん
21/01/03 22:03:10.41 3GzJdVpR.net
はいはい
883:デフォルトの名無しさん
21/01/04 00:31:45.14 iT2qTMUm.net
>>869
ゴミみたいなセンスだから優秀なライブラリを使うんだろうが
OSSタダ乗りおじさん舐めんな
884:デフォルトの名無しさん
21/01/04 09:41:29.84 rgY6auQv.net
AWSのことかな？ｗ
批判にあわてて援助し出したんだっけ？ｗ
885:デフォルトの名無しさん
21/01/04 16:45:28.03 qovFEaH+.net
ちょっと何言ってるか分からない
886:デフォルトの名無しさん
21/01/04 17:33:54.18 v/b/bq9A.net
意味不明だな
887:デフォルトの名無しさん
21/01/05 17:59:59.74 DKe92MJE.net
スライムというワイルドカード
888:デフォルトの名無しさん
21/01/06 19:42:43.06 V+n1SaTt.net
jqueryUIたいなライブラリー
なにか知りませんか？
Reactで使いますが、
React用じゃなくても良いですので。
889:デフォルトの名無しさん
21/01/07 00:03:32.99 HeEo+TnW.net
JQuery UIでいいじゃんそれ
890:デフォルトの名無しさん
21/01/07 00:36:41.77 P60007ut.net
BootstrapとかMaterial-UIの事言ってる？
891:デフォルトの名無しさん
21/01/07 12:47:58.31 IsAkKduI.net
bootsrtapは？
892:デフォルトの名無しさん
21/01/07 15:12:43.36 BMEPnbk6.net
bootstrapよりどちらかというとvelocityとかじゃね
893:デフォルトの名無しさん
21/01/07 19:07:40.82 XRImqR79.net
JQuery UIの主にインタラクションのような機能です。
Draggable
Droppable
Resizable
Selectable
Sortable
自前のコントロールを作ろうとすると必ずこの壁にぶち当たります。
894:デフォルトの名無しさん
21/01/07 20:50:34.46 ikfTGx5+.net
React に、そういう機能のコンポーネントは無いの？
895:デフォルトの名無しさん
21/01/07 22:24:29.72 8S5jtpKX.net
ないと思う
俺もjQueryUIのコンポーネント使いまくってるやつは移行が不可能
全部作らないといけないし
新規でやるときは使うんだが
896:デフォルトの名無しさん
21/01/07 23:16:04.95 3TLTtAUE.net
いや少なくともReact DnDでuseDragとuseDropはあるけど…？
そういうことじゃなく？？
897:デフォルトの名無しさん
21/01/08 00:07:17.50 BMLciGfP.net
ReactでjQueryUIを使う場合、
なのか問題とかあるのかな？
898:デフォルトの名無しさん
21/01/08 00:48:37.80 DKQwsFSV.net
仮想DOM のReact と、実DOMを更新するjQuery の更新タイミングを、
React のタイミングに合わせる必要がある
合っていないと、jQueryで更新しても、
その後、Reactでは更新していないと思われて、元の状態に戻ってしまう
899:デフォルトの名無しさん
21/01/08 02:03:55.07 BMLciGfP.net
>>886
それはなんとか大丈夫かな？
それよりもjqueryUIのベストなロードの方法はなんだろうか？
900:デフォルトの名無しさん
21/01/08 02:38:29.42 K8R3TNe9.net
いやだからjQueryUI互換のReactのコンポーネントライブラリが欲しいんだよ
なんやかんやいってjQueryUIの出来はめちゃくちゃいい
901:デフォルトの名無しさん
21/01/08 02:40:50.44 hM6lluL1.net
なんでUIライブラリ二重に使おうとするわけ？
野球帽の上にシルクハット被っても問題ないかな？と言ってるに等しいのでは？
これは問題あるともないとも言える。
可能不可能で言えば問題ないとも言えるが、バカに見えるという点では問題あると言える。
902:デフォルトの名無しさん
21/01/08 02:44:47.94 BMLciGfP.net
>>889
jqueryUIよく知ってますか？
903:デフォルトの名無しさん
21/01/08 02:44:56.99 K8R3TNe9.net
>>889
バカはお前だろ
jQueryUIはコンポーネントライブラリだぞ
904:デフォルトの名無しさん
21/01/08 07:47:08.14 c1yN1piV.net
俺はangular使ってるがmaterialUIがまんまそれに相当する
React にもあるはず。ちゃんと探そう
905:デフォルトの名無しさん
21/01/08 08:02:05.71 tSEaWM43.net
あちこちで言われてるんだからいい加減理解してほしいもんだけど
ReactとかはjQueryの代替にはならないの
ウェブサイト全体をウェブアプリに作り変える場合に使うもので
インターフェースはほぼ全部作り変えでUIを自分で作るためのものなの
jQueryだけじゃなくてブラウザ標準のDOM APIとも相性が悪い
全てをReactのやり方に置き換えるレベルじゃないと単に開発しづらくなるだけ
jQueryのシェアは去年一年で3%増えました。主に今までなにも使ってないところが
採用するのがjQueryです。まだ増え続けています。
その他のフレームワークは0.1%増えるか増えないかだよ
URLﾘﾝｸ(w3techs.com)
殆どのところは開発効率が上がらないか逆に下がってしまって却下されてるんだろう
906:デフォルトの名無しさん
21/01/08 08:08:57.80 sdGloSCX.net
Webサイトは改修しやすくないといけないからな
Reactでガチガチに作っても運用の人たちが困る
907:デフォルトの名無しさん
21/01/08 08:12:22.84 A+Em08N2.net
Webサイト → バニラ or jQuery
Webアプリ → Reactとか
これで結論出てる
908:デフォルトの名無しさん
21/01/08 08:13:08.49 DKQwsFSV.net
Ruby on Rails では、Bootstrap を使うから、
その依存関係で、jQuery も自動的に入る
React は、コンポーネントとして使う
909:デフォルトの名無しさん
21/01/08 08:50:47.46 BMLciGfP.net
意味も分からないバカが大量に沸いて出た。
あるいは、また自演坊の出現か？
910:デフォルトの名無しさん
21/01/08 09:21:04.83 Rc/BvzGB.net
Kentaだなってすぐわかる
911:デフォルトの名無しさん
21/01/08 09:44:49.72 A+Em08N2.net
UIくらい自分で解決しろよってことだなゴミカス
912:デフォルトの名無しさん
21/01/08 10:35:18.69 AdXs4K9l.net
う～んこの特徴的な文章
913:デフォルトの名無しさん
21/01/08 12:05:31.74 hYPH6FIY.net
JQuery UIをぐぐってみた感じ、完全な代替品はreactには無いんじゃないの？
自分がスクラッチしたUIに後からjsの振る舞いを付けてくれるライブラリ群って事だよね。
react、vueの場合、uiとjsの振る舞いをセットでコンポーネント化してあるものがメジャーだから、それらを採用してcssハックで見た目をカスタマイズするしかないと思う。
(コンポーネントによってはslotとかで後から自由にuiを付けられるものもあるので、ぜひドキュメントを見てもらえれば)
914:デフォルトの名無しさん
21/01/08 14:48:23.62 n+eqhbpb.net
あの、いまvueで実装してみたくてテストしていたんですが、
URLﾘﾝｸ(i.imgur.com)
イメージとしては{{message}}のところにデフォで表示される1というメッセージがコンポーネントで作ったボタンを押したらqqqqしたいんです
で、画像のように書いたところalertは表示されるんですが、内容が変わりません
これはおそらくコンポーネントの中に{{message}}とdataも入れてあげれば変わるようにはなるとおもうのですが、
やりたいことはコンポーネントで作ったカスタムボタンを押したらそのコンポーネント外に書いてある{{message}}に値をセットさせたいのです
これってどのように実装すればいいんでしょうか？
915:デフォルトの名無しさん
21/01/08 15:45:58.45 BMLciGfP.net
const element = <div id="A" />;
：
element.props.id = "B"; //--- TypeError: Cannot assign to read only property 'props' of object '#<Object>'
上記でエラーになるんですが、一度設定したプロパティを変更する事は可能？
もしかして出来なかったのだろうか...
916:デフォルトの名無しさん
21/01/08 19:38:17.54 hYPH6FIY.net
Emitを使えばいける。
vueのドキュメントのemitかstoreパターンの項を一度読んだ方が効率がいいと思う。
もしくはハンズオンの書籍で体系的に学ぶか。
またエディタはvscodeとか使った方が時短になります。
917:デフォルトの名無しさん
21/01/08 19:56:38.91 k0iEsoH9.net
プロパティは親からしか、変更できない。
dataとコンポーネントを紐付けている場合は、プロパティをwatchして変更を検知し、dataに反映する必要あり。
918:デフォルトの名無しさん
21/01/10 16:53:28.20 WtiCCgZ7.net
vue3、vue-cliのデフォルト設定だとローカルサーバーでtsファイルに定義したtypeの再コンパイルが走らなくてきっつー。
解決してる人いたら設定教えてくださいっす。
919:デフォルトの名無しさん
21/01/11 01:16:33.18 Nxf8SjHi.net
>>902
そんなあなたにvuex
920:デフォルトの名無しさん
21/01/11 08:18:12.32 yItx+DMm.net
>>906
serveでってことだよね。何もせずとも普通にやってくれるが？
921:デフォルトの名無しさん
21/01/13 16:35:56.54 atGCk1//.net
jotaiっていうReact用の状態管理ライブラリめちゃくちゃ良いじゃない
なんでこれ話題になってないの？
922:デフォルトの名無しさん
21/01/13 16:45:17.31 aKycOZrd.net
いいのはたくさんある。
だが結局は多くの人が使っているものが普及する
923:デフォルトの名無しさん
21/01/13 17:03:02.91 mK+3gZUP.net
>>909
前スレでとっくに既出。
449 デフォルトの名無しさん 2020/08/31 02:31:14
Reactのrecoilいいな
useContextの欠点を補完してる
もうReduxなんか必要ねえは
460 デフォルトの名無しさん 2020/09/11 22:12:09
>>449
これも面白そう
Jotai, a New Granular State Management Library for React
URLﾘﾝｸ(www.infoq.com)
たぶん日本語の「状態」からｗ
924:デフォルトの名無しさん
21/01/13 17:28:20.42 atGCk1//.net
>>911
おー出てたか
recoilよりはかなり使いやすい
とりあえず趣味プロダクトで使ってみる
925:デフォルトの名無しさん
21/01/13 19:06:48.50 J1EgIBFs.net
女体
926:デフォルトの名無しさん
21/01/13 19:40:18.84 mK+3gZUP.net
それはにょたいと読むから違うと思う
927:デフォルトの名無しさん
21/01/14 06:26:51.19 C2CclXL8.net
またみずちが変なこと言ってんなｗ
jQueryを求めてないって考えが間違いなんだってば
2021年1月時点のシェア 77.2%
URLﾘﾝｸ(w3techs.com)
2020年の1月から一年で +3.0%
今日の時点でシェア + 0.1%
需要は未だにjQueryが一番あるというのに
それを理解できないおじさん
928:デフォルトの名無しさん
21/01/14 06:47:13.36 mrWYZ3Pm.net
すなわち jQuery はウェブ制作板って事だろ。
929:デフォルトの名無しさん
21/01/14 07:37:51.87 ime41wMA.net
jQueryはDOMラッパーとしてしか使ってないわ
930:デフォルトの名無しさん
21/01/14 07:58:35.14 mrWYZ3Pm.net
ここはム板だからjQueryはあまり流行らない。
しかし世界は依然としてjQueryで出来てるのだろう。
そもそも論としてウェブサイトはアプリじゃないので。
931:デフォルトの名無しさん
21/01/14 08:39:14.28 C2CclXL8.net
いい加減ウェブアプリではjQueryは適さないって言えばいいのに
なぜかjQueryを目の敵にしてるｗ
自分が使わないからって、みんなも使わないと思うんじゃねーよ
932:デフォルトの名無しさん
21/01/14 08:45:47.25 cF+v3Ffe.net
正直jQueryの話をされても、EVの話をしてる時に馬車の話を始められるような気分
933:デフォルトの名無しさん
21/01/14 09:05:51.42 C0zlkM1X.net
ここはウェブサイトについて語る場所ではないので
934:デフォルトの名無しさん
21/01/14 12:43:00.94 4wMNB5xS.net
なんでこのスレタイ見て単なるウェブサイトの話題だと思うのか
935:デフォルトの名無しさん
21/01/14 16:42:19.64 KwILXC98.net
jQuery使ってる連中って、そもそもSPA用の開発環境構築出来るだけのスキルがないだろ
npmコマンド叩けるかも怪しい
936:デフォルトの名無しさん
21/01/14 17:33:50.48 RlMq/Epg.net
SPA用の開発環境構築するのが目的となってるなｗ
必要ならやるだけだろ
937:デフォルトの名無しさん
21/01/14 18:40:14.24 KwILXC98.net
SPA開発が流行らない理由は明白で、保守出来るやつが少なすぎるのよな
開発環境構築するのが目的のエンジニアがいると思うやつとか、
世間は頭が悪いやつが多すぎるのよ
938:デフォルトの名無しさん
21/01/14 19:54:36.53 YZxjw0oN.net
jQueryが使われてるというよりリプレイスできないから
シェアがそのままなんだろう
巨大サービスを作り直すとかGAFA以外無理だろう
939:デフォルトの名無しさん
21/01/14 19:59:19.79 0OjTyh5I.net
javaパーシステム屋と業務システム開発してるんだが俺のSPAフロントにビビっててこいつらいつの時代の連中なんだって感じ
誰一人理解してない
940:デフォルトの名無しさん
21/01/14 20:02:57.14 YZxjw0oN.net
一時期jQuery+handlebars+railsで無双してたな
フルスタックのフリーランスだったからマジで稼げた
最近は要素技術が多くなり過ぎて
全部1人でやるのが難しくなってきた
941:デフォルトの名無しさん
21/01/14 20:15:26.01 uwcPbgN/.net
QiitaとかDev.toとか見てるとNext.jsが破竹の勢いに見える
942:デフォルトの名無しさん
21/01/14 20:26:00.99 T4mjjynb.net
少なくとも日本でreactやvueを採用するって10%も無い気がする
それくらい何というか使える人も案外少ないし概念もややこしいのかなと
誰かが構築している上で構築した人の説明があって単にプログラム書くだけなら
案外簡単とは思うけど、一から構築するとなるとある程度知らないと出来ないだろうし
世界ではこの辺の技術の最先端が前に行き過ぎという感じがするなぁ
かといって今更jQueryで書く気はしないけど現実は中々そうは行かないという感じか
943:デフォルトの名無しさん
21/01/14 20:36:48.04 1FBYdS11.net
一番需要があると一番最高な技術なんだそうだｗ
944:デフォルトの名無しさん
21/01/14 21:06:57.91 pw+xUaFj.net
一番需要があるからといって、一番最高な技術なわけじゃない
一番需要があるのは、一番バランスがいい技術なんだ
何が一番なんなのか、そこを間違えてはいけない
945:デフォルトの名無しさん
21/01/14 21:30:12.38 ime41wMA.net
react圧倒的だな
URLﾘﾝｸ(trends.google.co.jp)
946:デフォルトの名無しさん
21/01/14 21:36:43.32 pw+xUaFj.net
>>933
調べなきゃ使い方がわからないとも言えるんだよな
947:デフォルトの名無しさん
21/01/14 22:54:19.75 cF+v3Ffe.net
Reactそんなに難しいかな？
DOMとJSさえ把握してれば、わりとすぐ使えようになる気がするけど
948:デフォルトの名無しさん
21/01/14 23:14:01.32 QYOIxwgk.net
>>930
Wappalyzer入れながら自分の知ってるサービス見てみたら？
知らんつもりで使ってるかもしれんよ。
ユーザ企業だけど、割とベンダーはReactかVue使ってくるし、
俺が作ってるのはVue使ってる。
949:デフォルトの名無しさん
21/01/14 23:24:32.61 YZxjw0oN.net
>>933
なんで急落してるんだ？
950:デフォルトの名無しさん
21/01/15 01:20:06.11 qcfmQYUH.net
DOM扱いは明らかにreactのがjqueryより楽だけど、非同期処理に関してはjqueryのが楽だわ。
951:デフォルトの名無しさん
21/01/15 01:26:00.65 qV+ZeCor.net
非同期処理はasync awaitで決着ついてる
952:デフォルトの名無しさん
21/01/15 01:57:16.01 qcfmQYUH.net
ついてねーよカス。そのコードをどこに置くかって話だよ。
953:デフォルトの名無しさん
21/01/15 01:58:51.99 qV+ZeCor.net
>>940
おまえは一生ajax読んどけクズが
954:デフォルトの名無しさん
21/01/16 22:08:24.04 J+DIrtXG.net
JQueryとVue.jsのどちらを勉強しようか悩んでいたけど、
955:target="_blank" class="reply_link">>>915を見ると、 JQueryの方が良さそうだね。
956:デフォルトの名無しさん
21/01/16 22:10:23.07 HVEkoRC9.net
草
スレが加速しそうなレス
957:デフォルトの名無しさん
21/01/16 22:28:35.19 7EFKht41.net
まあ初心者なら仕方ない
958:デフォルトの名無しさん
21/01/16 23:07:21.18 t4nHUbXC.net
釣りだろ
959:デフォルトの名無しさん
21/01/16 23:16:41.06 jZHiFUeq.net
片方しか勉強できない病
960:デフォルトの名無しさん
21/01/16 23:41:29.27 7+s5ajVF.net
新規にやるならReactの方がいいだろ
なぜVueに飛びつこうとするのか
961:デフォルトの名無しさん
21/01/16 23:44:07.37 EYVeHh6u.net
jQueryも知らない初学者に無茶言うなよ…
962:デフォルトの名無しさん
21/01/16 23:54:17.91 X8J3okh4.net
実質的にNextが使えないこの先はNuxtにすべきか悩み中
963:デフォルトの名無しさん
21/01/17 01:07:10.11 8yxv55PR.net
ぶっちゃけReactって覚えること少ないから初心者向けだと思うけどね
その分全部自分で書かなきゃならんし
hooksみたいなとっつきにくいものを身につけなきゃならない
Vueは覚えると楽だけど覚えるまでがすごく大変
964:デフォルトの名無しさん
21/01/17 01:37:41.05 CR1cS2lt.net
jQueryなんて勉強するものじゃないぞ。
あーめんどくせーってなったときjQuery つーかおってちょろっと書くもの。
jQueryすらお勉強しなきゃ使えないってんならプログラム全般致命的に向いてない。
965:デフォルトの名無しさん
21/01/17 07:33:09.60 r01V6dG2.net
同じことがreactにも言える。
プログラミングを簡単にするものだから楽になってるはずのもの
通常よりも楽になってるはずなのに、それを使うのに苦労してるようじゃ駄目
勉強してようやくreact使えるようじゃプログラム全般に向いてない
966:デフォルトの名無しさん
21/01/17 09:48:04.10 d8MroxOV.net
>>949
実質的にnextが使えないってどういうこと？
967:デフォルトの名無しさん
21/01/17 09:56:23.65 1YpVluAF.net
Vercel向けに最適化されてるってアレでしょ。OSSだしそんなに影響ないと思うけど。
968:デフォルトの名無しさん
21/01/17 10:03:56.79 mfJLlMXm.net
jQueryとvue.jsは並用出来るのでしょうか？
969:デフォルトの名無しさん
21/01/17 10:29:39.67 Yo3g4fKq.net
jqueryのカラム話題はこっち↓でやってくださいね
守らないと荒らしとみなされますよ
Vue vs React vs Angular vs jQuery Part.3
ｽﾚﾘﾝｸ(tech板)
970:デフォルトの名無しさん
21/01/17 10:52:38.90 d8MroxOV.net
vercel向けに最適化されてるのはわかるけど、そんな問題じゃないと思うけどね
971:デフォルトの名無しさん
21/01/17 10:57:14.69 d8MroxOV.net
これから先もエッジケースでvercel贔屓の開発は進むかもしれないけど、それが問題になるケースはなさそうだけどね
972:デフォルトの名無しさん
21/01/17 11:18:56.65 r01V6dG2.net
DOM APIとvue.jsは並用できるのかな？
という話題はここでOK？
973:デフォルトの名無しさん
21/01/17 12:30:38.61 d8MroxOV.net
>>959
なんで併用したいの？
そもそもreactやvueを使うと生のdomを触る機会は基本的にないはずだよ。
974:デフォルトの名無しさん
21/01/17 12:52:13.58 wK0lC+BJ.net
ふつう焼いたDOMだよな
975:デフォルトの名無しさん
21/01/17 13:10:51.08 mfJLlMXm.net
>>961
俺は刺し身でいく。
976:デフォルトの名無しさん
21/01/17 13:23:20.62 72VIHRdN.net
スカート付きか
977:デフォルトの名無しさん
978:2021/01/17(日) 14:11:45.46 ID:r01V6dG2.net
979:デフォルトの名無しさん
21/01/17 14:33:09.85 d8MroxOV.net
なるほど
それでいうと使える。
URLﾘﾝｸ(ja.reactjs.org)
ただ使う場合はrefを使用してdomにアクセスする様にしてね。上のリンクのいつrefを使うかにも書いてあるけど
980:デフォルトの名無しさん
21/01/17 14:35:37.43 d8MroxOV.net
俺が貼ったdocにはcreateRefが使われてるけど、今はuseRefがあるから、それを使えばいいと思う。
981:デフォルトの名無しさん
21/01/17 15:56:07.02 r01V6dG2.net
>>965
それができるならjQueryでも同じ方法でできますね。
jQueryはただのDOM操作ライブラリですから。
こういう聞き方をするのが良さそうです。
982:デフォルトの名無しさん
21/01/17 17:20:00.12 d8MroxOV.net
>>967
うん。jqueryも使えるよ。
ただ、reactやvueを使っててjqueryを導入したいと思うケースを俺は思いつかない。
983:デフォルトの名無しさん
21/01/17 18:00:08.77 mJ1vDarZ.net
最近知ったけど
reactjsexample.com
ってサイトいいね。いい感じの部品が結構色々ある
984:デフォルトの名無しさん
21/01/17 20:51:40.49 72VIHRdN.net
仮想DOM使いたくないならsvelteとか使えばいいじゃん
フレームワーク上でjqueryを使う理由ってなによ
985:デフォルトの名無しさん
21/01/17 21:08:38.19 BpZanF9R.net
通信でajaxでも使いたいんじゃない？
986:デフォルトの名無しさん
21/01/17 21:23:38.04 1YpVluAF.net
fetchでいいじゃん
987:デフォルトの名無しさん
21/01/17 21:25:14.65 8yxv55PR.net
ajaxって今思うとすげー恥ずかしいメソッド名だよな
988:デフォルトの名無しさん
21/01/17 21:26:50.06 OsPht3CQ.net
>>970
jQueryを使うのではなくて、
jQueryを使って作った多くの資産、ライブラリを使うんだよ
導入検討のためのサンプルとかPoCとか使い捨てプログラムとか
寿命が短いものばかり作ってんの？