HTML 一直是咱們編譯的目標 – 咱們能夠解決好它嗎？

• 原文地址：HTML is and always was a compilation target – can we deal with that?
• 原文做者：Christian Heilmann
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：CodeMing
• 校對者：jerryOnlyZRJ，Fengziyin1234

HTML 一直是咱們編譯的目標 – 咱們能夠解決好它嗎？

每隔幾周，Web 開發者的 Twitter 圈都會由於糟糕的 HTML 代碼而吵到瘋狂。但 HTML 只是一些帶有各類各樣屬性的 div 和 span 而已。有些 HTML 不只缺少任何可見的接口，例如錨點或按鈕，也缺少任何結構，例如頭部和列表。啊，這就是非語義的 HTML，不可讀的 HTML。

HTML 的定義很清晰，因爲它的語法有着很高的容錯率，它也很健壯。在XHTML時代，咱們試圖讓HTML下降容錯率，可是網絡環境不容許咱們這樣作。開發者犯下的錯不該讓用戶背鍋，而應該讓瀏覽器寬容 HTML 同時在渲染時自動修復錯誤。這個問題應讓咱們產生擔心：咱們被迫忍受多年來瀏覽器的糟糕決定。這就是爲何 HTML 不像其它語言那樣（進步得很快）—— 由於瀏覽器太臃腫和緩慢了。

HTML 容許咱們犯錯

首先，HTML 的高容錯率幫助了 web 世界存活下來。它確保了現代瀏覽器也能夠顯示很老的內容，而無需進行更改。不少年的 Flash 內容如今都沒法使用了，這件事證實在網絡這樣波動很大的環境中，容錯率高是一件正確的事情。

可是, 這確實意味着對非語義 HTML 沒有可感知到的錯誤。用 div、span 來實現 table 佈局仍然能夠正常工做（說的就是這個網站：hackernews）

展現給咱們全部內容的瀏覽器讓咱們感到擔憂，由於它讓「乾淨整潔「和「語義化」的 HTML 變成了一種少數人擁有的特殊技能。HTML 做爲網絡創做的文字，其書法千千萬，其中有大多數的內容都像是隨意塗寫的塗鴉。

語義化的 HTML 是很棒的，咱們能夠確保它沒有問題。你能夠從語義化的 HTML 中獲得不少顯而易見的好處。它每每表現得更好，它一般也意味着沒有第三方依賴，也容易閱讀和理解。咱們中的不少人學習 web 知識是經過閱讀其餘 web 站點的源碼，這個方法已通過時了，我幾個月前寫了這篇文章。

如今是時候開始在更成熟的層面上處理這個問題，而不是每隔幾個月就重複一樣的抱怨了。

HTML 一直都是一個編譯目標。「手寫 HTML」 的玩法僅僅適用於一小部分吵鬧的愛好者。

我是那些吵鬧的愛好者中的一員，至今我已經寫了 14 年博客了。我熱愛這個對全部人都開放的 web 世界。你只須要一個編輯器，一些（工具的）使用文檔就能夠在 web 世界上發佈你的做品。

手寫的 HTML 是稀有品，它應該是收藏品

大約20年前，當我開始成爲一名 web 開發者的時候，（用工具編譯 HTML）並非人們的工做方式。那個時候沒有什麼特別大的 web 產品被創造出來——事實上，一個職位需求中沒有要求「手寫 HTML/CSS/JS 的能力「都是很反常的。那時關注 HTML 規範化的是一個精英匯聚、興趣濃厚的團體。若是你可讓 web 世界變得更加清晰，更加語義化，那麼你就是一個很棒的人。可是咱們到底要改變什麼呢？

web 世界的大部分都是基於除了 HTML 之外的其餘技術：

• 服務端基礎（記得 .shtml 頁面嗎）
• CGI/Perl 模版引擎
• 用內容管理系統和咱們自定義的模版語言來生成 HTML
• 用來生成一些相似於 HTML 的 WYSIWYG（所見即所得）編輯器
• 模版語言，例如 PHP、ColdFusion、Template Toolkit、ASP 以及其它
• 在線編輯器和頁面生成器，例如 Geocities
• 論壇和博客編輯器有時擁有本身的語言（還記得 BBCode 嗎？）（譯者注：BBCode 是一類標記語言，相似於 Markdown。wiki：zh.wikipedia.org/wiki/BBCode…

這些技術沒有一件是在 web 上發佈產品所必需的。但在我工做過的一些大型公司中，他們的內容管理系統是及其複雜和龐大的，但人們卻選擇用它。由於它提供了一個更簡單、更明確、更清晰的 web 內容發佈途徑。他們解決的是開發人員和產品經理之間的問題, 而不是最終用戶體驗。Geocities 及相似的服務讓人們在網絡上發佈做品更加容易，由於這些服務使得人們甚至不須要編寫任何代碼。

你在瀏覽器裏看到的幾乎不會是源代碼。若是你想去提升代碼質量，你須要去追溯到代碼的源頭。

即便咱們選擇看網頁的源代碼，那也不是某我的寫的代碼，而是由服務端代碼處理各類數據甚至是優化後返回給瀏覽器的代碼。

這樣作是有其道理的。有不少不一樣的公共組件容許人們同時使用它們。通常狀況下，你的網站導航是全球性的，甚至是由其餘部門或公司編寫和維護的。你甚至沒法修改 HTML，若是幸運的話，你能夠解決網站 CSS 的一些問題。

HTML 是一個編譯目標

咱們回到如今。HTML 並非一個很酷的東西，各種模版語言（例如 Markdown Pug、Jade 以及其它）層出不窮。這些模版語言都但願能讓咱們從 HTML 在不一樣環境下的可靠性和兼容性問題中解脫出來。

HTML 有一個在某處可用，卻不能確保其它地方可用的壞名聲。比起只能確保兼容老舊技術的框架，一個能提供更強功能且與時俱進的框架會更加使人興奮。

web 世界不該該受到咱們的控制，可是咱們須要去知足用戶的需求。對於他們來講，在規定時間內給出了被需求的接口才是他們的任務。咱們應該改變這個現狀！

HTML 看起來不是咱們所須要擔憂的東西——它在一個容錯率高的環境中運行。它一般被看做是更好地利用你的時間來學習更高的抽象。人們不但願創建一個單純意義上的網站，而是想構建一個應用程序。儘管大多數狀況下，他們並不須要一個應用。咱們在保證 HTML 的趣味性上犯錯誤了。咱們但願網絡能給咱們更多的功能，讓其能夠與手機上的原生代碼並駕齊驅。但這老是致使咱們的應用有更高的複雜度。構建可擴展 web 的宣言 基本證實了網絡上的發佈者須要有比實體的做家或出版商更多的開發者思惟。咱們想要控制，咱們想要負責。如今咱們是這樣作了。

這樣作讓咱們剩下了什麼？首先，咱們須要去兼容如今 web 世界中現有的由服務器處理過的代碼。查看最終結果、感嘆其代碼質量是沒有意義的。沒有人寫過這些代碼，意味着它是不可讀的。

我不會放棄語義化 HTML 及其優勢，但我明白，咱們不會經過告訴開發者他們的產品是可怕的來講服他們。咱們須要與框架開發人員合做，這些開發人員是組件的建立者。咱們須要幫助模板源代碼，這些模板源代碼是框架渲染器。咱們須要確保轉換階段產生良好的 HTML 代碼——而不是簡單的 HTML。

同時咱們須要和工具開發者合做來確保人們瞭解語義化的價值。集成在編輯器內的代碼 Lint 和自動化有很大的發展潛力。如今咱們有了更多的工具可供選擇，以確保開發人員作正確的事情，而沒必要考慮它。我喜歡這個主意，它讓咱們從源頭上解決問題，而不是抱怨症狀。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。