実際どうなん?
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Angular Part.5
https://mevius.5ch.net/test/read.cgi/tech/1596029929/
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください
Angular, Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおk。
Vue vs React vs Svelte Part.6
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2020/10/27(火) 13:09:05.31ID:5aYZ+KyB761デフォルトの名無しさん
2020/12/29(火) 15:05:12.04ID:xrSERZg5 >>759
焦って途中でレスすんなよみっともない。
ほかのすべての言語はできるがC#だけは出来ない、と言ってるんではない。
C#が得意な事とそうではない事があることは認識しろ、と言ってる。
他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#なら、C#でも、ってのは、そりゃ原理上可能だろ。可能じゃなかったらチューリング完全でない。
ただ、向いてるかって聞くと、それぞれもっと向いているものを知ってる人間は居るってことなんだよ。
ちょっと冷静に考えろ。
C#は好きだが、議論の道具として叩いてて、反対側にはメリットもあるのはわかってんよ。
焦って途中でレスすんなよみっともない。
ほかのすべての言語はできるがC#だけは出来ない、と言ってるんではない。
C#が得意な事とそうではない事があることは認識しろ、と言ってる。
他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#なら、C#でも、ってのは、そりゃ原理上可能だろ。可能じゃなかったらチューリング完全でない。
ただ、向いてるかって聞くと、それぞれもっと向いているものを知ってる人間は居るってことなんだよ。
ちょっと冷静に考えろ。
C#は好きだが、議論の道具として叩いてて、反対側にはメリットもあるのはわかってんよ。
762デフォルトの名無しさん
2020/12/29(火) 15:10:39.54ID:EHaGj/ct >>757
>「気に食わんけど耐えるしかない or ワークアラウンドで対応」
>これはなんの解決でもない。
GCの差し替えができないならそうするしかない
C#は他の言語と違って安全なメモリ管理サポートが充実しているので「耐えるしかない」ということはない
>非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの
非同期を跨いで利用される変数のスコープが伸びることは必然だから問題じゃない
もし問題だというならそれはシンタックスシュガーのせいではなく非同期アルゴリズムの設計に問題がある
言語のせいではなく設計ミス
>他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
そうじゃない「他の言語でできないor難しいことが簡単に出来る」と言ってる
たとえばC#のref構造体やspanのように安全に低頻度のアロケーションをサポートするスクリプトが幾つあるだろう
>「気に食わんけど耐えるしかない or ワークアラウンドで対応」
>これはなんの解決でもない。
GCの差し替えができないならそうするしかない
C#は他の言語と違って安全なメモリ管理サポートが充実しているので「耐えるしかない」ということはない
>非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの
非同期を跨いで利用される変数のスコープが伸びることは必然だから問題じゃない
もし問題だというならそれはシンタックスシュガーのせいではなく非同期アルゴリズムの設計に問題がある
言語のせいではなく設計ミス
>他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
そうじゃない「他の言語でできないor難しいことが簡単に出来る」と言ってる
たとえばC#のref構造体やspanのように安全に低頻度のアロケーションをサポートするスクリプトが幾つあるだろう
763デフォルトの名無しさん
2020/12/29(火) 15:24:29.79ID:EHaGj/ct >高いよ。
>お前あんまりミッションクリティカル系でC#使ってないだろ。
処理系のメンテコストの話がミッションクリティカルでのC#利用経験の話になるのはなぜ?
>違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる?
>特にPCL。あれで現に破綻しただろ。
PCLは確かにあまりうまく行っていなかった
うまく行っていなかったからこそだ
本格的なマルチプラットフォーム対応のためのCoreでありStandard
>安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
>お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
もちろんメンテナンスは続けてるだろ
古いコード新しいコード両方が安定して稼働するからこそ安価にメンテナスが可能となる
APIが急になくなったらちょっとしたメンテナンスでも大騒ぎだ
>そのあたりで踏み抜くものが多すぎるんだよ。
多すぎるというからには何かしら数字が出てるのだと思うけど示せる?
>コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
すまん
正直意味不明なので説明を求む
>なんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの?」という話なんだよ。
その属性をつけるのは結局手動だろう?
自動化信仰も結構だが世の中全てを自動化できるわけではない
手動で解決してる理由は機械的、自動的に決定できないからだよ
機械的、自動的に決定できないものに対して取れる最もマシな方法は昔から決まってて
事故が起こりにくい方をデフォルトにする
どちらも安全なら統計を撮って利用頻度で決める
>お前あんまりミッションクリティカル系でC#使ってないだろ。
処理系のメンテコストの話がミッションクリティカルでのC#利用経験の話になるのはなぜ?
>違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる?
>特にPCL。あれで現に破綻しただろ。
PCLは確かにあまりうまく行っていなかった
うまく行っていなかったからこそだ
本格的なマルチプラットフォーム対応のためのCoreでありStandard
>安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
>お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
もちろんメンテナンスは続けてるだろ
古いコード新しいコード両方が安定して稼働するからこそ安価にメンテナスが可能となる
APIが急になくなったらちょっとしたメンテナンスでも大騒ぎだ
>そのあたりで踏み抜くものが多すぎるんだよ。
多すぎるというからには何かしら数字が出てるのだと思うけど示せる?
>コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
すまん
正直意味不明なので説明を求む
>なんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの?」という話なんだよ。
その属性をつけるのは結局手動だろう?
自動化信仰も結構だが世の中全てを自動化できるわけではない
手動で解決してる理由は機械的、自動的に決定できないからだよ
機械的、自動的に決定できないものに対して取れる最もマシな方法は昔から決まってて
事故が起こりにくい方をデフォルトにする
どちらも安全なら統計を撮って利用頻度で決める
764デフォルトの名無しさん
2020/12/29(火) 15:34:45.80ID:EHaGj/ct >>760
>コンテナ化する事を動作保証と言うぞ。
いや言わない
基本的に今まで動作していた環境で同じように動作することを動作保証という
新しくコンテナに載せ替えるかどうかは動作保証とはまったく別のベクトルの話であって関係がない
>安定して利益を生み出す、で履き違えるな。
>負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
技術的負債のことを言いたいのだろうけど
古いAPIが全て負の遺産であるような認識は典型的な間違いだぞ
たとえ古いAPIを使っていてもテストが整備されていて設計が美しく開発環境の準備が難しくないならそれは借金でもなんでもない
>言語のAPIが急にサポート切れ、な。
>いつ誰がやらかしたかな?
.NETでは幸いなことにまだぶち当たったことがない
>コンテナ化する事を動作保証と言うぞ。
いや言わない
基本的に今まで動作していた環境で同じように動作することを動作保証という
新しくコンテナに載せ替えるかどうかは動作保証とはまったく別のベクトルの話であって関係がない
>安定して利益を生み出す、で履き違えるな。
>負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
技術的負債のことを言いたいのだろうけど
古いAPIが全て負の遺産であるような認識は典型的な間違いだぞ
たとえ古いAPIを使っていてもテストが整備されていて設計が美しく開発環境の準備が難しくないならそれは借金でもなんでもない
>言語のAPIが急にサポート切れ、な。
>いつ誰がやらかしたかな?
.NETでは幸いなことにまだぶち当たったことがない
765デフォルトの名無しさん
2020/12/29(火) 15:40:20.23ID:Fq3XcUlo なげーなー
C#はSPAには特化してない
歴史的な経緯があるからそのせいで扱いにくいこともある
SPA作るなら特化しているReact+ts使った方が幸せになれる
ってこと?
C#はSPAには特化してない
歴史的な経緯があるからそのせいで扱いにくいこともある
SPA作るなら特化しているReact+ts使った方が幸せになれる
ってこと?
766デフォルトの名無しさん
2020/12/29(火) 15:43:25.20ID:EHaGj/ct >>761
>焦って途中でレスすんなよみっともない。
うるせえな寒くて手が滑ったんだよ
暖房つけたからもう大丈夫
>C#が得意な事とそうではない事があることは認識しろ、と言ってる
C#より上手く特定の分野を実装できる言語はあると思う
しかしC#は各分野で最高とまでいかなくとも何でも得意で
C#が特別に苦手なことというのはない
そういう成績オール5 or 4的なところが気に入ってる
>他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#を使えるなら他を使う「積極的」なメリットは無い
他の言語が特別に得意な分野がどうしても必要なときに仕方なくその言語を使う程度の塩梅でおk
>焦って途中でレスすんなよみっともない。
うるせえな寒くて手が滑ったんだよ
暖房つけたからもう大丈夫
>C#が得意な事とそうではない事があることは認識しろ、と言ってる
C#より上手く特定の分野を実装できる言語はあると思う
しかしC#は各分野で最高とまでいかなくとも何でも得意で
C#が特別に苦手なことというのはない
そういう成績オール5 or 4的なところが気に入ってる
>他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#を使えるなら他を使う「積極的」なメリットは無い
他の言語が特別に得意な分野がどうしても必要なときに仕方なくその言語を使う程度の塩梅でおk
767デフォルトの名無しさん
2020/12/29(火) 15:49:41.14ID:EHaGj/ct >>765
>C#はSPAには特化してない
SPAについてはまだまだ黎明期
>歴史的な経緯があるからそのせいで扱いにくいこともある
新規に開発する分には扱いやすい
レガシーがモダンと比較して扱いにくいことがあるがそれはレガシーなので仕方がないこと
レガシーが安定して動作するよう後方互換性とセキュリティパッチが充実しているので
レガシーのメンテナンスを最小化することができる
>SPA作るなら特化しているReact+ts使った方が幸せになれる
人による
現時点ではReact+TSのほうが支持者が多い
>C#はSPAには特化してない
SPAについてはまだまだ黎明期
>歴史的な経緯があるからそのせいで扱いにくいこともある
新規に開発する分には扱いやすい
レガシーがモダンと比較して扱いにくいことがあるがそれはレガシーなので仕方がないこと
レガシーが安定して動作するよう後方互換性とセキュリティパッチが充実しているので
レガシーのメンテナンスを最小化することができる
>SPA作るなら特化しているReact+ts使った方が幸せになれる
人による
現時点ではReact+TSのほうが支持者が多い
768デフォルトの名無しさん
2020/12/29(火) 15:51:29.01ID:xrSERZg5 >>766
全部言い訳だわ。
GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか?
IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う?
ケース知らなすぎるだろ。
他の事も色々間違ってるがもうそもそもおかしい。
C#は別になんでも得意じゃねえぞ。
オール3だよ。
C#でこれは4だなって思うのはLinqぐらいだ。それももう追いつかれた。
他の言語を知らんから、本当の5を知らんのだろ。
積極的なメリットは無い。知らないからそりゃそうだろうな。
それでC#が好きだとほざくな。
全部言い訳だわ。
GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか?
IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う?
ケース知らなすぎるだろ。
他の事も色々間違ってるがもうそもそもおかしい。
C#は別になんでも得意じゃねえぞ。
オール3だよ。
C#でこれは4だなって思うのはLinqぐらいだ。それももう追いつかれた。
他の言語を知らんから、本当の5を知らんのだろ。
積極的なメリットは無い。知らないからそりゃそうだろうな。
それでC#が好きだとほざくな。
769デフォルトの名無しさん
2020/12/29(火) 15:55:19.91ID:yginI0z/ ・・・本当の5の言語って何や?
770デフォルトの名無しさん
2020/12/29(火) 16:04:46.05ID:xrSERZg5 >>769
人とニーズによるだろうけど、Goの並行処理とか、
Erlangのメッセージパッシングとか、
F#の測定単位とか、
Lispのマクロとかかな。
JavaScriptも、あれはあれでとても良いと思う。
人とニーズによるだろうけど、Goの並行処理とか、
Erlangのメッセージパッシングとか、
F#の測定単位とか、
Lispのマクロとかかな。
JavaScriptも、あれはあれでとても良いと思う。
771デフォルトの名無しさん
2020/12/29(火) 16:08:35.63ID:b5xW7Gve >>768
>GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか?
大抵のことはGCで問題ない
クリティカルなところでのC#なら安全に比較的細やかにメモリ管理ができるので問題ない
>IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う?
当たり前だがDisposeするまでだろ
非同期挟もうが挟むまいが不要になった時点で速やかに破棄される
awaitを使ったからと言って必要もないのに無駄に変数の寿命が伸びることはないよ
伸びるのは非同期処理を実装するのに本当に必要な変数だけだ
>本当の5を知らんのだろ。
例えば?
>GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか?
大抵のことはGCで問題ない
クリティカルなところでのC#なら安全に比較的細やかにメモリ管理ができるので問題ない
>IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う?
当たり前だがDisposeするまでだろ
非同期挟もうが挟むまいが不要になった時点で速やかに破棄される
awaitを使ったからと言って必要もないのに無駄に変数の寿命が伸びることはないよ
伸びるのは非同期処理を実装するのに本当に必要な変数だけだ
>本当の5を知らんのだろ。
例えば?
772デフォルトの名無しさん
2020/12/29(火) 16:11:47.13ID:Fq3XcUlo773デフォルトの名無しさん
2020/12/29(火) 16:24:08.58ID:Fq3XcUlo774デフォルトの名無しさん
2020/12/29(火) 16:24:33.75ID:b5xW7Gve >>770
果たしてそれがメインの開発言語を乗り換えるほどの価値があるかどうかだよね
自分はとてもではないがそうは思えない
もし本当にどうしても避けられずそれが必要になったら局所的にその言語で実装してメイン言語から呼び出すって形にするだろうな
まあGoぐらいなら別にメインにしてもいいかなぁ…とは思うがね(実際にはしないだろうけど)
果たしてそれがメインの開発言語を乗り換えるほどの価値があるかどうかだよね
自分はとてもではないがそうは思えない
もし本当にどうしても避けられずそれが必要になったら局所的にその言語で実装してメイン言語から呼び出すって形にするだろうな
まあGoぐらいなら別にメインにしてもいいかなぁ…とは思うがね(実際にはしないだろうけど)
775デフォルトの名無しさん
2020/12/29(火) 18:16:37.52ID:Hcyt9B7d C#は素敵な言語だけどさすがにオール5は言い過ぎたねって話だね
776デフォルトの名無しさん
2020/12/29(火) 18:29:46.92ID:Cpv18UIo なんでこの人たちいつもC#の話してるの?
777デフォルトの名無しさん
2020/12/29(火) 18:30:27.64ID:xrSERZg5778デフォルトの名無しさん
2020/12/29(火) 18:44:00.86ID:awsGRXp2 オール5の言語なんてLispしかないよ!DSLで何にでも特化できるから!神はLispで世界を作ったんだぜ!(ぐるぐる目)
冗談はさておき、昔のJSはLispの匂いがして好きだった。今は(TSは)Lispの匂いほぼなくなって、万人ウケしやすい言語になったと思う。
冗談はさておき、昔のJSはLispの匂いがして好きだった。今は(TSは)Lispの匂いほぼなくなって、万人ウケしやすい言語になったと思う。
779デフォルトの名無しさん
2020/12/29(火) 19:19:37.56ID:xrSERZg5 >>778
ほんとにそれよね。JSはC構文のLispっぽくて好きだったけど、TSでどんどん静的な言語になってしまってる。
ほんとにそれよね。JSはC構文のLispっぽくて好きだったけど、TSでどんどん静的な言語になってしまってる。
780デフォルトの名無しさん
2020/12/29(火) 19:25:03.79ID:PuaagtBb 高階関数で関数型プログラミングの匂いはするがLispの匂いはしない
Lispって全部がリストになってるから
Lispって全部がリストになってるから
781デフォルトの名無しさん
2020/12/29(火) 19:35:30.70ID:xrSERZg5 >>780
applyと分割代入あたりが、おおむね対応するんではなかろうか。
applyと分割代入あたりが、おおむね対応するんではなかろうか。
782デフォルトの名無しさん
2020/12/29(火) 19:39:46.86ID:LSI+C1uB C#をNGにしたら書き込み全部消えちゃった
783デフォルトの名無しさん
2020/12/29(火) 19:41:55.81ID:xrSERZg5 まあ、作った人がScheme意識してるって言ってるからな。
https://brendaneich.com/2008/04/popularity/
https://brendaneich.com/2008/04/popularity/
784デフォルトの名無しさん
2020/12/29(火) 19:47:54.10ID:awsGRXp2 全部がListだったらそれはもう匂いがするどころではなくLispそのものだと思う。
Lisp脳だったのでTS始めた時は型演算そのものを(Lispみたいに)JSで書かせてくれと思ったよw
Lisp脳だったのでTS始めた時は型演算そのものを(Lispみたいに)JSで書かせてくれと思ったよw
785デフォルトの名無しさん
2020/12/29(火) 19:53:01.60ID:awsGRXp2 Lispの匂いといえばMozillaのlet式が没ったのは返す返すも残念だった。今はdo式に期待してる
786デフォルトの名無しさん
2020/12/29(火) 21:12:55.98ID:LSI+C1uB787デフォルトの名無しさん
2020/12/29(火) 23:06:44.05ID:awsGRXp2 Lispのデータとソースコードは全てListである。
Lispは主にListを操作してプログラムする。
Lispには文は無く、式だけがある。
LispのマクロはListであるLispソースコードの操作をLispで行う。
Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。あらゆるコードを抽象化できる。
スレ違いだからあとは調べてね。
これは個人的な所感だけど、
ありとあらゆる式文が作れる(抽象化できる)ってことはつまり俺ルールがまかり通って分断を招く言語って事だから、そりゃ一般向けじゃないやね
Lispは主にListを操作してプログラムする。
Lispには文は無く、式だけがある。
LispのマクロはListであるLispソースコードの操作をLispで行う。
Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。あらゆるコードを抽象化できる。
スレ違いだからあとは調べてね。
これは個人的な所感だけど、
ありとあらゆる式文が作れる(抽象化できる)ってことはつまり俺ルールがまかり通って分断を招く言語って事だから、そりゃ一般向けじゃないやね
788デフォルトの名無しさん
2020/12/29(火) 23:19:25.78ID:c62SKept >>787
そのせいでクオートとか関数クオートみたいな邪悪な存在が生まれたのは無視かな?
そのせいでクオートとか関数クオートみたいな邪悪な存在が生まれたのは無視かな?
789デフォルトの名無しさん
2020/12/29(火) 23:26:15.08ID:Ba9B66hW >>787
長々と書いてるがメリットってこれだけだろ?
> Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。
DSLを作りたいやつがどれだけいるか知らんが
DSLというのはただの関数に過ぎない
だからどの言語でも関数を作ることで簡単にDSLを作れるぞ
長々と書いてるがメリットってこれだけだろ?
> Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。
DSLを作りたいやつがどれだけいるか知らんが
DSLというのはただの関数に過ぎない
だからどの言語でも関数を作ることで簡単にDSLを作れるぞ
790デフォルトの名無しさん
2020/12/29(火) 23:36:01.58ID:awsGRXp2 細かい反論はあるけど概ねご批判の通りだよ。
だから流行らない。俺は好きだけどね
だから流行らない。俺は好きだけどね
791デフォルトの名無しさん
2020/12/29(火) 23:38:23.99ID:Ba9B66hW https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E7%89%B9%E5%8C%96%E8%A8%80%E8%AA%9E/
> DSLは、大きく内部DSLと外部DSLに分類することができます。
>
> 内部DSL: 内部DSLは、汎用のプログラミング言語の書き方を工夫して、
> 見かけ上の構文を自然言語に近づけた言語です。
書き方を工夫するだけだからどの言語でも出来る
> 外部DSL: 外部DSLは、汎用のプログラミング言語とはまったく別の構文を持ったDSLです。
こっちはlispでも作りづらい
> DSLは、大きく内部DSLと外部DSLに分類することができます。
>
> 内部DSL: 内部DSLは、汎用のプログラミング言語の書き方を工夫して、
> 見かけ上の構文を自然言語に近づけた言語です。
書き方を工夫するだけだからどの言語でも出来る
> 外部DSL: 外部DSLは、汎用のプログラミング言語とはまったく別の構文を持ったDSLです。
こっちはlispでも作りづらい
792デフォルトの名無しさん
2020/12/29(火) 23:46:09.89ID:Ba9B66hW 内部DSLの場合、言語によって自然言語に近づけるといっても限界がある場合がある
えばC言語なら、 This("is", "a", "pen"); が限界だろう
これがRubyだと This "is" "a" "pen" となる
is とか a とか を定義すれば、This is a "pen" と書けるかもしれないな
だがシェルスクリプトであれば This 関数を作るだけで
This is a pen と書くことが出来る。
ダブルクォートでくくらなくても文字列として扱われるからだ
内部DSLを作るのに一番適した言語はシェルスクリプトだと思うが
それはそれとして、DSLを簡単に作れる言語の条件はリスト操作をしてるとかではなく
引数を () でくくらなくても良いとか最後にセミコロンがいらないとか
そういう言語ではないだろうか?自然言語は () でくくらないからな
えばC言語なら、 This("is", "a", "pen"); が限界だろう
これがRubyだと This "is" "a" "pen" となる
is とか a とか を定義すれば、This is a "pen" と書けるかもしれないな
だがシェルスクリプトであれば This 関数を作るだけで
This is a pen と書くことが出来る。
ダブルクォートでくくらなくても文字列として扱われるからだ
内部DSLを作るのに一番適した言語はシェルスクリプトだと思うが
それはそれとして、DSLを簡単に作れる言語の条件はリスト操作をしてるとかではなく
引数を () でくくらなくても良いとか最後にセミコロンがいらないとか
そういう言語ではないだろうか?自然言語は () でくくらないからな
793デフォルトの名無しさん
2020/12/29(火) 23:52:22.87ID:Ba9B66hW 引数の区切りにカンマが不要ってのもDSLに適した言語の条件かな
794デフォルトの名無しさん
2020/12/30(水) 00:05:32.15ID:TuVgzDLD >>789
kotlinぐらいじゃないかな。
無茶めな構文が変わるレベルのDSLが作れるの。
S式として成り立ってればどんな構文すら作れるから、関数を作ることで作れるとか言ってるレベルじゃないぞ。
それが良いことかはおいといて。
kotlinぐらいじゃないかな。
無茶めな構文が変わるレベルのDSLが作れるの。
S式として成り立ってればどんな構文すら作れるから、関数を作ることで作れるとか言ってるレベルじゃないぞ。
それが良いことかはおいといて。
795デフォルトの名無しさん
2020/12/30(水) 00:08:13.49ID:Zk/FBUc0 どんな構文でも作りたいわけじゃない
「自然言語」に近い構文を「簡単に」作れるというのが条件
自然言語というのはシンプルで、単語を並べるだけなのだ
仮にkotlinでC言語の構文に対応できたとして
それはDSLとしてはふさわしくない構文
「自然言語」に近い構文を「簡単に」作れるというのが条件
自然言語というのはシンプルで、単語を並べるだけなのだ
仮にkotlinでC言語の構文に対応できたとして
それはDSLとしてはふさわしくない構文
796デフォルトの名無しさん
2020/12/30(水) 00:08:25.33ID:olxuh5fb797デフォルトの名無しさん
2020/12/30(水) 00:15:06.44ID:Zk/FBUc0798デフォルトの名無しさん
2020/12/30(水) 00:19:04.50ID:Zk/FBUc0 あと「簡単に」ってのも重要
作れるけど大変っていうのは簡単ではない
作れるけど大変っていうのは簡単ではない
799デフォルトの名無しさん
2020/12/30(水) 00:19:15.74ID:olxuh5fb Lispは自然言語風ではないだろ
あの括弧なんとかしろよ
あの括弧なんとかしろよ
800デフォルトの名無しさん
2020/12/30(水) 00:21:48.47ID:TuVgzDLD DSLって別に自然言語に寄ってなくても良いんじゃないか?
ドメイン記述に便利な表記であればそれで良いかと。
昔ウィジェットツリーをそのまま書いたらマクロで展開されるとかそういうの書いたことあるけど、自然言語寄りではなかったな。
最近で言うとkotlinのankoみたいなやつ。
ドメイン記述に便利な表記であればそれで良いかと。
昔ウィジェットツリーをそのまま書いたらマクロで展開されるとかそういうの書いたことあるけど、自然言語寄りではなかったな。
最近で言うとkotlinのankoみたいなやつ。
801デフォルトの名無しさん
2020/12/30(水) 00:26:09.36ID:Zk/FBUc0 > DSLって別に自然言語に寄ってなくても良いんじゃないか?
それは正しいが「自然言語と異なる別のプログラム言語」を
覚え直さなければいけないのはナンセンスだろ
それは正しいが「自然言語と異なる別のプログラム言語」を
覚え直さなければいけないのはナンセンスだろ
802デフォルトの名無しさん
2020/12/30(水) 00:26:50.79ID:Zk/FBUc0 (なぜか「当分お断りしております。」が出たので分割して書き込み)
独自のDSLを作る場合、新たな言語を覚えなおさなくていいように
誰もが知ってる自然言語に近い構文にするのが普通
独自のDSLを作る場合、新たな言語を覚えなおさなくていいように
誰もが知ってる自然言語に近い構文にするのが普通
803デフォルトの名無しさん
2020/12/30(水) 00:27:23.67ID:Zk/FBUc0 そうしないとDSLを使うことで
804デフォルトの名無しさん
2020/12/30(水) 00:28:25.07ID:Zk/FBUc0 ぎゃくにこーどがわかりづらくなる
DSLの特徴である「ドメイン固有の処理を簡単に表現できる」に反してしまう
DSLの特徴である「ドメイン固有の処理を簡単に表現できる」に反してしまう
805デフォルトの名無しさん
2020/12/30(水) 00:29:06.25ID:Zk/FBUc0 (なんで「ぎゃくにこーどが」を漢字とカタカナにしたら書き込めないんだ?)
806デフォルトの名無しさん
2020/12/30(水) 00:30:13.27ID:Zk/FBUc0 「コ ー ド」をスペース抜いたら書き込めない
807デフォルトの名無しさん
2020/12/30(水) 00:34:39.76ID:DCxLNcGT こうやって言語機能そのものみたいな基本部分の重箱つついて、何かあるとすぐちゃぶ台返しして応用や発展的な話題出ないの最高に5chのプログラム板って感じ
808デフォルトの名無しさん
2020/12/30(水) 00:35:42.82ID:olxuh5fb そもそもすれ違いだぞ
809デフォルトの名無しさん
2020/12/30(水) 00:41:11.57ID:Zk/FBUc0810デフォルトの名無しさん
2020/12/30(水) 00:56:40.62ID:lXmFrXZN コード
811デフォルトの名無しさん
2020/12/30(水) 00:59:28.01ID:nb9M1V+x >>810
どうやらブラウザ(ユーザーエージェント?)も関係あるっぽい
Chromeでは書き込めず、Firefoxなら書き込めた
その他の情報も見てる可能性があるな
IPアドレスは変えてもクッキー消しても意味はなかった
どうやらブラウザ(ユーザーエージェント?)も関係あるっぽい
Chromeでは書き込めず、Firefoxなら書き込めた
その他の情報も見てる可能性があるな
IPアドレスは変えてもクッキー消しても意味はなかった
812デフォルトの名無しさん
2020/12/30(水) 01:01:03.26ID:eKh3SvG1 スレ違いなネタでろくに知識もないのに平気で一人で盛り上がってる感じ、またC#おじさんかよ。NGすとこ
813デフォルトの名無しさん
2020/12/30(水) 01:12:42.10ID:lGcdPzxm >>812
9月2日から10月10日までレスが3つしか付かなかった過疎スレだったんだよね
テーマに沿って話して過疎るか雑談でスレを伸ばすかのどっちかで雑談でもいいと思う
でないと話すことなくて過疎る
雑談が嫌なら来なければいい
9月2日から10月10日までレスが3つしか付かなかった過疎スレだったんだよね
テーマに沿って話して過疎るか雑談でスレを伸ばすかのどっちかで雑談でもいいと思う
でないと話すことなくて過疎る
雑談が嫌なら来なければいい
814デフォルトの名無しさん
2020/12/30(水) 01:42:40.61ID:zA1s3IaL なんでjs前提のスレで他言語について話してんだ○イジかよと思ったけど。もともと過疎スレだったのか。
フロントエンドFrameworkはすでに別にスレがあるから、雑談スレでもいいかもね。
フロントエンドFrameworkはすでに別にスレがあるから、雑談スレでもいいかもね。
815デフォルトの名無しさん
2020/12/30(水) 01:56:29.40ID:Cptlqs6D みんなどうやったら良いSPAが作れるか議論したいんじゃないの
今更だけどスレタイで技術を限定するのは世界を狭めていると思う
C#おじさんはうざいかもしれないがまがいなりにもSPAを作る技術があるわけで
今更だけどスレタイで技術を限定するのは世界を狭めていると思う
C#おじさんはうざいかもしれないがまがいなりにもSPAを作る技術があるわけで
816デフォルトの名無しさん
2020/12/30(水) 02:08:36.28ID:sThloFfy わいはSSRの方がすこだ!
817デフォルトの名無しさん
2020/12/30(水) 03:37:46.36ID:olxuh5fb C#おじさんの自演ここまでくると怖い
本当に年内に病院に行くべき
本当に年内に病院に行くべき
818デフォルトの名無しさん
2020/12/30(水) 05:45:50.88ID:WuRkJ7SN >>816
Next.jsなら今はSSG推奨
Next.jsなら今はSSG推奨
819デフォルトの名無しさん
2020/12/30(水) 06:08:39.70ID:npFXMZqI 時代はISR
820デフォルトの名無しさん
2020/12/30(水) 06:38:08.28ID:Kz0vlNp0821デフォルトの名無しさん
2020/12/30(水) 10:00:04.98ID:TuVgzDLD まあアホみたいにC#に反論して悪かった。
そりゃそうでそもそもスレチだわな。
React今更やり直してんだけど、スタイルってどうやってる?
Vueみたいにコンポーネントごとに書いといたらcssが一本ドーンとできるみたいな仕組みが欲しいんだが、見た感じなさそう。
css in jsでインラインスタイルみたいな感じで当てまくるのが王道なの?
そりゃそうでそもそもスレチだわな。
React今更やり直してんだけど、スタイルってどうやってる?
Vueみたいにコンポーネントごとに書いといたらcssが一本ドーンとできるみたいな仕組みが欲しいんだが、見た感じなさそう。
css in jsでインラインスタイルみたいな感じで当てまくるのが王道なの?
822デフォルトの名無しさん
2020/12/30(水) 11:50:39.35ID:mn0czGQ5 react というかNext.jsってpagesの中でscssをimport する時って
各エレメントにclassName={hoge.kage} って手動でクラス名を紐付けないと駄目なの?
比較して申し訳ないけど、vueだとcss側に*{color:red}とか.main{border:1px;}、html側に<div class="main">と書くだけで
コンポーネント単位でdata-v-xxxx ってスコープ切って紐付けてくれるんだが、そういうのは無し?
前の人と多分同じネタかなこれ
各エレメントにclassName={hoge.kage} って手動でクラス名を紐付けないと駄目なの?
比較して申し訳ないけど、vueだとcss側に*{color:red}とか.main{border:1px;}、html側に<div class="main">と書くだけで
コンポーネント単位でdata-v-xxxx ってスコープ切って紐付けてくれるんだが、そういうのは無し?
前の人と多分同じネタかなこれ
823デフォルトの名無しさん
2020/12/30(水) 12:16:17.47ID:TuVgzDLD824デフォルトの名無しさん
2020/12/30(水) 12:34:12.03ID:zA1s3IaL 横からだけど自分もそれ気になるなあ。
コンポーネントごとcssを別出しするとか色々あるみたいだけど、やり方が複数あって迷うなぁ。
Tailwind使ってるからスタイル自体そんなに充てないけども
コンポーネントごとcssを別出しするとか色々あるみたいだけど、やり方が複数あって迷うなぁ。
Tailwind使ってるからスタイル自体そんなに充てないけども
825デフォルトの名無しさん
2020/12/30(水) 12:54:00.12ID:mn0czGQ5 >>823
うーむ、Next.jsのgetServerSidePropsに惹かれて試してみたけど、こっちはVueと比べてCSSの考える事は多い感じかな
適当に書くけど、.main > * {color:red}とかやって、子コンポーネントに突き抜けたりしないだろうか・・・。
うーむ、Next.jsのgetServerSidePropsに惹かれて試してみたけど、こっちはVueと比べてCSSの考える事は多い感じかな
適当に書くけど、.main > * {color:red}とかやって、子コンポーネントに突き抜けたりしないだろうか・・・。
826デフォルトの名無しさん
2020/12/30(水) 14:36:06.25ID:97VH6JZh >>820
他人に過疎を味あわせたいというのは異常だし
おまえがこのスレに来なくて過疎を味わい他人がこのスレで雑談して楽しむのはwin-win
スレのテーマを話したい人がいるときに雑談で邪魔しないというマナーはある
他人に過疎を味あわせたいというのは異常だし
おまえがこのスレに来なくて過疎を味わい他人がこのスレで雑談して楽しむのはwin-win
スレのテーマを話したい人がいるときに雑談で邪魔しないというマナーはある
827デフォルトの名無しさん
2020/12/30(水) 17:44:12.92ID:zA1s3IaL >>822
Reactだと、上記と同じことをするのはstyled-componentsかな。
エディタの補完が追いつくのかは気になるけど
https://qiita.com/taneba/items/4547830b461d11a69a20
Reactだと、上記と同じことをするのはstyled-componentsかな。
エディタの補完が追いつくのかは気になるけど
https://qiita.com/taneba/items/4547830b461d11a69a20
828デフォルトの名無しさん
2020/12/30(水) 18:55:12.14ID:olxuh5fb829デフォルトの名無しさん
2020/12/30(水) 20:27:31.52ID:/bDJ6XEP 「過疎スレだから」がスレ違い宣伝荒らしの言い訳ならprologスレとforthスレを盛り上げてこい。これは命令だ。
830デフォルトの名無しさん
2020/12/31(木) 00:25:02.74ID:QWe6530o Next.jsってアップデートされたけどVercel使わないとまともに使えん的になってきてそこそこの規模でも有料だし
少し大きくなったら年間数万ドルもかかるとかやばくねえっすか?
少し大きくなったら年間数万ドルもかかるとかやばくねえっすか?
831デフォルトの名無しさん
2020/12/31(木) 00:48:49.82ID:ZOSFby6D ちょっと調べたけどnextって今そんなことになってたんだ。面白ー。
まぁまだゆとり向けフレームワークのnuxtちゃんがいますし...
まぁまだゆとり向けフレームワークのnuxtちゃんがいますし...
832デフォルトの名無しさん
2020/12/31(木) 07:16:28.08ID:kXsKi0cH 画像最適化やISR等の一部機能がVercel依存なだけじゃないの?
Vercelも自分とこのプラットフォームを使ってほしいだろうけど、客寄せになるNext.jsの人気は必要だから無茶はできないし
Vercelも自分とこのプラットフォームを使ってほしいだろうけど、客寄せになるNext.jsの人気は必要だから無茶はできないし
833デフォルトの名無しさん
2020/12/31(木) 17:56:20.15ID:v+HdWO16 ReactのNext.jsのgetServerSideProps() に相当する機能ってVueのNuxt.js には無い?
DBアクセスとか、必ずサーバー側で実行して欲しい処理を書きたい
DBアクセスとか、必ずサーバー側で実行して欲しい処理を書きたい
834デフォルトの名無しさん
2020/12/31(木) 20:12:22.49ID:n8r8zFZ6 ある
が基本的すぎてドキュメント読んでないのがバレるぞ
が基本的すぎてドキュメント読んでないのがバレるぞ
835デフォルトの名無しさん
2020/12/31(木) 23:11:57.32ID:v+HdWO16 asyncDataやfetchだとrouter-link、nuxt-linkでページ遷移するとクライアント側で実行されちゃう認識だけど
それ以外にも必ずサーバサイドで実行される(ロジックの中でfs.readFileSyncが使える)方法あるの?
それ以外にも必ずサーバサイドで実行される(ロジックの中でfs.readFileSyncが使える)方法あるの?
836デフォルトの名無しさん
2021/01/01(金) 01:01:38.63ID:I6jeM+Zp getServerSidePropsの意味するところを俺が誤認してたみたい失礼。
asyncDataをサーバ側に限定する方法はない
ServerMiddlewareを使えばサーバ側で動くAPIを作れるから、それをクライアント側から呼ぶ形が一般的
asyncDataをサーバ側に限定する方法はない
ServerMiddlewareを使えばサーバ側で動くAPIを作れるから、それをクライアント側から呼ぶ形が一般的
837デフォルトの名無しさん
2021/01/01(金) 01:11:21.91ID:/+4IUuLb やっぱりページごとにAPI作るのがNuxtの流儀か
管理サイト的なものを作っていて、9割のページがDBのデータを表示してるから
1ページごとにAPIを個別に作るのはしんどいんだよね
それか、router-link禁止で全部<a>タグでのみページ遷移するルールにするかって感じか
管理サイト的なものを作っていて、9割のページがDBのデータを表示してるから
1ページごとにAPIを個別に作るのはしんどいんだよね
それか、router-link禁止で全部<a>タグでのみページ遷移するルールにするかって感じか
838デフォルトの名無しさん
2021/01/01(金) 10:22:39.74ID:JSeY8OLT839デフォルトの名無しさん
2021/01/01(金) 11:09:03.93ID:LgwM8ucz840デフォルトの名無しさん
2021/01/01(金) 12:13:22.88ID:JSeY8OLT841デフォルトの名無しさん
2021/01/01(金) 13:10:38.63ID:LgwM8ucz842デフォルトの名無しさん
2021/01/01(金) 13:44:12.20ID:JSeY8OLT >>841
あとビルドするときにscssをcssとして出力(package.jsonに記載)したほうがChromeのDeveloperで開発しやすいんでないかな
俺はそうした
jsにスタイル書くのって俺的には無理だったしscssの変数とかmixinどうすんのって感じだったから使ってない
あとビルドするときにscssをcssとして出力(package.jsonに記載)したほうがChromeのDeveloperで開発しやすいんでないかな
俺はそうした
jsにスタイル書くのって俺的には無理だったしscssの変数とかmixinどうすんのって感じだったから使ってない
843デフォルトの名無しさん
2021/01/01(金) 20:12:23.69ID:/+4IUuLb せっかくコンポーネントごとに分けてるのにグローバルな巨大cssを作るのもちょっとなぁ
scssだと入れ子が出来るだろうから素のcssよりゃマシだろうけど
scssだと入れ子が出来るだろうから素のcssよりゃマシだろうけど
844デフォルトの名無しさん
2021/01/01(金) 22:01:26.56ID:7dc3kU9y >>842
package.jsonに記載って何を記載するんですか?
package.jsonに記載って何を記載するんですか?
845デフォルトの名無しさん
2021/01/01(金) 22:03:44.11ID:gR0w6/3v いいからガタガタ抜かさずemotion使ってみろってw
846デフォルトの名無しさん
2021/01/01(金) 22:05:08.76ID:gOgGeOog emotion は絶対にない。
linaria は許容できるけど
linaria は許容できるけど
847デフォルトの名無しさん
2021/01/01(金) 22:30:42.44ID:8TPOGttB SPAで特定のページにnoindex付けたいんですがどうやるのが正解ですか?
今考えてるのは特定のページに入ったらjqueryでheadにnoindexをぶち込む方法です
今考えてるのは特定のページに入ったらjqueryでheadにnoindexをぶち込む方法です
848デフォルトの名無しさん
2021/01/01(金) 22:34:56.11ID:JSeY8OLT849デフォルトの名無しさん
2021/01/01(金) 22:40:09.79ID:HdS3p/N5 css in js だと goober が軽くてええな
850デフォルトの名無しさん
2021/01/01(金) 22:43:08.73ID:gOgGeOog styled component と emotion は全く同じ位置付けなんだけど。
styled componentが無理矢理でemotionが無理矢理じゃないのが理解できない。
dev toolpの問題は結構前に解消されてるでしょ。
css in js を使用する人は何を実現したくて使用するのか聞きたい
styled componentが無理矢理でemotionが無理矢理じゃないのが理解できない。
dev toolpの問題は結構前に解消されてるでしょ。
css in js を使用する人は何を実現したくて使用するのか聞きたい
851デフォルトの名無しさん
2021/01/01(金) 23:02:42.71ID:gR0w6/3v emotionはstyled component形式でも書けるけどメインはcss prop形式だよ。
css prop形式使わないならstyled component使えばいい。
わざわざemotion使うからにはcss prop形式使うでしょ。
styled component形式は移行のためのサポートと思っとけばいい。
css prop形式使わないならstyled component使えばいい。
わざわざemotion使うからにはcss prop形式使うでしょ。
styled component形式は移行のためのサポートと思っとけばいい。
852デフォルトの名無しさん
2021/01/01(金) 23:05:06.53ID:gOgGeOog853デフォルトの名無しさん
2021/01/01(金) 23:10:00.98ID:gOgGeOog ちゃんと読まないでレスしてた
css prop形式だと余計に css in js 使う意味ないでしょ。
それだと classNameをconditionで操作してるのと変わらないでしょ
css prop形式だと余計に css in js 使う意味ないでしょ。
それだと classNameをconditionで操作してるのと変わらないでしょ
854デフォルトの名無しさん
2021/01/01(金) 23:19:20.92ID:gR0w6/3v あのねえ、styled componentより後発でたったそれだけのことで人気追い抜くわけないでしょ…
知らないならドキュメント読んで使ってみなさいよ
知らないならドキュメント読んで使ってみなさいよ
855デフォルトの名無しさん
2021/01/02(土) 00:13:03.58ID:gKf/Fv60 時代はtailwindCSS
856デフォルトの名無しさん
2021/01/02(土) 15:35:58.93ID:RXFdEIXY tailwindかtacyonsどっちか迷ってる俺に推しの一言をどうぞ
857デフォルトの名無しさん
2021/01/02(土) 17:42:37.50ID:wubIjlLH https://i.imgur.com/vOB4XJi.jpg
もはや比較の必要あるか?というレベルで大差付けてるけども
最近の人気で言うとTailwindCSSかChakra UIかという感じやな、chakraはreact専用だけども。
もはや比較の必要あるか?というレベルで大差付けてるけども
最近の人気で言うとTailwindCSSかChakra UIかという感じやな、chakraはreact専用だけども。
858デフォルトの名無しさん
2021/01/02(土) 20:18:33.44ID:7UePDUod tailwindとchakra uiはスコープだいぶ違うと思うが。
前者はCSSフレームワーク、後者はreact用uiツールキットでしょ
前者はCSSフレームワーク、後者はreact用uiツールキットでしょ
859デフォルトの名無しさん
2021/01/02(土) 22:31:31.83ID:wubIjlLH >>858
立ち位置は完全には同じでないけど、被ってる部分は結構あってサイト内にも比較ページがあるくらい意識されてるよ。
https://chakra-ui.com/docs/comparison
背景も使い所も全く別物なら公式がわざわざ用意しないからね
立ち位置は完全には同じでないけど、被ってる部分は結構あってサイト内にも比較ページがあるくらい意識されてるよ。
https://chakra-ui.com/docs/comparison
背景も使い所も全く別物なら公式がわざわざ用意しないからね
860デフォルトの名無しさん
2021/01/03(日) 00:49:54.47ID:U3X4E4MI うんそれoverview読むだけでまったく別物だって分かるね
■ このスレッドは過去ログ倉庫に格納されています
