近期，一系列博客文章引發了關於JavaScript框架成本的熱議，凸顯了負責任地使用JavaScript的重要性。
故事始於Eric嘗試在一家醫療服務提供商網站上預約就診，結果卻遭遇了空白屏幕。
現代醫療的客戶體驗依賴於React和Webpack，並伴隨大量的遙測數據。
對於熟悉Web開發的人來說，原因顯而易見：過度依賴JavaScript的網站，其邏輯與調用的其他錯誤邏輯發生衝突，導致死鎖。
但對於非專業人士而言，這並不明顯。他們看到的只是永不停歇的加載動畫。
這在某些情況下可能只是小麻煩，但在關係到健康問題時，後果不堪設想：
尋求幫助的人不會關心TypeScript、tree shaking、熱模塊替換、A/B測試、燃盡圖、NPS、OKR、KPI或其他創業術語。如果用戶無法獲得所需服務，開發者體驗就毫無意義。
這就是現實的衝擊。當我們的工具和報告——本應提高工作效率的工具——反而妨礙了用戶體驗時，會發生什麼？這些工具本應提供洞察力，幫助我們預測用戶的需求，尤其是在緊急情況下。
我知道，將矛頭指向JavaScript框架本身容易引起爭議。但這不僅僅是關於使用React還是其他框架的問題，而是業務優先級和開發者體驗與用戶體驗之間的衝突。
緩慢而復雜的框架的支持者成功地將低效的框架包裝成新潮事物，儘管其缺陷隨處可見，卻擠壓了更高質量的選擇。
這些技術最初打著“提升用戶體驗”的旗號，但在高成熟度組織之外，完全未能兌現承諾。在更廣泛的Web環境中，這些新技術棧已被證明是昂貴的失敗品。
問題就在這裡。 Alex直言不諱，但他指出責任在於框架的營銷方式，而非開發者本身。營銷策略是什麼？
一旦檸檬賣家灌輸了“改進開發者體驗（DX）會導致更好的用戶體驗”的理念，“改進DX”就變成了目的本身，許多明知其弊的人也被迫參與其中。長期掩蓋用戶體驗的負面影響是一種策略，而非錯誤；他們不需要你成功，只需要你繼續購買。
從營銷角度來看，這種“DX”的誘餌和調包策略非常巧妙，但技術本身並沒有為任何人帶來好處，除了開發者。
難以接受，對吧？沒有人想被欺騙，承認沉沒成本也很難。如果你已經投入時間和精力在一個特定的技術和將其集成到你的技術棧中，那就更難了。開發工作流程很複雜，適應一個流程就像適應一個你打算住一段時間的房子一樣。但你應該知道，你的房子是不是建在Alex所說的“沙地基礎”上。
我想在此暫停一下，說明我對這場辯論沒有個人立場。作為一個Web通才，我傾向於儘早嘗試新工具以熟悉它們，然後迅速放棄，將它們放到我的工具箱裡，直到找到合適的用途。換句話說，我的知識面很廣，但在某個特定領域並不深入。 HTML、CSS和JavaScript是我的常用組合，但我非常重視用戶體驗，知道何時選擇合適的工具來解決特定問題。
而且，我們也要承認，並非每個人都能自主決定。我們許多人都在受管理的團隊工作，使用的工具是預先指定的。 Alex也提到了這一點，我認為這很重要，因為它清楚地表明這並非針對個人。這是一個關於我們優先級和確保它們與用戶期望相符的聲明。
讓我們讓Chris引導我們回到主題……
所以，也許你的應用程序是用React構建的，原因並不重要。仍然需要做一些工作來確保應用程序的可靠性和可訪問性。
只需阻止一個文件就不應該完全破壞一個網站，但它經常會這樣做！在JavaScript中，這可能是因為開發者編寫了依賴於第三方JavaScript（我通常會阻止）的第一方JavaScript（我通常會允許）。
[…]
如果我阻止來自tracking-website.com的資源，我的第一方JavaScript就會拋出錯誤。 JavaScript並不會忽略錯誤。如果拋出錯誤，它就不會執行文件中更靠下的JavaScript代碼。如果更靠下的代碼是transitionToOnboarding();——那就不會執行。
也許值得重新審視你的工作流程，並對其進行調整以識別更多故障點。
所以，這裡有一個想法：在安裝了流行的內容攔截器及其默認配置的瀏覽器中運行你的端到端測試。
這樣做可能會發現一些問題，這些問題會阻止你的客戶，以及那些需要幫助的人。
好主意！任何有助於更真實地描繪應用程序使用方式的方法都是好的。這種清晰度可以在流程的早期出現，也許在做出開發決策之前。了解你的用戶。他們為什麼要使用這個應用程序？他們如何瀏覽網頁？他們的地理位置在哪裡？什麼問題可能會妨礙他們？ Chris也對此有一個很好的演講。
以上是醫療保健，出售檸檬和開發人員體驗的價格的詳細內容。更多資訊請關注PHP中文網其他相關文章！
