rontend 4 で消滅する必要がある開発神話-CSSチュートリアル-php.cn

rontend 4 で消滅する必要がある開発神話

Linda Hamilton

リリース： 2024-12-28 22:34:12

オリジナル

371 人が閲覧しました

rontend Development Myths That Need to Die in 4

フロントエンド開発は、過去 10 年間で大きな進歩を遂げました。しかし、フロントエンド開発者としての私たちの活動についての根強い神話のいくつかは消えようとはしていません。これらの神話は初心者を混乱させるだけでなく、ユーザー向けソフトウェアを構築する作業と課題を誤って伝えています。私が個人的に遭遇したこれらの通説のいくつかと、なぜそれをきっぱりと破る時が来たのかを共有しましょう!

誤解 1: CSS は簡単です!

みんなが大好きなスケープゴートである CSS から始めましょう。確かに、セレクター、プロパティ、値という一見するとシンプルに見えます。どれほど難しいでしょうか？さて、グーグルせずに div を中央に配置してみてください。さらに良いのは、Z インデックス 9999 が機能しない理由を説明することです。 (待ってます。)

CSS は一見強力なツールですが、次のようなニュアンスを理解する必要があります。

特異性戦争 (こんにちは!重要な虐待!)。

フレックスボックスとグリッドの混乱。

人生の選択に疑問を抱かせるブラウザの不一致。

Chrome では完璧に動作するのに、Safari では崩れてしまうレイアウトのデバッグに何時間も費やしてきました。したがって、次回誰かが「CSS は簡単です」と言ったら、表面の単純さの裏には多くの複雑さが隠れていることを親切に思い出してください。

誤解 2: フレームワークがすべてを解決する

React、Angular、Vue は、間違いなく素晴らしいです。しかし、本当のことを言うと、フレームワークがすべての問題を魔法のように解決するわけではありません。

フレームワークは UI の複雑さを管理するツールを提供しますが、小規模な静的サイトには過剰になる可能性があります。 3 つの段落と画像を含む単一ページの Web サイトに React を使用することを想像してください。そうです、それはあなたが思っているよりも頻繁に起こります。

私は、単純な HTML ファイルの方が高速で保守しやすいのに、過剰なエンジニアリングによって行き詰まったプロジェクトを見てきました。フレームワークは強力ですが、独自の学習曲線、パフォーマンスに関する考慮事項、および技術的負債が伴います。賢く使用してください。

誤解 3: バックエンドは難しい部分です

ああ、フロントエンドとバックエンドの長年にわたる議論。バックエンドエンジニアは、自分たちの仕事はより「複雑」だと言って、高みを主張するのが好きです。しかし、彼らはこれまでに次のようなことに対処したことがありますか?

国家管理の混乱?

大規模な DOM ツリーのパフォーマンスの最適化?

サイトの視覚的な魅力を維持しながら、スクリーンリーダーがアクセスできるようにするには?

API の文書化が不十分だったり、突然の設計変更により、単純なフロントエンドのタスクが 1 週間にわたる頭痛の種に変わってしまった瞬間を数え切れないほど経験してきました。最新のフロントエンド開発には、API の統合からデバイスやブラウザ間でアプリがスムーズに動作するかどうかに至るまで、非常に困難な問題の解決が含まれます。フロントエンド開発者に当然の栄誉を与えましょう。

誤解 4: 急いでいる場合はアクセシビリティをスキップしてもよい

アクセシビリティ (a11y) は、特に締め切りが迫っている場合、「あれば便利なもの」として扱われることがよくあります。ここで重要なのは、アクセシビリティはオプションではないということです。

なぜ?

これは多くの国で法的要件です。

これにより包括性が確保され、誰もがアプリを使用できるようになります。

全体的な使いやすさが向上します - キーボードナビゲーションをご存知ですか?

これは、私が取り組んだプロジェクトがアクセシビリティ監査に不合格となり、大幅な遅れが生じた後、苦労して学んだことです。それ以来、私はアクセシビリティをワークフローの譲れない部分としてきました。 Lighthouse や ax などのツールを使用してサイトを監査し、アクセシビリティを後付けではなくプロセスの一部にします。