jQueryもbackboneもAngularもいらない。javascriptフレームワークといえばVanilla JSに限る

jQueryもbackboneもAngularもいらない。javascriptフレームワークといえばVanilla JSに限る

世の中には便利なライブラリやフレームワークがあり、その数はどんどん増えていって、あれがいいよとかこれがいいよなんていう情報が矢継ぎ早にささやかれるわけですが、そんなにあれこれ使っていったいどうするんだい?というのが私の心境です。

私自身はエンジニアではないので、なかなかサイトを構築する時に裏側の環境までは手を出せません。
Angular使うよーとか、Laravel使うよーとかいうのはエンジニアさんたちが決めています。
とりあえず動くものをただただ手っ取り早く作るプロジェクトならばそれでいいんですが、そうじゃない事情もある、ということでチームの人たちにも少し知っておいてほしい。

jQuery,backbone.js,AngularJS,Bootstrap,Sass,Lessといったライブラリ・フレームワーク等を導入するデメリット

Webサイトでは多くの場合、SEO施策が必要だったり、専属のデザイナーさんが練ったデザインを再現したりする必要があるので、きっちりマークアップして成形していきたいんですよね。
ところが、使いたいライブラリとかフレームワークの都合で、やっぱりここにdiv追加して~とかolが2個に分かれてもいい?なんていうことがしょっちゅうで工数がかかると、なんのためにフレームワーク使ってるんだよと。

しかも使いもしないコンポーネントまるごと読み込んで結局リクエスト数が増えたりレンダリングがブロックされたりトータルの読み込みサイズ自体も増えてなんなんですか?いったいなんなんですか?
スマホ対応のために必死にスプライト作ったりソース減らしたりしてリクエスト減らしたり読み込み減らしたりレンダリングのパフォーマンスまで考えて頑張ってるのに全部無駄だよ!!
ヽ(`Д´)ノウワァァァン!!

この話をWebデザイナーさん向けにCSSに置き換えて考えるのなら、たとえばSassのようなプリプロセッサのようなものを導入して、共通ルールを決めて、一見軽くて早くなったように見えるけどコンパイルしてみると実態は不要なソースだらけで、そんなごちゃごちゃと肥大化したセレクタたちを眺めてはscss側の修正箇所を血眼になって探す日々が続くわけですね。(´Д`)ハァ…

目的と手段が入れ替わってしまっていませんか?

「いくさは手段であって目的じゃないんだぜ」byきり丸

ライブラリ・フレームワーク等を導入する目的はなんだったか

  • コーディングの手数を減らしたい
  • 属人化しない共通ルールで管理したい
  • 軽量化してパフォーマンスをアップしたい

だとしたら…

Sassを導入するだけのコストがかけられるのなら生のCSSをまともに設計できるようになればいいし、みんなが知らないフレームワークを勉強するコストがかけられるのなら生のJavascriptをみんなが書けるようになればいいじゃないですか。
それがもっともシンプルで単一で正確に伝わる共通言語ではないですか?
関西弁やら博多弁やら南部弁やらそれぞれ魅力はありますが、効率化を図るのであればすべての人が標準語を身につける、それでいいではないですか?
だからみんな英語を勉強するんじゃないですか。

  • コーディングの手数を減らしたい ←Emmetで十分効果出たんじゃね?
  • 属人化しない共通ルールで管理したい ←ツールの問題じゃなくね?
  • 軽量化してパフォーマンスをアップしたい ←あれ?遅くね?

ちょっと興奮して見えない敵に向かって喧嘩腰になってしまいましたが、そんな私が唯一おすすめするフレームワークをいまさらご紹介します。

超高速・超軽量・ハイパフォーマンスで無料の信じられないjavascriptフレームワーク

タイトルでとっくにバラしているVanilla JS。
話題になってからだいぶ経つので、この記事を見に来るような人はとっくに知っているかと思います。恐縮です。
ありとあらゆる記事があるので、ぜひ参考にして、そして導入してみてください。
有用な記事を書いてくださっている神たちに敬意を表して外部リンクつけておきますね(*´∀`*)