前提

以下は、ここにある Josh Collinsworth による美しい記事への返信です。

私は、彼が記事内で述べた要約引用をそれぞれ取り上げ、それぞれに私の意見を返信することで、このコンテンツを構成することにしました。

したがって、この記事は個人的な意見を特定する一連のアイデアとみなされます。報告された 12 件の引用のうち、私は ✅ 8 に同意し、❌ 3 に同意せず、 については意見がありませんでした。 1.

[TL;DR] 私は一般的に著者の意見と視点に同意しますが、場合によっては、記事によって作成された歪んだ見解により、いくつかの記述に同意できないことがあります。私の意見では、偏見に関する分析は、開発の世界に対する著者の側の偏見と同じくらいの偏見を引き起こしました。

フロントエンドの実践が広範囲に減少しているように感じます。ほぼどこを見ても、その重要性が最小限に抑えられ、その課題が矮小化されていることがわかります。

✅ この声明に完全に同意します。

フロントエンドは長い間バックエンドの「弟」であると考えられてきましたが、これは間違いです。フロントエンドは、エンド ユーザーが見て操作するアプリケーションの部分であり、したがって製品の成功の基礎となります。その重要性を過小評価することはできませんが、このようなことがあまりにも頻繁に起こるため、私自身、フロントエンド開発者としての自分の仕事がバックエンドでの仕事よりも「劣っている」と考えることがありました。

なぜこのようなことが起こるのでしょうか?私の観点からすると、これは過去 10 年間にフロントエンド開発の世界がフレームワークやライブラリに侵食され、作業がよりシンプルになり、誰にとってもアクセスしやすくなったからだと思います。これにより、過去に生じた多くの問題に対応することができ、フロントエンド開発が「よりシンプル」になりました。これにより、「コード モンキー」と見なされることが多いフロントエンド開発者の役割の評価が低下しました。ただし、シンプルだからといって簡単というわけではありません。フロントエンド開発者は複雑な問題を解決し、重要な決定を下すことが求められることがよくあります。なぜなら、フロントエンド開発者はフレームワークによってすでに解決されている「単純な」問題を解決することを期待されなくなり、むしろ、むしろ重要な意思決定を下す必要があるからです。新しく革新的な方法でユーザー エクスペリエンスを豊かにするため。

それは、CSS が奇妙な量子状態に存在しているようなものです。どういうわけか、複雑すぎて使用できず、同時に単純すぎて真剣に取り組むことができません。

✅ ここも同感です。

CSS は、Web 開発の世界で最も過小評価され、価値が低くされている言語の 1 つです。 CSS は強力で複雑な言語であり、複雑で詳細なユーザー インターフェイスを作成できます。ただし、コードの通常の記述方法、その特定の構文、およびその動作ロジックからかけ離れているため、習得や使用が困難になることがよくあります。 CSS は、習得するのに時間と献身が必要な言語です。

CSS-in-JS 運動で起こったことは、コミュニティがどのようにして存在しない問題を解決しようとしたかを示す明らかな例です。すでに非常に複雑な言語に抽象化を加えながら、新しい言語を作成します。

多くの点で、CSS はユーザー エクスペリエンスに他の言語よりも大きな影響を与え、多くの場合、成功に直接影響します。では、なぜその役割がそれほど軽視されているのでしょうか?

✅ 同意します。

前の引用への返答で述べたように、CSS の問題はその操作ロジックとその特定の構文によるものだと私は考えています。問題は、JavaScript が JavaScript と比較して「二次」言語とみなされていることが多いことですが、実際にはそれ自体がルールや特徴を備えた言語であり、プログラミングと同等の学習時間を必要とします。 CSS は強力かつ複雑な言語であり、その役割を過小評価することはできません。

ほとんどの場合、フロントエンドの重要性が低いとか、現実性が低いとか、フロントエンドを行うのにそれほど賢明である必要はないなどと実際に言う人は誰もいません。しかし、それは暗示されていることが多いようです。

✅ 部分的に同意します。

実を言うと、私はこのテーマが著者が言うよりもはるかに明白だと考えています。実際、私はフロントエンドをバックエンドに比べて「マイナーな」仕事だと考えており、フロントエンド開発者は

プログラマーであるべきではなく、サポートは、実際の作業であるバックエンドを行う人々に。私の役割は何かと聞かれると、私は常にフルスタックと答えます。なぜなら、私のトレーニングと成長にはさまざまな異なる要素があり、コインの両面が私にとって重要で重要だからです。

この考え方を根絶するためにコミュニティはさらに努力する必要があると私は信じています。フロントエンド開発者はあらゆる点でプロフェッショナルであり、彼の仕事は製品の成功の基礎です。

フロントエンド開発者は、絶えず進化するツールによってサポートされながら複雑な問題を解決し（これにより認知負荷が大幅に増加します）、製品の成功の要であるユーザー エクスペリエンスに直接影響を与える重要な決定を下すことが求められます。

私たちのアウトプットはある程度芸術的ですが、芸術的なものには、単に単純で楽しそうに見えるという理由だけで、悲劇的に価値が下がってきた長い歴史があります。

✅ 同意します。

役割と責任に対する理解の欠如が、私たちの業界で根本的な役割を果たしています。フロントエンド開発者は「アーティスト」、「クリエイター」として見られることが多く、彼の仕事はバックエンド開発者のような「技術的」ではないため、価値が低くなります。これは 2 つの点で間違いです。

まず第一に、アプリケーションのデザインを決定するのはフロントエンド開発者ではなく、デザイナー (UX、UI、お好みで呼んでください) であることがよくあります。フロントエンド開発者は、設計をコードに変換し、効率的かつ高パフォーマンスの方法で変換することが求められます。これには、単にコードを書くだけではない、技術的なスキルと特定の知識が必要です。

第二に、すでに上で述べたように、フロントエンド開発者の責任は、多くの場合、単にコードを書くことをはるかに超えています。バックエンド アプリケーションのコードを変更すると、自動テストは私よりも早くリグレッションに気づく可能性が高くなります。フロントエンド アプリケーションのコードを変更した場合、リグレッションに気づく唯一の方法は、アプリケーションを手動でテストするか、エンド カスタマー* からのレポートを待つことだけである可能性が高くなります。このため、フロントエンド開発者の仕事は、思っているよりもはるかに複雑で要求の厳しいものになっています。

ビジネス ロジックと状態管理の量は言うまでもなく、両方ともすぐにフロントエンドに注がれ、その役割がビジネスとますます統合されています。

*注: エンドツーエンド テストの存在はよく知っていますが、その実装は従来の自動テストよりもはるかに複雑で高価であり、さらにそのランダムな外部条件により信頼性が疑問視されることがよくあります。

この言語は、インターフェイスがソフトウェアから切り離されており、ソフトウェアの実際の一部ではないことを意味します。

?これについては意見がありません。

ここで言及しているのは、私たちの分野では

開発者とエンジニアの間に違いがあるようで、どちらが必然的にもっと何​​かとして示される必要があるという矛盾です。 ]。この件について私は意見を持っていませんが、今日、タイトルやバナーの蔓延は、私たち一人ひとりが実際に何をしているのかという点で水を濁すだけであるという点には同意します。

CSS を書くことは、会議でメモをとることと同じようにみなされているようで、暗黙の性差別と会議室におけるメモを取る人の重要性の軽視が伴います。

✅ 同意します。

この記事ですでに述べたように、CSS とフロントエンドの世界一般の誤った評価については私も同意します。さらに、記事のこの部分では、私たちの分野に存在する排外主義について言及されており、私はそれを直接認識したことはありませんが、その現実と重大さは理解しています。私たちの業界は依然として女性にとって敵対的な環境が多すぎるため、コミュニティはこの考え方と闘うためにもっと行動する必要があると信じています。

過去、現在、そして未来において、あらゆるデバイス、オペレーティング システム、画面サイズ、ブラウザ、ユーザー設定、インターフェイスをサポートするというほぼ不可能に近い仕事が非常に単純であるかのように、私たちは退屈しているからといって、すべての複雑さを自分たちで発明してしまいました。

✅ この声明の本質的な意味に同意します。

今日の世界の複雑さにより、フロントエンド開発者の役割はこれまで以上に複雑になっており、フロントエンドのジョークや

オチが偏見になると、陥りやすくなります。フロントエンド ワーカーの仕事の価値を下げるという罠。

はい、グループとして、私たちは新しいことに興奮します。しかし、なぜそれが私たちに好奇心を持たせたり、順応性を高めたり、探究心を持たせたりしないのでしょうか?定位置に留まることを拒否したことで非難されるのではなく、学習する喜びを評価してもらえるのはなぜでしょうか?

❌ 私はこれにはあまり同意しません。

フロントエンドの世界の進化により、アイデア、ツール、方法論が急増したことは事実ですが、

シャイニー オブジェクト症候群は、特にフロントエンドコミュニティ。これは、好奇心や順応性を持ってはいけないという意味ではなく、メリットとデメリットを完全に理解せず、また、それらが実際に必要かどうかを評価せずに、新しいテクノロジーを採用するという罠に陥ることがよくあるということです。

もし私たちのスキルが、組織の欠陥を埋めるダクトテープのように価値があるのであれば、それらの欠陥を防ぐことができる可能性があるにもかかわらず、その欠陥を引き起こした計画や意思決定の段階ではなぜ価値がないのでしょうか?

✅ 完全に同意します。

ソフトウェア アーキテクト (またはテクノロジ リード、またはアーキテクチャを担当する人) と同様に、チームのすべてのメンバーをアーキテクチャの選択に関与させる必要があります。最終決定権を持ち、最終的には責任を負うにもかかわらず、意思決定も行う必要があります。 - アプリケーションまたはその一部の作成につながる作成プロセスには、フロントエンド開発者を含むチームのすべてのメンバーが関与する必要があります。これを長く続けている人は、他の人には気づかないようなユーザー エクスペリエンスやデザインのギャップを発見できる可能性があり、意思決定プロセスに参加させることで、より良いユーザー エクスペリエンスと製品の成功につながる可能性があります。

フロントエンド ツールは、あたかもフロントエンドが誰もやりたくないものであり、必要以上に気にする必要がないかのように宣伝します。

❌ 投稿が進むにつれてフラストレーションが増大しているのがはっきりとわかりますが、この場合は同意できないとしか言​​えません。

Josh が定義する

フロントエンド ツールの

マーケティング は、いくつかのまれな例外を除いて、開発者の課題を矮小化したり、単純化しようとしたりすることはありません。これらのツールは、フロントエンド開発者の作業をよりシンプルかつ効率的にすることを目的としていますが、決して平凡ではなく、方向性が同じであることは正しいことです。約束は、フロントエンド開発者をコード モンキーにすることではなく、本当に重要なこと、つまり成功するユーザー エクスペリエンスの作成と、ビジネスと周囲の世界への影響に集中できるようにすることです。同じことがバックエンドの世界にも当てはまります。バックエンドの世界では、開発者が技術的な選択や構成の問題ではなく、製品に集中できるようにツールが進化しました。

最後に、開発者関係の世界は近年、構造化された方法で発展しており、一部の企業によるいかなる失敗も標準とみなされるべきではないことを思い出してください。

フロントエンドが製品の重要な部分であるとはもう誰も考えていないようです。彼らはそれを、製品が到着する素敵な箱だとしか考えていません。

❌ ここでも、悲しいことに、私はジョシュの意見に同意しません。

フロントエンドは製品の基本的な部分であり、その重要性を過小評価することはできませんが、必ずしも複雑さや抽象化に耽る必要があるというわけではありません。フロントエンド開発はすでに非常に洗練された設計や難解なアーキテクチャを必要としないほど十分に複雑であり、バックエンドの世界とまったく同様に、事実を十分に理解した上で標準化を行えば、不必要な認知的負荷を加えずに他の側面に集中することができます。製品の