プログラミング言語やフレームワークに関する疑問をググるとだいたいQiitaの記事がヒットして、開くたびにアカウント登録しろしろとうるさいのでキレながらアカウント作りました。サブカルメンヘラクソ女の@hg0です。折角なのでアカウント登録のついでに書こうと思います。
大学は芸術系で、デザインやメディアアートをかじっていた程度なのですが、縁があってWebエンジニア業界に就職することが出来ました。
2年ほど、フロントエンドのお仕事・勉強をさせて頂いて思ったこと、躓いたこと、各言語やフレームワークを使って思ったことを振り返りながら書いてみようと思います。
言語・フレームワークについて
HTML/CSS/JavaScript
「Webサイト制作」「フロントエンド」の勉強をするにあたって、誰もが一番最初に学ぶのは間違いなくこれだと思います。どれも国際的な団体が、仕様や書き方を中立的に定めている、Web業界の標準語で、ブラウザが直接理解できる、共通の言葉です。この記事に登場する様々な技術、フレームワークの全ての根幹になっていて、何を使っても最終的にはこの3つに変換されることになります。
何か分からないことがあっても、MDNを見れば大抵のことが、しっかり書いてあります。しかも記事のほとんどは日本語に翻訳済みです。
私は大学までは趣味で、ちょっとしたWebサイトやWordPressを使ったブログなどを作っていました。JavaScriptはjQueryと一緒に使うことがほとんどでしたが、「もうjQueryは古いし、できるだけ使わないようにしたほうが良いよ」とフォロワーさんに指摘されたのをきっかけに、document.querySelectorAll とかJavaScriptの標準の機能を使うようになり、モダンなJavaScriptの世界に入っていきました。
HTML、CSS、JavaScript……これらのWeb標準の言語はすごいと思います。Webサイトというものが登場してから、もう四半世紀近く経つのではないかと思いますが、その書き方や仕様は少しずつ変化しているものの、Webサイトを作るにあたって必ず必要になる、不動の言語たちです。
それからはSNSのAPIを叩く簡単なツールを作ったり、大学の研究では空間芸術作品としてMaxやProcessingといった芸術系のプログラミングツールをAPIを介してWebサイトと連携した作品を作ったりしました。
Vueとの出会い
就職して、仕事で最初に触ったJavaScriptフレームワークがVueでした。ファイルの拡張子こそは .vue ですが、書き方はhtmlやjavascript、cssの標準の仕様とほとんど変わらず、理解しやすいです。フレームワークを使うのは初めてでしたが、基本的な部分は数週間〜１ヶ月くらいで習得できた記憶があります。
他のフレームワークでもそうですが、コンポーネントという概念で、例えばボタンのデザインやテキストボックスをカスタマイズして使い回し、WebサイトやWebアプリを作っていけることに感動しました。
Vueや、Vueを拡張したNuxtといったフレームワークは今でも大好きなので、時間さえあれば、昔作ったWordpressのブログや直書きのhtmlで作ったWebサイトなんかもVueやNuxtに移行できたらいいなと思っています。
React
Vueはhtmlファイルとほぼ同じ構造の.vueファイルの中に、<script>タグを使ってJavaScriptを書くのに対して、Reactは、JavaScriptの中にHTMLタグのようなものを書く、jsxという独自の文法を使います。ひとつのコンポーネントがJavaScriptの中だけで作られていく感じでした。
嫌いというほどではないのですが、これが少し厄介で、たとえば標準のhtmlでタグにclass名を付ける際は <span class="hogehoge"> といった書き方をするのに対して、Reactでは <span className="hogehoge"> というように、 className と書かないとエラーになって怒られます。JavaScriptの中ではclassという単語が使えないからです。
この辺を勉強した辺りから「標準もどき」、HTML/CSS/JavaScriptっぽく書けるけど、ちょっと違うもの が苦手になってきました。
また、React Nativeを使うと、JavaScriptだけでWebViewではない本物のスマホアプリも作れてしまいます。これは魅力的でした。
TypeScriptは使う意味がわからなかった
仕事を始めて、いちばん最初に苦戦したのがTypeScriptです。
TypeScriptは、Microsoftが作った、複雑な変数の型をつけられるJavaScriptもどきの言語です。標準語であるJavaScriptとは違って、ブラウザは直接理解できないため、コンパイルという作業を通して、JavaScriptに戻す必要があります。
コンパイルする時にエラーが出まくったりとか、VSCodeで文法エラーの赤い波線が出まくったりとか、ググってもよく分からないエラーメッセージが出まくったりとかで、嫌になりました。
普通にJavaScriptを使って開発をした場合でも、webpackやbabelなどのツールでコンパイルに似た作業をして、古いブラウザに対応させたり、JavaScriptのファイルサイズを小さくするのは当たり前になっています。「最新の標準語」に対応していない古いブラウザだったり、サイトの読み込み速度を改善するための機械翻訳のような作業なので、必要性はわかります。でも、TypeScriptはどれだけのエンジニアに支持されていようと、「標準」ではないです。
マイコンとかArduinoとかで使われるC言語のように、「型を使うことによってメモリの領域を管理する」とかなら分かるんですが、WebサイトやWebアプリといったものは、ブラウザが勝手にメモリを管理してくれるはずですよね。だから、複雑な型システムを使う必要性が、調べても理解できませんでした。API側やサーバーサイドのエンジニアと連携するときに、型を定義したほうが便利、というのもあると思います。その場合でも、APIの仕様をちゃんと日本語でまとめるとか、JSON Schemaと呼ばれるJSONの書き方を示すファイルを書けば十分だと思います。
TypeScriptでは型を定義するファイルとコード本体が別になっていて、コードの中で使われている型がどういう型なのかは、コードと型を書いた人にしかわかりません。つまり、別の場所にある定義ファイルをいちいち探してきて、調べる、といった作業が必要です。はっきり言って面倒の極みです。
そもそも、元々のJavaScriptにも、必要最低限の型は揃っています。それで十分だと思います。ブラウザが直接理解できる、JavaScriptという標準語があるんだから、それでいいじゃないですか。TypeScriptでわざわざ型を書いたところで、JavaScriptにコンパイルしたら消えるだけです。単純に書く量も増えて、エラーも出まくって、効率が落ちるだけです。TypeScriptを使わなくても、自分の書いたコードが悪かったら仕事をする上では上司や先輩に必ずコードレビューをしてもらいますし、ESLintという優れた文法チェックのツールもあります。
これだけ面倒でも、最近のフロントエンドはTypeScriptが使われていることが多くて気が滅入ってしまいます。面倒さを上回るメリットや理由があるんでしょうか。
SCSS/SASS, Pug, etc...
ほとんど使ったことがないですが、CSSやHTMLの無駄な部分を省いて簡単に(？)書けるようにしたものです。例えばpugはhtmlの閉じタグを省略できたりします。ただこれも結局はTypeScriptと同じで、ブラウザが直接理解できるわけではないので、コンパイルが必要な言語です。自分からはできるだけ使いたくないです。楽に書けるのかもしれないですが、環境や設定を整えたりするほうが面倒です(複数人で開発するとなると余計に)。
htmlの閉じタグはVSCodeが勝手に入れてくれますし、インデントやスペースの数を適当に書いたとしても、自動整形ツールのPrettierを設定していれば勝手に整えてくれます。その反面、SASSやpugはインデントやスペースの数が崩れると100%エラーになります。コンパイラの設定がミスっているのか、何も編集してないのに上書き保存ボタンを押しただけでコンパイルエラーが出たりもしました。SCSSの変数は便利かもしれませんが、素のCSSでも変数を使うことは出来ますし、IE11以外ではとっくにサポートされています。
Angularはまあまあ
AngularはGoogleの作ったフレームワークで、1つのコンポーネントがフォルダにまとまっていて、そのフォルダの中にhtml, css, jsがまとまっているという構造で、かなり分かりやすいです。その分、1つのコンポーネントを編集するために、3つのファイルを同時に開いて編集しなくてはいけないので、エディタのタブの切替とかがめちゃくちゃ面倒なのが難点です。それから、せっかくHTML/CSS/jsというWebの標準技術に則っているのに、TypeScriptを使うことを前提としているのは残念です。
また、マテリアルデザインをやたら推しているので、Angularで作られたWebサイトやアプリはマテリアルデザインを使っていることが多い気がします。個人的にマテリアルデザインは正直なところ、elevationといった独自の概念がWeb向きではない気がするのと、UIのデザインができないエンジニアが公式のガイドラインも見ずにとりあえず使って、品質の悪いアプリが量産されてる印象があって、好きではないです。
あとは ng serve や ng lint といった独自の開発用コマンドを使う必要があり、その辺りの細かい設定の調整がしづらいです。例えば、2020年現在、TSLintは開発の停止が発表され、ESLintに統合されることが決まっていますが、Angularに同梱の ng lint コマンドの中身は未だにTSLintのままで、開発が進んでいないようです。公式ドキュメントのサイトの挙動も微妙におかしいし重いし、大丈夫なんでしょうか。
VueやNuxtと比べて、大きなWebサイトやWebアプリを作るのには向いていそうな気がします。
Ruby on Railsはもうやりたくない
Rubyというプログラミング言語で、フロントエンドもサーバーサイドも書けるようにしたフレームワークがRailsです。「これさえマスターすれば、なんでもできるよ。君もこのレールに乗ろう！」というのが売り文句のようです。
仕事で少しだけ触る機会があって少しだけ勉強したのですが、そもそもRailsにはAPIという概念がなく、 .html.erb というHTMLもどきの言語を使って書きます。何回も言いましたが標準もどきの言語は嫌いです。
Rails流の書き方や、フォルダ構成などを強制されるのも苦手でした。例えば、JavaScriptやCSSを置く場所が決められていて、その適用範囲がどこになるのか、把握するのが難しいです。どちらかというとフロントエンドエンジニアのためのフレームワークというよりかは、サーバーサイドエンジニアがフロントエンドを書くために補助的に使うもの、という感じがしました。
Web Components
それだけ標準にこだわるならWeb Componentsがあるじゃない……って言われそうなんですが、まだ使ったことないです。仕事でも使う機会がないのと、ちょっと調べた感じだとまだ今後に期待……みたいな記事しか出てこないので、いつか未来が来てほしいですね。
仕事・勉強のやり方について
新しいフレームワークや言語を習得するにあたって
私は、本を買ったり学習サイトを見たりする前に、必ず公式のドキュメントやチュートリアルを見るようにしています。例えば、新しい家電を買った時に、その家電の使い方をググるよりも、取扱説明書を読んだほうが確実なのと同じです。その家電を作った人たちが、その家電について一番よく知っているはずです。
また、プログラミング言語やフレームワークといったものは、バージョンが上がるにつれて新しい書き方が出来るようになったり、仕様が変わったり、書き方が廃止されたりします。そうなったときに情報が反映されるのは、公式が当たり前に一番早いです。このように、移り変わりの激しい業界というのもあって、勉強のために本を買うのは無駄だな、と勝手に思ってしまっています。
上に挙げたようにいろいろなフレームワークや言語を学んだり使ったりしてきましたが、Railsに関してはその公式ドキュメントが貧弱すぎるように感じました。「これさえあれば何でも出来る」故に膨大な分量があり、RailsやRuby自体はどんどんアップデートで機能が追加されるのに対してドキュメントの更新が追いついていないような状況でした。そのせいもあってか、「Rails 公式ドキュメント」でググると、有志(？)による非公式のドキュメントだったり、有料の勉強用サイトばかり出てきて、公式がどこにあるのかわからない状況です。新規参入者の受け入れに消極的で、なんとなく閉鎖的だなと感じてしまいました。
他人のコードを読むのが苦手
既存のコードに修正を加えるような仕事を割り振られたとして、未経験のフレームワークや言語が使われていると、途端に何をしたらいいのか分からなくなります。TypeScriptやRailsの節でも書きましたが、そのフレームワークや言語の流儀、またコードを書いた人特有のルールみたいなものを分かっていないと、何十もあるファイルの何千行もあるコードの中から、どの部分がどのように使われてるか探し回る羽目になります。1人で開発する分には良いのですが、仕事では一つのものを複数人で手を加えて、Gitなどで合体させて……といった作業を繰り返すことになるので、READMEにどこに何があるのかしっかり書く、変数の名前は無理に省略せず分かりやすくする、コード中にコメントで注釈を入れる、などは最低限やって欲しいし、私も今後は気をつけようと思いました。
仕事で使われる用語が難しい
業務では「LP」「LGTM」「SPA」「SSR」「WBS」「MTG」「LT」といった略語、業務に関係ない日常会話でも「コンテキスト」「パース」「デプロイ」といったカタカナ語を使う人が多い気がします。エンジニア以外の業界でも勿論業界用語はありますし、便利な言葉は多用される傾向にあると思いますが、それを知っている前提で会議中に突然知らない業界用語を使って質問をされると、逆にその言葉の意味を質問して恥をかく羽目になってしまいます。コードレビューのコメントなどでも、知らない単語が頻繁に出てくると、頭が一杯になってしまいます。都度調べてはいますが、皆さんはそういった単語をどこで覚えてきてるんでしょうか。それとも世間の常識なんでしょうか。会社にはエンジニアではない事務や経理などの方もいますし、せめて業務以外では一般に通用する語彙で会話できたらな、と思います。
自由な風潮は自分に合っていると思う
やっぱりメンヘラクソ女なので、社会生活は苦手です。大学の同級生は芸術系の道に進んだ方もいれば、SEなどの職に就いた方も多いのですが、毎朝化粧してスーツに着替えて出向……なんて絶対私には出来ないと思います。リモート勤務・フルフレックス制なので、気持ちが沈んでいるとき、体調が悪いとき、仕事以外の趣味に集中したい時など、休みたい時には自由に休めます。その一方で、案件の納期が迫っている時や、出勤時間が足りなくなってきた時、違う時間帯に作業している人とのコミュニケーションなどで、精神をすり減らすこともありますが、その辺はトレードオフかな、と思います。
同じエンジニアでも、会社や業界によっては、支給のPC以外一切使用禁止だったりとか、業務時間外に社内のサーバーにアクセスすると怒られたりだとか、色々厳しいみたいな話も聞きます。
分からないことで躓いて精神を病むことも多いですし、芸術の道に進みたかった気持ちもありますが、UIやUXなどはデザインや人間の感性と大きく関わる部分もあり、フロントエンドエンジニアとして働くことができて満足しています。
まとめ
- jsxやts、sassなど、Webの標準以外の記法が嫌
- 言語やフレームワークはかなり好みの差が出てくる
- 会議で専門用語が出てくると話についていくのが大変
- 自由な仕事スタイルは良い
「フロントエンドエンジニア」として仕事を始めてから経験が浅いこと、サーバーサイドやバックエンド、インフラなどに関しては知識0なので、まだまだ知らないこともあると思いますが、初心者の正直な感想としてはこんな感じです。