Create a gist now

Instantly share code, notes, and snippets.

Embed
What would you like to do?
JavaScript プログラマの職種は4種類くらいに分けるべき

はじめに

JavaScript を使っていると「JavaScript出来るの? jQuery / AngularJS / Node.js etc... で困ってるんだけどさー」みたいな話を振られることがあります。 そういった時に、自分は一般的なライブラリの使い方やフレームワークに対して大した知見も興味もないので、わざわざ説明するのも面倒なのでこうして文章にしておきます。(本当に届いて欲しい人に限って、こういう文章が届かないのはわかっていますが、文章を書くこと自体が気晴らしだと思って諦めます。)

「フロントエンドエンジニア」という言葉の汎用性

先ほどのような話は自分に限ったことではなく、たぶん経験のある人も多いでしょう。 振られた話が自分の分かる範囲、あるいは興味のあるものならばまだ良いのですが、そうでないことがあまりに多すぎます。 話を振られるだけならともかく「JavaScriptできるんでしょ? じゃあ jQuery つかったこのサービスのメンテしてほしいんだけどー」みたいに仕事として振られることもあり、そう言う時は脳みそ取り出して洗剤で洗った方が良いのでは、と思うことも多々あります。

プログラミング言語が同じだけで、それに関わるすべての項目に詳しかったり興味があると思うのは殆どの場合期待しすぎです。 C 言語が使えるというだけで Linux カーネルハッカーに Windows アプリケーションを書かせますか? 偶然 Windows アプリケーションに興味のある人ならばやってくれるかもしれませんが、多くの場合断られるか転職されることでしょう。

なぜこういったことが頻繁に起こるのか少し考えてみたところ、現状 JavaScript を使うプログラマの呼び方が「フロントエンドエンジニア」というものしか知られていないからだと思い当たりました。 Node.js でサーバサイドプログラミングする人もフロントエンドエンジニアと呼ばれていると思います。 というかクライアントサイドのコード書いてたのに「JavaScript 書けるんでしょ? 今度 Node.js のプロジェクトできるから任せた」みたいな感じでいきなりサーバサイドに放り込まれた人もいるのではないでしょうか。 ともかく、「JavaScript が関係するものはすべて分かる」みたいに思われると誰も得をしないので、もっと細かく呼び方を分けたほうが良いのではという提案です。

なお、この話は自分のできるところだけしかやらない、やりたくないのかという話ではなく、JavaScript プログラマの対象とする範囲は幅広く、すべての場所で専門性を求められても困るしパフォーマンス出せないよという話です。 (まあ、本音を言えば、自分のできるところや興味のあるところしかやりたくないのですが)

どうやって分けるか

とりあえず、4種類に分けるのが良い気がします。 クライアントかサーバ、フロントエンドかバックエンドという括りです。 何がフロントエンドで何がバックエンドかは、作成するものがサービスのユーザに近いかどうかで決めます。

クライアントサイド + フロントエンド

現状の「フロントエンドエンジニア」と最も近い存在です。 jQuery や AngularJS などの MV なんとかフレームワークに興味を持ち、テンプレートエンジンなどの使い勝手や特徴などに詳しく、Web アプリケーションの設計などに興味のある人たちです。

クライアントサイド + バックエンド

ブラウザで動作するライブラリを作る人たちです。 直接ユーザにコードを届けることはしませんが、サービスやアプリケーションの機能を提供します。 JavaScript でアルゴリズム実装することが多いです。

サーバサイド + フロントエンド

Node.js などを利用したアプリケーションや Web API を提供します。 要は直接クライアントのリクエストを受ける位置をフロントエンドとします。 いかにブロッキングさせないかや適切に(主にイベントの参照が原因の)リソース解放されているか、リクエストをどれだけ効率的にさばくかなどに興味を持ちます。

サーバサイド + バックエンド

Node.js で動作するライブラリ(ネイティブ実装のバインディング含む)を提供します。 また、サーバサイド間で通信する処理用のスクリプトもバックエンドとします。 JavaScript にかぎらず、高速化が行えるならば C/C++ などの言語を使ってライブラリを作ります。

その他

例えば WebGL, Web Audio API などでデモやアプリケーションを作る人はここでいう「クライアントサイド+フロントエンド」とも少し違う気がします。 それがライブラリとして動作するならば「クライアントサイド+バックエンド」で良いと思いますが、まだまだフロントエンドの指す範囲が広いように思います。 また、Web MIDI Link のように「アプリケーションとしても動作するが、他のアプリケーションからライブラリとして呼び出せる」といった場合の分類も適切かどうか判断が難しいです。

まとめ

jQuery のこととかきかれても微塵も興味ないので困ります。

@jumperson

This comment has been minimized.

Show comment
Hide comment
@jumperson

jumperson Mar 19, 2014

HTML,CSSちょっとしたJavaScriptを書いているデザイナさんがいたりすると更に混乱しますよね。

HTML,CSSちょっとしたJavaScriptを書いているデザイナさんがいたりすると更に混乱しますよね。

@lv7777

This comment has been minimized.

Show comment
Hide comment
@lv7777

lv7777 Jan 6, 2016

javascriptやブラウザの設計をしている人はどこに入るんですかね?

lv7777 commented Jan 6, 2016

javascriptやブラウザの設計をしている人はどこに入るんですかね?

@nagofox

This comment has been minimized.

Show comment
Hide comment
@nagofox

nagofox Jan 27, 2018

背景

私は、Webアプリケーションを設計したい人で、Web技術を身に着けるべく(JavaScriptを含めて)学習するための材料を集めております。学習においては特に、区別を増やすという概念は大事だと思っております。

増えた区別に関して

Frontend Backend
Clientside ×
Serverside

注釈

◯は、もっとも関心の高い領域、区別です。△は、関心のある領域、区別です。
(So what? と思われるかもしれませんが…)

感想

今回は、こちらで、(クライアントサイド === フロントエンド)は、falseだという事に気づかされました。
ありがとうございました。

nagofox commented Jan 27, 2018

背景

私は、Webアプリケーションを設計したい人で、Web技術を身に着けるべく(JavaScriptを含めて)学習するための材料を集めております。学習においては特に、区別を増やすという概念は大事だと思っております。

増えた区別に関して

Frontend Backend
Clientside ×
Serverside

注釈

◯は、もっとも関心の高い領域、区別です。△は、関心のある領域、区別です。
(So what? と思われるかもしれませんが…)

感想

今回は、こちらで、(クライアントサイド === フロントエンド)は、falseだという事に気づかされました。
ありがとうございました。

@garchomp-game

This comment has been minimized.

Show comment
Hide comment
@garchomp-game

garchomp-game Jun 1, 2018

そうなんだ…と思わず心の中でつぶやいてしまいました。

自分のところは

・html css js周り(node含む)がフロント
・それ以外のphpやサーバーの部分等も含めてサーバーサイド
ていう感じです…実はこれハードル高いんですね

そうなんだ…と思わず心の中でつぶやいてしまいました。

自分のところは

・html css js周り(node含む)がフロント
・それ以外のphpやサーバーの部分等も含めてサーバーサイド
ていう感じです…実はこれハードル高いんですね

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment