Nuxt.jsのメリット・デメリット

Nuxt.jsとは？

こんにちは、ソラノデザインの角田です。

この記事はプログラマー寄りの記事になりますので、プログラミングにご興味のある方向けの内容になります。

今回記事で取り扱うのは、最近流行のVue.jsを用いたフレームワーク、Nuxt.jsについてです。

Angular、React、Vueと、３大JSフレームワークを用いたフロントエンドが、徐々に主流になってきていますよね。

ソラノデザインではAngularの旧バージョン、Vue.jsを主に開発に用いた経験があり、React経験は少しです。

しかし一通り触ってみた経験はありますので、それぞれの比較を踏まえて、記事をかけるのではないかと思い今回筆をとった次第です。

Angularは巷で言われている通り、学習コストが高く、またバージョンアップも激しく使いづらさを感じています。

何より挙動が重たいところがAngularの弱点な気がします。

元々挙動が重たいバックエンドのフレームワークとAngularとは合わせたくないというのが、個人的な所感です。

モダンフロントエンドを用いた開発が主流になった頃、3大JSフレームワークの中でも「Google印」のAngularを最初に勉強したのですが、少なくとも金沢の私の周りのエンジニアの間では、Vue・Reactが主流と言えます。

東京などの大都会だと、リソースも多種多様なので、またニーズは変わってくるんでしょうか？

Quitaなどをみている限り、大規模開発意外にAngularを採択している印象はありませんが、東京の現場の声を一度実際に聞いてみたいですね。

ちなみに私は、プログラミングの先輩からVueを細かく教えてもらった事もあり、最近はVueを使う事が多いです。

Vue.jsのメリットは？

Reactと違い双方向のバインディングが容易にできる、冗長にならない、コンポーネント化が楽、などが個人的に感じるVue.jsのメリットです。

また、ReactはJSXでhtmlライクな記述をするのに対し、Vueはhtmlタグをそのまま使えます。

「100%の開発屋さん」にはReactは堅いフレームワークですし需要がありそうですが、

ホームページ制作6割：開発4割などで仕事をしている私にとっては、Vue.jsのほうがメリットや使いやすさを感じますね。

Nuxt.jsとは？

Nuxt.jsはVue.jsのフレームワークです。

先んじてリリースされたReactのフレームワークの名前が、「Next.js」。

後発でリリースされたVueのフレームワークの名前が、「Nuxt.js」。

わざと名前を寄せたという噂なだけあって、そっくりな名称です。

Nuxt.jsには、SSR（サーバーサイドレンダリング）を簡単に実装できる機能が最初からついています。

Nuxt.jsは、SPA・SSR・静的化の中から選択してビルドできるフレームワークです。

SPAモードは楽なのですが、クライアント側でHTMLを生成しレンダリングしているので、SEOや表示速度に懸念があります。

開発内容によっては、クライアント側に持たせておきたくない値やメソッドがあるかもしれません。

サーバー側でjavascriptをレタリングしHTMLを生成するSSRではそういった問題を解決してくれるので、よりよりアプリ・サイトを構築するためにもSSRはおすすめです。

Nuxt.jsを使ってUIコンポーネントを独立

Nuxt.jsはコンポーネント化のしやすさから、保守管理も簡単になります。

学習コストをかけずコンポーネント化するために一時EJSが流行りましたが、ライブラリの豊富さやES2019への対応の速さ、開発のしやすさなどからやはり３大フレームワークは強いです。

これからフロントエンドのJSを学ぶ方は是非Nuxt.js(Vue.js)、Reactなどから学習してみてください。

最近のフロントエンドはやたらと「クラス名…」「キャメルケースが…」「命名規則が…」などと揉める事が多いです。

しかし命名規則に多く採用されているBEMは、自動でファイル間のクラス名を変換してくれるNuxt・Vueでは（要件によりますが、殆どのケースで）必要ありません。

そもそもにBEMを採用する理由は「G.R.E.A.T」の概念に基づくものなので、

命名規則がどうであれ、自動でその点をカバーしてくれるNuxt・Vueでは開発者側で「G.R.E.A.T」を気にする必要性が薄いんです。

命名規則ついては色々な意見があるかとは思いますが、個人的にはNuxtでのCSS命名規則はキャメルケースのみで十分だと思います。

普段から「BEM」が必要な理由を踏まえてコーディングを行っていれば、「BEM」が必要ない理由も自ずと見えてくるはず…という考え方です。

私も先輩から教わった事なのですが、「これが存在する理由」「意図」などをできる限り深く考えると早いスピードで成長できます。

命名規則であっても、フレームワークであっても、安直な採択は自身の技術レベルを下げてしまいますので気をつけましょう。

Nuxt.jsのデメリット

個人的に感じるNuxt.jsのデメリットは、やはり「フロントエンド寄り過ぎる事」や、「独特の記述が多い」事でしょうか。

プログラマーをやっていると本当に色々な言語に触れるかと思います。

たとえば数ヶ月ずっとJSで開発していて、久しぶりにphpを触った時に、array_pushを間違えてpushと書いてしまう….などはプログラマーあるあるかと思います。

独自の記述が多い分、ついつい次回案件でもNuxtに頼ってしまいがちになります。

しかし客観的な目で、多少の苦労があっても「Reactのほうが良い」といった開発であれば、Reactを採択するプロ意識は必要になりそうです。これがなかなか難しいんですが…..私も自分に念押しするためにもこの記事を書いています。笑

また、これはしょうがないことなのですが、「フロントエンド寄りすぎる」ことは多少の弱点な気がします。

前述の通り、NuxtはSSR対応で様々な事が実現できるので、FirebaseなどのJsonでデータを扱えるmBaaSを使えばバックエンドなしで開発を行う事ができます。

反面これは、「バックエンドで書いていた事をフロントエンドで書ける」ということです。

メリットのように感じますが、個人的にはデメリットに感じてしまっています。

というのもメソッドが飽和したり、保守管理がしにくかったり、開発期間が長くなれば長くなるほどそういった点が煩わしく感じてしまいます。

短期間で高速開発を行う際はメリットになりますが、やはり基本的には「バックエンドAPIをLaravelなどのFWで開発」し、「フロントをNuxtで開発し別サーバーに立てる」という最近流行りの手法がベストプラクティスと言えると思います。