ここ最近は Vue の記事を見かけることが増えたと思います

それまでのこの 1, 2 年くらいはほとんど Vue の話題を見かけなかった気がします
ほとんど React 関係のものばかりでした
React ばかりになりつつあるなと思いながらも 1 年ちょっとくらい前に Vue3 が出て Vue に少し期待してました
しかしリリース直後は話題になってもそれ以降は全然でした
IE のサポートを切ったことや大きな変更があって 3 がリリースされてもデフォルトは 2 のままでしたし リポジトリも next みたいなのに分かれてました
周辺ライブラリの対応待ちなどもあって すぐにちゃんとしたところで使っていけなかったというのもあったと思います

そこまで回答者が多いものではないですが State OF JS のアンケート結果だと React が 8 割に対して Vue は 5 割という利用率でした
Vue よりはるか昔に目にすることが無くなりまだ生きてるのって思ってた Angular 以下なのは驚きでした
一応 Angular が下がり Vue が上がってるようでしたが それでも React が遥かに強くて より新しいフレームワークも出てきてますし React に追いつくのは無理なのかなという感じでした

そんなだったのですが ここ最近は何かあったのかなと思うくらいに Vue の記事を見かける割合が増えています
調べてみるとやっとデフォルトが 3 になったようです
https://blog.vuejs.org/posts/vue-3-as-the-new-default.html

ドキュメントも 3 が出た頃に比べると色々新しくなってました
たしか以前見たときは書き換え中とか 2 のままで更新予定とかが残っていて 3 がデフォルトになった頃に見ようと後回しにしてた気がします
軽く見ていると新機能の Composition API というのがあって 個人的に嫌だった部分が改善されてました
一般的な Composition API のメリットではなく すごく個人的なところです

命名規則

いったん Vue は置いておいて 変数や関数などの命名規則についてです
言語ごとに推奨が違ったりして .NET なら FooBar() 形式で Python なら foo_bar() で JavaScript fooBar() みたいなのです
それに合わせたりもしますが 短期間に複数の言語を切り替えながら書いてるとどれがどれだったかわからなくなってきますし そのルールに従わないと動かない系の言語でもなければ全部を自分ルールで書いてたりします
そこまで特殊なルールでもなく たまに同じように書いてるコードを見かけたりもしますが なにかの言語にとってのデフォルトってわけでもないはずのでマイナーではあると思います

class FooBar {}
const fooBar = () => {}
const foo_bar = 1

という感じでクラスやコンストラクタ関数は一般的な FooBar 形式です
その他の通常の関数は fooBar() で関数以外の変数は foo_bar です
JavaScript だと関数も変数に入ってるオブジェクトでしかないのですが 関数は他の値と違って特別なものですし こうなってるほうがぱっと見でわかりやすいので好みです
引数や返り値に関数名と同じ名前を使いたいことがときどきあって そのときに命名規則が違うことでそのまま使えたりします

const foo_bar = 1
fooBar(foo_bar)

const foo_bar = fooBar()

この規則と相性が悪い部分

基本はこれで困ってないのですが 唯一と言ってもいいくらいに困るところが getter/setter です

const obj = {
	value: 0,
	get fooBar() {
		return this.value
	},
	set fooBar(value) {
		this.value = value
	}
}

関数なので fooBar 形式にしましたが使うところでは別です

obj.fooBar = 100
console.log(obj.fooBar)
// 100

関数ぽいものに数値が入ってることになって とても気持ち悪いです
かと言って

const obj = {
	value: 0,
	get foo_bar() {
		return this.value
	},
	set foo_bar(value) {
		this.value = value
	}
}

とするのも 関数定義部分に _ があって嫌です
get/set というキーワードがあるから別物とは言えますが こういう規則にそってないものが混ざってるコードを見るとすごく浮いて見えてどうにかしたくなります

幸い 普段は getter/setter って無くても困りません
関数呼び出し形式にしても () が増える程度です
関数にしておけば後から拡張したいときに引数を増やすだけで済んで変更が少なく済みますし 特別な理由がなければ getter/setter ではなく関数呼び出しにしてます

Vue の場合

そういうわけで getter/setter は使うこと無いし 命名規則的にも統一されてるって状態でした
しかし Vue では computed properties というものがあります

computed: {
	foo_bar() {
		return this.foo + this.bar
	},
},

この foo_bar という名前はそのままテンプレート中で

<span>{{ foo_bar }}</span>

というふうに使います
setter がない場合は省略して get キーワードなしのメソッドとして書くので 命名規則的には JavaScript の通常の getter 以上に気持ち悪さがあります

Composition API のおかげで

そういう不満があったわけですが Composition API だと React の hook に近い書き方になります

const foo_bar = computed(() => {
	return state.foo + state.bar
})

getter 関数は computed の引数として渡して foo_bar は computed() 関数の返り値です
関数ではない何かのオブジェクトなので foo_bar という名前を違和感なく使えます

そういう感じでだれからも共感はされなそうですが 個人的な嫌だった部分が解決されたという話です

その他

他には Composition API だと オブジェクト風な書き方をしないので this というキーワードを見なくて済むのもいいところです
ただこの仕組み簡単のようで複雑でドキュメントを見ても Composition API の方が分量が多いです
https://vuejs.org/guide/essentials/reactivity-fundamentals.html

reactive だけならまだわかりやすかったのですが ref が出てきて unwrap みたいなものもあって しかもやってくれるところとやってくれないところあったりです
完全にやってくれて .value を意識しなくていいならまだしも中途半端だと混乱のもとですし いっそ特別なことしないほうがよかったのではと思ってます
リスナのインライン記法で @click="method" と @click="method()" みたいのがあったりと Vue は変に便利にしようとして難解になってるところが多く感じます
多少不便でも明示的に書いて迷うことがないような方がいいんですけどね