作者丨Cal Paterson

編譯丨諾亞

Csvbase是一個托管表數據的網站。關于csvbase有一點不尋常的是，當我編寫它時，我沒有編寫任何 Javascript。

大多數我沒有寫的 Javascript 分為以下幾類：

我沒有編寫任何前端表單驗證。沒有必要——這些都可以通過 HTML5 來完成。

我沒有寫日期選擇器。再說一遍，HTML5。

圖片

過去需要花費數千行 Javascript 來完成此操作。現在瀏覽器會為你做這件事

我最喜歡的功能是，你可以直接將 MS-Excel 中的單元格粘貼到神奇的文本區域中，而 csvbase 會盡力找出它是什么并將其轉換為表格。再次強調：不涉及 JavaScript。實際上，在后端推斷數據類型、指定字符串編碼、檢測單元格分隔符等等要容易得多。

我的頁面上的HTML是由模板生成的，就像還是2005 年一樣。

表單multipart/form-encoding是用XHR（XMLHttpRequest）出現之前我的前輩所做的方式提交的。

當表單是“可編輯的”（即，你得到某種加號按鈕，可以動態添加另一個表單字段），我只需讓該加號按鈕添加一個查詢參數，并使用 HTTP GET 來獲取添加了該字段的表單的新版本（減號按鈕則相反）。同樣，HTML5 允許你為各個按鈕提供特殊的 “formaction”，并使這個技巧比以前更容易。

堅持己見的人會爭辯說，實際上我使用的 CSS 框架附帶了一個.js文件。這是真的——但那個文件不是我寫的。我都沒讀過。就我而言，它是完全封裝的。所以事實是：我沒有寫任何 JavaScript。

1、汽車和公共汽車

但何苦呢？如果你能做到，不寫JavaScript會讓你的生活更輕松，從而節省你的時間。

預測汽車可靠性的一種方法是通過零件的數量。零件數量較多的汽車往往可靠性較差，因為隨著汽車變得越來越復雜，出現問題的方式必然會越來越多。如果你確實有一個零件，最好不要是一個移動的零件。內飾件很少造成機械師的麻煩。然而，如果你的機械師提到你的變速箱 ，你將聽到非常壞的消息。在其他條件相同的情況下：零件越少越好。

將 Javascript 添加到任何項目中總是會帶來很多部分。幾乎所有的都是那種麻煩的移動類型。三年前，微軟的某人確定Github上的Javascript項目平均只有10個直接依賴項，但有683個間接依賴項(想想:庫X需要庫Y，需要庫Z……)。

大多數嚴肅的商業Javascript應用程序的數據要高得多。這可能是NPM (Javascript包管理器)需要風險投資的原因之一——解決Javascript構建依賴關系可能是我們目前可用的最尖端技術。

省略Javascript不僅更可靠，而且更簡單。與編寫糟糕的 React 所需的技能相比，模板HTML的技能集要小得多。當我過去從事專業的Web項目時，我經常發現前端開發所使用的技能的深度和環境令人難以置信。例如，你知道嗎，現在許多（甚至是基本的）Web 應用程序都包含一個完整的瀏覽器內事件總線？這是一種一開始聽起來肯定很瘋狂的事情，但可悲的是，隨著你了解得越多，它就開始變得更有意義。

最重要的好處之一是，不編寫 Javascript 會讓你的系統更容易測試。由于我的系統關注的是用戶端，一旦我將HTML寫入套接字，我就不需要為瀏覽器建模，只需要一個HTML解析器。因此，我的測試可以在 HTTP 級別上運行，并且由于速度相當快，我可以進行更多的“全系統”測試。目前，我有大約 360 個測試，其中大多數是通過 HTTP 客戶端進行測試。HTTP 是一個很好的抽象級別，因為你可以說，例如“給定一個用戶，當他發布此表單時，他會得到這種 HTML”。

整個測試套件的運行時間為 3.5 秒——沒有并行性。每次測試大約需要 10 毫秒。我應該提到的是，我沒有模擬數據庫。由于 csvbase 是一種 ORM，因此損失正確性不值得提高速度。有些查詢可能會變得相當復雜。

2、使用更多快捷方式，減少時間

所有這一切的結果是節省時間。有個老梗說，如果任何政府計劃失敗，那是因為預算不夠大（如果成功了，那也只能證明需要更多預算）。這個笑話在軟件項目中的類似之處當然是指時間而不是金錢。

制作一個可用的軟件需要花費大量的時間。你如何為你的業余項目騰出時間？

如今，有一個巨大且不斷增長的“生產力工業綜合體”——成千上萬的播客和博主建議如何重新組織你的生活，以節省時間，或者至少更有效地利用時間。說實話，我對他們從來沒有感到親近。

正如金錢不是大多數政府計劃的問題一樣，對于軟件項目來說，只有在其他領域出現問題時，時間才顯得重要。我一直認為，要讓某件事走出困境，與其說是超級高效和/或“有效”地完成，不如說是在任何合理的時間內找到使之成為可能的正確捷徑。

對于 csvbase，沒有 Javascript 前端是我完成任務的捷徑。這是眾多問題之一：csvbase 沒有后臺工作人員；JSON API 使用與 HTML 頁面相同的視圖處理程序，只是不是將對象渲染到 HTML 模板中，而是將其格式化為 JSON；我也使用（幾乎）同樣的技巧來服務CSV、XLSX 和 Parquet；我仔細設置了 HTTP 標頭，這樣我就可以利用 CDN 中內置的緩存層，而不是自己編寫任何緩存代碼。任何你真正能完成的副業項目都充斥著這些捷徑。

這并不是要貶低Facebook Reacts。它們有自己的一席之地，但專業程序員的職業風險是，如果你在日常工作中做了一些事情，那么你可以把你的技能帶回家并用它們來做你自己的項目。問題是你也把這種心態帶回家了。你的工作場所的標準做法可能比你能承受的勞動密集度高一個或兩個數量級，例如(就像我的情況)，你只能在你的孩子睡覺的時候才開始做這個項目。

3、PHP魔術引號里面有什么嗎？

我一直對為什么那么多成功的公司開始使用LAMP，特別是PHP很感興趣。

Wikipedia、Flickr、Facebook、Slack 和 Wordpress 最初都使用了 PHP。PHP 有何特點？我對 PHP 不太了解，但從表面來看，在我這個癡迷于走捷徑的人看來，PHP 絕對是在密謀提供捷徑。

嚴肅的項目會構建發行包(有點復雜，5MB)，docker(非常復雜，100-1000兆字節)或unikernel（誰知道有多復雜）。我甚至在小公司工作過，在那里，將代碼部署到生產環境是多個人的全職工作。

相比之下，許多PHP應用程序是由FTP客戶機直接復制到生產環境中的。

我所使用的HTML模板方法在今天正經的商業項目中也不常見。通常會構建 GraphQL API，然后通過前端 Javascript 使用/控制。但PHP更進一步：它不是將模板嵌入到編程語言中，而是將編程語言嵌入到模板中。它們是一回事。可以說，PHP只是一種模板語言。

我在上面提到過，令人沮喪的是，包管理可能是一個相當困難的問題。PHP現在有包管理器，但是，在黃金時代，人們只是簡單地將他們想要使用的文件復制到他們的項目中。（C 編程仍然以同樣的方式工作——為了體面，這種“技術”被稱為“vendoring”）。

這并不是說我認為 PHP 是某種潛在的理想語言。我沒有為 csvbase 編寫任何 PHP代碼。但我確實認為 PHP 文化中有些東西值得我們學習。捷徑很重要。創意的適應度函數之一是是否有人可以發布版本 1。

這意味著通過 FileZilla 進行部署有一個合適的規模：小型項目的規模。“小”是一個重要的尺度，因為雖然不是每個項目都會變大，但每個項目都是從小開始的。

參考鏈接：https://csvbase.com/blog/4