素のJavascript(Vanilla)だけでフロントエンド開発はできるか?

このページでは、ReactやVueではなく、Vanillaと呼ばれる素のJavascriptのみで、フロントエンド開発が可能であるか?を解説します。

今回はフロントエンド開発についてです。

私はWebデザインから、徐々にステップアップし、Javascriptを習得した者です。
次は、フロントエンド開発を覚えたいと思っていますが、ReactやVueといったフロントエンドフレームワークはやや敷居が高いと感じます。
Node.jsを利用せずに、Javascriptだけでフロントエンドは開発は、現状できないのでしょうか?
これらは結果的にHTMLとJavascriptにトランスパイルされるので、結果的にできると思うのですが…?

手間や制限はありますが、Javascript(=Vanilla Javascript)だけでフロントエンドシステムは構築できます。
ただし、それなりの手間はかかりますよ!

実用レベルに達しているかは、各自で判断してください。

「Vanilla JS」で検索すると、同名の軽量フレームワークのサイトが現れますが、それではなく、そういったフレームワークすら使用しない、素のJavascriptを、Vanillaと呼んでいます。
(とても紛らわしいですが…)

目次

素のJavascript(Vanilla)だけでもフロントエンドとして動かせる

気になるであろう「手間や制限」は次章以降で解説しますが、先に定義および前提条件を解説します。

説明している段階で、自分のスキルでは、わざわざフロントエンド開発する必要性がなくなるかもしれません。
(PHPやRuby on Railsなどで開発できるのなら、そちらの方が楽ですしね。)

至極当たり前のことも書いておきます。

これらが理解できれば、素のJavascript(Vanilla)でフロントエンドが開発できます

静的な「.html」拡張子のファイルを使用

可能な限り静的な「.html」拡張子のファイルにて構築します。
このことにより、SPAではないことがわかります。
さらにサーバー上では動的に作成しませんので、SSRでもありません。

SPAではないCSRと表現できそうです。

APIへの接続はasync/await型のfetch()を利用

フロントエンドフレームワークを使用する利点は、例えばアトミックデザインを始めとした開発の効率化だと思いますが、もう一つはAJAX処理の簡素化だと思います。

その手法については、以前でしたら、やれJQueryが必要だの、axiosが必要だのと言われていましたが、今はfetch()で、APIに簡単にアクセスできます。

取得したデータを後続処理に繋げたいのならば、async/await型でしょうか。

GET/POSTも可能ですし、BODYにJSONを入れてAPIを呼び出すことも出来ますし、フォームデータも可能です。
添付ファイル付きフォームデータでしたら、勝手に「multipart/form-data」になりますので、至れり尽くせりですね。

逆に考えると、共通化・部品化などがクリアできるかが、素のJavascript(Vanilla)でのフロントエンド開発の鍵になります。

CSSフレームワークは使用してよい

CSSフレームワークはNode.jsは使用しませんし、フロントエンドのフレームワークとの相性も考えなくて良いですので、使用しても構いません。

もし、あるとしたら、JQueryの使用の可否でしょうか。
フロントエンドのフレームワークは使用しないため、相性の問題もありませんので、使用したければ使用すれば良いだけだと思います。

Webサーバーは必要

当然ではありますが、Webサーバーは必要です。

理由は簡単で、Webサーバーが無いとCookieが動作しません。また、他の環境からの実行確認ができないからです。

簡易的なもので十分だと思います。

Macをお使いの場合は、すでにWebサーバー(Apache)がインストールされているので、設定ファイルを変更し、再起動することにより、ローカルユーザーで使用することができます。

Webサーバーがあれば、とりあえず当座のAPI(JSON)モックは作成可能

気の利いたWebサーバーならば、hoge.jsonといった拡張子のファイルであれば、WebサーバーはContent-Typeapplication/jsonにしてくれるはずです。

なので、当座の紙芝居はこれで出来るはずです。

実際の開発では、.json拡張子ではなく、バックエンドのフレームワークに依存しますので、そこで手直しは発生します。

パラメータオプション等の、APIの仕様は別途作成すると思いますが、データとして何が欲しいのアピールはできると思います。

node.jsがすでにインストールされている場合は、そちらでもAPIモックサーバーの立ち上げは可能だと思います。
(独自のパラメータが用意されているようですが、それと実際のシステムのAPI仕様は異なる気はします。)

参考:フロントエンドとバックエンドの関係について

ここまでで、簡易的な開発はできるかなと思いますが、システムの本格的な開発を行うための、前提条件である、フロントエンドとバックエンドの関係性について、もう少し深堀りしていきます。

フロントエンドフレームワークではSQLを発行できない

バックエンドのフレームワークって?…例えばRubyならばRuby on RailsやSinatraなどです。

APIって何?という方は、この記事は呼んでいないと思いますが、一般的にフロントエンドフレームワークではSQLを直接発行できません

もし仮に可能になったとしても、裸のSQLがHTMLに埋め込まれたら嫌ですよね?

本格的な開発にはバックエンドのフレームワークが必須

ですので、バックエンドシステムを別途開発して、バックエンド側とはAPIという手法を用いて接続し、DBアクセスを行ってもらい、結果をJSONで取得して、HTMLに反映します

なんだか、まどろっこしいシステム開発だなあ…とは思いますが、システムも理解できて、データ管理も得意で、さらにWebデザインも簡単にできますよ…という技術者は、まず周りにいないでしょうから、こういった役割分担が大切になるのかな…と思います。

ただ、可能性としては、Webデザインもできて、Javascriptによる動きもある程度付けられる…といった方はいらっしゃると思います。

今のフロントエンドエンジニアは、バックエンドの知識がぶっちゃけ不要でもなんとかなるので、スタート時にはWebデザイナー領域だった人でもフロントエンド技術さえ習得すれば、「フロントエンドに限り」ですが、Webシステム開発に参画できるという利点…というかチャンスはあります

つまり…

  • デザインを壊さず、制御用のclassやidやJavascriptコードを埋め込む
  • フォームから入力した値をAPIに投げ、結果を受け取る
  • 戻ってきたJSONから、名称や計算値を再表示したり、画面の一部を表示したり閉じたり、画面遷移したり…
  • どのようなデータがバックグラウンドにあるのか?そのデータが一体どうなるのか?まで、理解する必要はない

といったことが、フロントエンドエンジニアの主な役割だと思います。

そんなのRuby on RailsやPHPで一緒に出来るじゃん…という人は、わざわざ、このようなまどろっこしいことはしなくて良いと思います。

今までどおりバックエンドのみで開発し、郵便番号APIをAJAX的に呼び出し、画面遷移無しで表示するといったところのみ、API開発すれば良いと思います。

だた、WebデザイナーさんがSSR開発までを一気に学習するには、学習コストがちょっと高すぎる気もします。
それでもWordpressのプラグインなら作れますよ!という方もいらっしゃるでしょうから、それぞれの世界があるんじゃないかな…とは思います。

フロントエンド開発を別途しなければいけない理由

まとめ…というほどでもありませんが、経験(?)上、フロントエンド開発を別途しなければいけない理由は…

  • デザイン重視や見た目の動き重視で、バックエンド連携はあとで実装したい(デザインが壊れやすい)
  • 政治的な力学(?)で、フロントエンド開発とバックエンド開発を別の会社で行うことになってしまった
  • 流行に乗っておいて、技術ノウハウを溜め込みたい
  • フロントエンドの方が単価が高そう

といったケースでしょうか。

本来は①のみであるべきだと思うのですが…

APIの仕様はどちらが作る?

問題はAPIの仕様はどちらが作成するかだと思います。

  • 欲しい項目の一覧、選択・照会画面の絞り込み等⇒フロントエンド側
  • URLの仕様⇒バックエンド側(Restfulが実現できないバックエンドフレームワークもある)
  • DBとしてセットして欲しい値⇒バックエンド側

双方が要求を投げあって、まとめていけば良いと思いますが、フロントエンド側でツールがあるのであれば、まとめるのはフロントエンド側となりそうですね。

仕様につてはこちらも参照してみてください。

参考:フロントエンド・バックエンドがバズワード化したパターン

この項は、狭義のフロントエンドとはかけ離れたケースですので、理解できなくても、読み飛ばして結構です。

参考までに、フロントエンド・バックエンドがバズワード化したパターンもあります。

割りと多いケースとしては、PHPのECパッケージのカスタマイズ等で、基幹(物流)システムにデータ連携したい場合に、(パッケージのDBとバッティングしないように)APIを活用するといったケースでしょうか。

この場合、Web側をフロントエンド、基幹システム側をバックエンドと呼んでしまうと思いますが、狭義の意味のフロントエンド・バックエンドとは異なりますよね。

ちなみに、基幹側が欲しい情報を渡す必要がありますので、APIはバックエンド側が作成します。
この場合は、ECシステム側としては、あくまでも外部データ連携という位置づけになります。

いわゆるAPIサービスと同じ位置づけです。

また、連携した情報が、どのくらい進捗しているか?(具体的には荷物がどのあたりにあるか?など)、といったAPIもありえますね。
この場合は基幹システムだけではなく、運送会社とのデータ連携なども考慮する必要がありそうです。

Vanillaでのフロントエンド構築を阻む、手間や制限について

狭義のフロントエンドシステムを振り返る

閑話休題。
狭義のフロントエンドシステムを振り返ります。

  • フロントエンド側ではSQLを発行できない
  • レスポンスデータの中に(SSR的な)動的データは存在しない(枠だけが存在)
  • 動的データの入出力はすべてAPIで行い、セットはJavascript(fetch)で行う
  • エラーチェックはAPIに任せる
  • ログイン情報はCookieあるいはLocalstrageで管理(トークンを持つ)

これらについては、node.jsとかを一切利用せずに、素のJavascript(Vanilla)のみで、狭義の意味のフロントエンド開発は出来ます。

Vanillaでのフロントエンド構築を阻む、手間や制限

ただし、以下の手間あるいは制限があります。

こちらは、主にJavascriptの動作などとは関係のない部分になります。
すべて、拡張子「.html」ファイルは静的に作成されることに由来するものです。

  • ヘッダー・メニューやフッターはfetch()で取得して表示
  • Javascriptのインクルードはできない
  • HEADタグ内はfetch()できない
  • ブラウザのキャッシュを無効化できない
  • キャッシュバスター(キャッシュバスティング)ができない

解決方法は?

  • 高機能なフロントエンドフレームワークを利用(ReactやVue.jsなど)
  • Webサーバーの機能があれば、それを利用する(SSI)
  • APIで利用するバックエンドシステムを利用してSSR表示する

ただ、今回の記事の目的(目標?)はVanillaのみで…なので、残念ながらReactやVue.jsなどの選択肢はありません。
(その選択肢がすでにあるのであれば、この記事にはたどり着かないかな…と思います。)

ですので、SSIあるいはバックエンドフレームワークを加味した上での開発となるでしょうね。

こちらの詳細は、下記の記事に移動しました。

最終的に何を選択するか?

分かれ目となるポイントは?

分かれ目となるポイントは…

  • DBの作成もサーバーサイドフレームワークで行っているか
  • Webデザイナーが絡んでいるか?

だと思います。

DBの作成もサーバーサイドフレームワークで行っているのならば、スキャフォールド(scaffold)でマスターメンテナンス的なものは簡単に作成できると思いますので、いわゆる(表に出ない)「管理画面」はサーバーサイドフレームワークで完結させ、デザイナーの絡んでいる「個性的な画面」のみHTML+Javascript+APIで行う…といった棲み分けを考えるのもひとつの手です。

規模感や、自分や周辺のスキルで決めても良い

小規模でまずトライしてみたい!のならば、これ以降の記事を読んでいって、Vanillaなシステムを作ってみると良いと思います。
可能であればSSIを使用してもいいでしょう。

もし、それで不満だった場合は、「個性的な画面」をReactかVueあたりで作成しても良いかなと思います。

以降の記事は「管理画面」的な画面をHTML+Javascript+APIで作成していきますが、もし貴方がサーバーサイドフレームワークを使いこなせていたのなら、「管理画面」は、はじめからサーバーサイドフレームワークで完結させたほうが楽でしょうね。
「個性的な画面」も、慣れていればサーバーサイドフレームワークでトライしても良いでしょうね。
(デザイナーとの連携が鍵ですが。)

SSRフレームワークによっては、AJAX部分を簡略化した機能を用意しているはずですしね。

といった具合に、自分の立ち位置や、スタッフの力量などで考えても良いと思います。

最後に

SSIのデメリットを紹介するサイトでは、「SSIはWebサーバーに負荷がかかるのでCSR(あるいはSSR)が良い」という意見もよく見かけますが、CSRはブラウザに負荷をかけますし、SSRはアプリケーションサーバーに負荷をかけます

結局、どこかに負荷はかかるわけです。

CSRは動作が重く、初期表示にタイムラグが発生しやすいです。

実は、トレンドに左右され、その都度、なんらかの手法に偏るだけなのでは?とも思っています。

ただし、デザイン重視の傾向から、フロントエンドエンジニアというお仕事は、当面は安泰かもしれません。

将来はわかりませんが。

それでは、また。

続編を書きました。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

CAPTCHA

目次