プログラミング

JavaScriptで挫折！「JavaScriptが大嫌い」と感じた理由

7:03

JavaScriptなんてもう嫌だ！そう叫びたくなるくらい、かつて私はJavaScriptの学習で心が折れかけました。毎日のようにエラーや警告に悩まされ、つい「JavaScriptが大嫌い！」と口にしてしまうほど追い詰められていたのです。

本記事では、なぜ私がそこまでJavaScriptを嫌いになってしまったのか、その理由を自分の体験談をもとに振り返ってみたいと思います。入社直後に味わったIEとNetscapeのブラウザ戦争による苦労、TypeScriptの厳しすぎる型定義に挫折しかけた話、ESLintのエラー警告に疲弊したエピソード、JavaScriptの書き方が多様すぎて初心者には混乱の元だったこと、さらにはjQueryのバージョン違いで思わぬハマり方をした件など、当時の苦い経験を正直に綴ります。

最後には、「JavaScriptなんて大嫌い！」だった私がどうやってその壁を乗り越え、今ではどのようにJavaScriptと付き合っているのか、克服までの道のりもお話しします。同じようにJavaScriptで挫折しそうな人の参考になれば幸いです。

IEとNN（嫌いな理由その1）

私が新人エンジニアだったころ、最初に直面したJavaScriptの壁がブラウザ間の非互換でした。入社して1年ほど経った頃、JavaScriptで開発された社内システムの保守を任されたのですが、当時はInternet Explorer（IE）とNetscape Navigator（NN）の2大ブラウザが覇権を争っていた時代です。

まだJavaScriptの仕様が統一されておらず、ブラウザごとに動作が異なるのが当たり前でした。案の定、「IEでは動くのにNNでは動かない。NNで動くよう修正すると今度はIEで動かなくなる」──そんな不具合が次々と発生しました。両ブラウザの癖を調べては条件分岐で書き分け、動作検証を繰り返す日々に疲弊しました。結局、このブラウザ間の不整合対応に約4か月も振り回され、私はすっかりJavaScriptが嫌いになってしまったのです。

iframeを使った罠（嫌いな理由その2）

まだ駆け出しの頃、ページのヘッダーやフッターを使い回すために<iframe>タグを使う手法が流行っていた時期がありました。iframe内のスクリプトから親ページ（メインページ）を操作する場合は、通常のオブジェクト参照にparent.を付ける必要があります。

ところが、ある案件で「ほとんどのコードにparentが抜けていて正常に動作しない」というひどい状態のプログラムを修正するハメになってしまいました。膨大なJavaScriptコードにひたすらparent.を付け足していく地道な作業です。何とか動くように直しましたが、このときも嫌というほど痛感しました。「もうJavaScriptはこりごりだ…」と。

マスカット（嫌いな理由その3）

それから数年が経ち、私がプログラミングに慣れてきた入社8年目くらいの頃。世間ではちょうどAjaxが流行し始めていました。

そこで携わることになったのが、Ajax用フレームワーク「マスカット」を使った開発案件です。リッチUIを実現できる先進的な技術との触れ込みでしたが、クライアント側（ブラウザ側）の処理が重く、開発手法も独特でかなり苦戦した記憶があります。特に大変だったのは、Ajaxで取得したデータをJavaScriptの変数に格納し、それを使って動的に一覧表を表示する処理でした。共通部品を作る専門のチームがあり、その人たちがJSのユーティリティを用意してくれていたのですが、蓋を開けてみると不具合が多数…。

「変数に格納した値がずれる」「格納したはずの値が取得できない」など、共通部品側のバグでこちらの実装が思うように動かず、かなり振り回されました。このときもストレスが溜まり、「やっぱりJavaScriptは厄介だ…」と嫌いになる一因となってしまいました。

スマホ対応とjQueryの混乱（嫌いな理由その4）

マスカットでの苦労をひと通り経験した後、今度はスマートフォン対応の案件に携わりました。ちょうどAndroid4が出始めた頃で、iPhoneにもAndroidにも対応したサイトを作る必要があり、jQueryやjQuery Mobileを使ってモバイル向けのUIを実装しました。

ところが、やはりというべきか「Androidでは動くのにiPhoneでは反応しない」という現象が各所で発生しました。たとえばスワイプ操作の実装ひとつ取っても、iPhoneだとうまく反応しないのにAndroidだと動く、といった具合です。しかも端末の機種やAndroidのバージョンによって挙動が微妙に異なり、想定通りにいかないことばかり。当時のAndroid端末には標準ブラウザが搭載されていましたが、これがまたクセ者で、デバッグにも苦労しました。

スマホの機種差・ブラウザ差による不具合対応に追われる日々で、私はまたしてもJavaScriptが大嫌いになってしまいました。さらに追い打ちをかけたのが、jQuery自体の混乱です。便利そうだと飛びついたjQueryでしたが、ネット上の情報を鵜呑みにして痛い目を見ることが度々ありました。当時、ネットには玉石混交のサンプルコードが溢れており、古いバージョンのjQuery向けに書かれた記事も少なくありません。何も知らない私は古いブログ記事のコードをコピペしては「…あれ、動かない？」と首をかしげる始末。たとえばイベント処理ひとつ取っても、ある記事では最新の$.on()メソッドを使っているのに、別の古い記事では$.bind()や$.click()を使っていたりします。同じjQueryなのに記事ごとに書き方がバラバラなので違いが分からず、「どうして統一されてないの！？」と混乱しました。

さらにプロジェクトによっては複数のjQueryプラグインや別ライブラリが絡み合っており、バージョンの相性問題で謎のエラーが出ることも…。原因がわからず頭を抱えるしかない状況で、「JavaScript界隈は互換性や整合性がなくカオスだ…」とさえ感じました。こうした経験も重なり、「もうJavaScriptには関わりたくない」という気持ちがますます強くなっていきました。

FCKeditorカスタマイズ地獄（嫌いな理由その5）

それからしばらくして、社内のCMS（Content Management System）の編集機能を刷新することになり、なぜか私が担当に指名されてしまいました。正直、嫌な予感しかしません。ブログ記事などの投稿に当時よく使われていたWYSIWYGエディタ「FCKeditor」を導入し、必要な機能をカスタマイズするというミッションです。当然、FCKeditorのベースとなるソースコードやライブラリを読み解き、さらに独自の機能を追加するための自作JSライブラリも書かなければなりません。

案の定というべきか、ここでもJavaScriptの泥沼にはまりました。例えば、テキストの改行コードを自動で<br>タグに置き換える処理や、センタリング用に<div>タグを差し込む処理など、すべてJavaScriptで実装する必要があります。ライブラリのコードを読んでカスタマイズするわけですが、内部では変数名がaとかbといった一文字で書かれている箇所も多く、何をしているコードなのか理解するだけで一苦労でした。ソースを読むだけでストレスは最大値、ついには「JavaScriptなんて、この世の中から消えてなくなればいいのに…」と本気で思ってしまったほどです。

謎のウィジェット改修（嫌いな理由その6）

CMS絡みでもう一つ、ページのレイアウトを自由にカスタマイズできる機能を作ることになり、これまた前任者が誰かも分からないJavaScriptコードの改修を任されました。画面上のウィジェット（部品）をドラッグして配置を入れ替えたり、背景色を変更したり、画像を表示したり――見た目のレイアウト変更をすべてAjax＋JavaScriptで実現する仕組みです。汎用的に使えるよう作られているためコードは複雑で、JavaScriptの行数もかなりのボリュームでした。さらに厄介なことに、「JavaScriptはソースコードを利用者に見られてしまうから」という理由でコメントがほとんど書かれていないのです。誰が書いたかも分からない、説明もない巨大なJSコードとにらめっこするうちに、だんだん気分が悪くなってきました。まるで迷路に迷い込んだような感覚で、「もうJavaScriptは見たくもない…」と心底思いました。

非同期処理との戦い（嫌いな理由その7）

2018年の中頃、Webページの表示パフォーマンスを改善するプロジェクトで、私は再びJavaScriptの壁にぶつかりました。あるサイトの表示速度がGoogleのPageSpeed Insightsで低評価となり、ブラウザの描画をもっと速くして欲しいと言われたのです。真っ先に思い浮かんだボトルネックは、やはり埋め込みのJavaScriptでした。

私はページの<body>直下にベタ書きされていたjQueryのスクリプトを修正し、読み込みを遅らせたり非同期（async/defer）にしたりと、試行錯誤しながら対応にあたりました。その過程で痛感したのは、サイトの至る所にJavaScriptが入り込み、表示をブロックしていたという事実です。たとえばjQueryのライブラリ自体がレンダリングを阻害していたり、画像の遅延読み込み（Lazy Load）の実装にJSが使われていたりと、どこもかしこもJavaScriptだらけでした。まるで気づかないうちにJavaScriptに侵食されていたようで、「もうこれはWebがJavaScriptに支配された世の終わりなんじゃないか…」とさえ感じてしまいました。当然、JavaScriptに対する苦手意識はさらに深まるばかりです。

広がるJavaScriptの勢力（嫌いな理由その8）

そして追い打ちをかけるように、近年はフロントエンドの世界で新しい技術が次々と登場しています。Vue.jsやNuxt.jsといったモダンなフレームワークの名前を聞かない日はありませんし、さらにはNode.jsのようにサーバーサイドにまでJavaScriptが進出してくる時代です。気づけばクライアントからサーバーまでJavaScriptが席巻するようになり、私には「世の中がJavaScriptに乗っ取られつつある」ように思えてきました。

新しいフレームワークやライブラリは魅力的ではありますが、次から次へと登場しては消えていくため、キャッチアップするだけでも大変です。せっかく覚えたやり方がバージョンアップで通用しなくなったり、便利だった関数が次のバージョンで非推奨になっていたりするのもしょっちゅうあります。JavaScriptという言語そのものだけでなく、その周辺の技術全体に振り回されているような感覚で、私は途方に暮れていました。

TypeScriptとESLintに心が折れる（嫌いな理由その9）

そんな中、JavaScriptに型付けを加えるTypeScriptというものにも手を出してみました。型チェックがあればバグが減らせて便利かも、と思ったのですが、この型定義（変数や関数にどんな種類の値が入るか指定すること）作業が想像以上に大変だったのです。オブジェクトの型を細かく定義しようとするとinterfaceやtypeエイリアスを書かなければならず、コード量が一気に増えて頭を悩ませました。

ちょっと複雑な処理を書こうとするたびに赤い波線のエラーが容赦なく表示され、「また型が合わないって怒られてる…」とコーディングのたびに心が折れそうになります。さらに追い打ちをかけたのがESLintです。ESLintはコードの品質チェックツールですが、当時の私はこのESLintにも散々泣かされました。たとえば「そのうち使うかも」と思ってimport文でライブラリを読み込んだものの、結局使わなかったような場合に「未使用の変数があります」と厳しく指摘してくるのです。コーディング中ずっと「ここがダメ」「あれもダメ」と赤字警告で責め立てられているような状態で、心が休まる暇もありませんでした。エラーを消そうと修正しても、また別の警告が増える…その繰り返しで、「自分は一生JavaScriptを使いこなせないんじゃないか」と本気で落ち込んだものです。

多様すぎる書き方に混乱（嫌いな理由その10）

私がJavaScriptに苦手意識を持った大きな理由の一つに、「書き方が多様すぎる」という点があります。JavaScriptでは同じ目的を達成するのに複数の書き方が存在し、初心者だった私は毎回「結局どれが正解なの？」と迷っていました。例えば次のような具合です。

変数の宣言方法ひとつ取っても、var・let・constと複数の選択肢がある。
関数の定義も、従来のfunctionキーワードを使う方法と、() => { }というアロー関数の書き方が存在する。
セミコロン（;）を付けるか付けないかですら、コードスタイルが人によって違う。
非同期処理に至っては、コールバック関数・Promise・async/awaitまで様々な手法があり、どれを使えば良いのか途方に暮れる。

このように選択肢が多すぎるせいで、当時の私はコードを書くたび「本当にこれでいいのかな…」と不安になっていました。ネットで調べても人によってオススメの書き方が違うため、どの情報を信じればいいのか分からなくなってしまうのです。せっかく自分なりに書いたコードも「もっと良い方法が他にあるかも」と疑心暗鬼になり、なかなか先に進めませんでした。「JavaScriptには統一されたお作法がなくて不親切だ！」と感じてモヤモヤが募り、これもまたJavaScript嫌いに拍車をかける結果となりました。

それでもどう乗り越えたか

ここまで、私が「JavaScriptなんて大嫌いだ！」と思うに至った数々のエピソードを紹介してきました。しかし、そんなこんなで一時はJavaScriptから逃げ出しそうだった私ですが、現在ではなんとか付き合えるようになっています。最後に、どうやってこの苦手意識を乗り越えたのか、その鍵となったポイントをお話しさせてください。

まず肩の力を抜くことです。TypeScriptやESLintで感じた挫折については、最初から完璧に使いこなそうとしないようにしました。型定義も、初めは厳密にやろうとしすぎず自分が理解できる範囲でざっくりと書き、慣れてきたら徐々に厳密にしていけばいいと割り切ったのです。ESLintの警告に対しても、必要以上に深刻に受け止めず「また何か言ってるな」くらいの軽い気持ちで受け流す余裕を持つようにしました。どうしても自力で解決できないエラーに出くわしたときは、その都度公式ドキュメントを確認したり、先輩エンジニアに相談したりして、一人で抱え込まないようにも心がけました。

「自分がダメなんじゃない、詳しい人に聞いてみよう」と発想を転換しただけでも、だいぶ気持ちが楽になりました。次に自分なりの定番スタイルを決めることです。JavaScriptの書き方が無数にあって混乱した件については、いろいろ試した上で「自分にとって書きやすい方法」を基準にすることにしました。例えば、変数宣言はもうvarは使わずlet/constに統一する、関数は基本的にアロー関数で書いてみる、セミコロンの有無は自分の好みで統一する…等々、自分ルールを作ったのです。もちろん状況に応じて書き分ける柔軟さも必要ですが、「まずはこのやり方で書いてみよう」という軸ができたことで迷いが減り、コードを書き始めるハードルがぐっと下がりました。「これで合っているのかな…」と手が止まってしまうことも少なくなり、だいぶコーディングが楽になりました。

それから、周りの力を借りることも克服には欠かせませんでした。jQueryに関して行き詰まっていたとき、思い切ってモダンなフレームワーク（例えばReactやVueなど）に手を出してみたのですが、これが非常に勉強になりました。「jQueryで無理に古いやり方を追わなくても、今はもっと便利な道具があるんだ」と知ったことで、逆に気持ちが楽になったのです。どうしても既存プロジェクトでjQueryを使う場面では公式ドキュメントを確認してバージョン差異に注意するようにし、闇雲にネットの情報を鵜呑みにしないようにしました。場合によっては周囲の詳しい人に「これ動かないんだけど何でだろう？」と気軽に相談し、自分一人で抱え込まないようにしたのも良かったと思います。

振り返ってみれば、JavaScriptが「大嫌い」だった一番の原因は、自分の未熟さゆえに空回りしていたことでした。悩んでいた当時は視野が狭くなって「全部JavaScriptが悪いんだ！」とさえ思い込んでいましたが、今では「当時の苦労も通過儀礼だったのかな」と少し冷静に捉えられるようになりました。もし当時の私のようにJavaScriptで挫折しそうになっている人がいたら、「そんなに気負わなくても大丈夫だよ」と伝えたいです。遠回りして一度は大嫌いになりかけたけれど、今では少しずつ仲良くなれてきた──これが私のJavaScript克服までの正直な体験談です。JavaScriptに振り回されて心が折れそうな人がいたら、どうか焦らず肩の力を抜いてみてください。きっと私のように、「いつの間にか苦手意識が薄れていた」と思える日が来るはずです。