我已經開發 Web 應用程式很長時間了。很久以前了。您在該環境中的第一個 Web 應用程式 我在那些日子裡創造了這個詞 "Google" 當時還不是一個動詞，人們使用 Yahoo! 在網路上搜尋資訊。和漫步者。我用過 'om - 他們的搜尋範圍縮小了，而且不像 Yahoo! 那樣醜陋、超載的介面。
應用程式的開發，任何應用程序，不僅僅是網路應用程序，都是創造性的工作。不太可能有人會反對這種說法。創造力之美就像是科學知識的實踐—真理的標準。但如果科學實踐是客觀的並且基於測量，那麼美就是一個主觀的主題，取決於誰在看。所以我問自己，對我個人而言，什麼是一個漂亮的 Web 應用程式？
（KDPV 上的眼睛不是我的，而是女人的眼睛，但是，恕我直言，KDPV 上女人的眼睛比男人的更合適，因為它 - !)
以下是我自己的標準，即目前哪些 Web 應用程式可以被認為是美麗的。基於我個人經驗的非常主觀的陳述。也許對某些人來說，我對美麗的標準似乎是對醜陋的標準。不要驚訝，你只是有不同的經驗。
由於您已經進入剪輯階段，請謹慎發表評論。畢竟，如果你可以在文章中的內容對你來說看起來醜陋甚至醜陋時就停止閱讀，那麼我作為作者，就被迫閱讀所有評論。
棲息地
通訊協定
我甚至不知道是否值得單獨制定這個標準。 Web 應用程式存在於 Web 上，並且被迫遵守 Web 法律（協議）。網路上的主要協定有： и 。許多其他協定都是基於它們的，但對於 Web 應用程序，我認為最重要的是 （或者更確切地說，它的擴展 在基地 ）。也就是說，一個漂亮的Web 應用程式可以透過HTTPS/TLS（可選- 透過HTTP）獲得，而其他協定（LDAP、RPC、IMAP4、POP3、SMTP、FTP、NNTP 等）會因為每個附加支援而使其不那麼美觀協議。應用程式本身可以透過這些附加協定來使用外部資源。
至於 ，那麼我沒有足夠的經驗在 Web 應用程式中使用此協定。它看起來很漂亮，很有前途，但我不能說它有多穩定和實用。
瀏覽器
Web 應用程式只有一隻腳在伺服器端，另一隻腳在客戶端。客戶端是瀏覽器。現代瀏覽器提供 ，現代 Web 應用程式可以而且應該利用它來發揮其優勢。漂亮的 Web 應用程式使用現代瀏覽器功能，並且不需要在不提供現代功能的瀏覽器中運作。我明白 ——這是必要的措施，但它很醜。最後，不僅開發人員必須跟上現代技術，這也適用於使用者和企業。
雅普
對於用於創建 Web 應用程式的程式語言，一切都非常令人困惑。對於 Web 應用程式的用戶端，有許多技術可以讓開發人員輕鬆建立 HTML/CSS/JS 三元組（所有現代瀏覽器都可以理解）。但有一次我近距離接觸到 我認為當開發人員在瀏覽器中看到原始程式碼而不是編譯或轉譯的結果時，這是很美妙的。因此使用 '恕我直言，用於產生客戶端程式碼的類似產品都很醜。在瀏覽器中運行的程式碼與開發人員創建的原始程式碼越相似越好。不相信我？嘗試在生產中調試 GWT 產生的程式碼。
伺服器端有更多的自由（Java、PHP、perl、python、C#、Ruby...），但在我看來，在伺服器端和應用程式中使用相同的程式語言是很美妙的。 JavaScript。仍然 ，由志同道合的人組成的團隊生產力更高。
人類
一個漂亮的網頁應用程式應該是有用的。首先，對於作為最終消費者的人類是有用的。因此，我不能稱其為漂亮的 Web 應用程式 。對於普通人（不是網頁開發人員）來說，與他們合作是很困難的。 Web 服務以其自己的方式美麗，
一個漂亮的 Web 應用程式應該有一個直覺的介面。人們可以爭論 這是一件相當主觀的事。鼻子 如果用戶在沒有珍惜的情況下無法使用該應用程序，那麼一切都會變得簡單得多 - 糟糕的用戶體驗，醜陋的網路應用程式。與此標準相關的最漂亮的網路應用程式可以被還不知道如何閱讀的孩子輕鬆使用。
逆可擴展性
曾幾何時，程式可以在軟碟上傳輸，現在可以在隨身碟上傳輸或立即從網路下載。複製常規應用程式並在另一台電腦上運行它是一項微不足道的任務。 Web 應用程式的情況有些特殊。網路是一個全域環境，無需克隆同一 Web 應用程式。在網路上，一個 Facebook、Twitter、Instagram、Mail.ru 或 Yandex 就足夠了。您可以在同一主題領域擁有不同的 Web 應用程序，但針對不同的受眾（例如 Facebook 和 Vkontakte、Mail.ru 和 Gmail、Google 地圖和 Azure 地圖）。需要硬體資源來確保此類 Web 應用程式的全球可用性，比方說， .
作為一名開發人員，我從未使用過這種級別的 Web 應用程序，也不知道它們內部是如何運作的。為了確保此類 Web 應用程式的功能，需要相關專家團隊和獨立的資料中心。我欽佩人們進行如此大規模的協作並創造出這樣的產品的能力，但我的美學標準是可以在單獨的筆記型電腦上運行的 Web 應用程式。
一個漂亮的 Web 應用程式不僅可以向上和向外擴展（對於使用者），還可以向下和向內擴展（對於開發人員）。
“兩棲性”
要存取現代 Web 應用程序，需要使用兩種類型的設備：
- 計算機（筆記型電腦、桌上型電腦）；
- 行動裝置（智慧型手機和平板電腦）；
地平線上的某個地方隱約可見“「但現在就這樣了。
電腦與行動裝置的不同，就像陸地生物與水禽的不同。這些是不同的環境，它們對生活在其中的生物（程序）提出了不同的要求。美麗的 Web 應用程式並不是那些看起來像的應用程序 ，水中的如魚，陸地上的如動物，空中的（) - 像鳥一樣。
我覺得它很醜”「，這就像試圖坐在兩把（SEO - 三把）椅子上。更像《史瑞克》裡的菲歐娜——白天一個，晚上另一個。是的，更貴。但更好。
交叉共享
我已經在「反向可擴展性」段落中指出，網路的全球化使得每個星球擁有一個 Web 應用程式成為可能。因此，每個 Web 應用程式都必須與其他應用程式至少有所不同，才能確保其生存。然而，我多年的經驗 （建立電子商務商店的框架）表示，各個 Web 應用程式之間的相似之處可能多於差異。優秀的 Web 應用程式不僅應該是模組化的，還應該與其他 Web 應用程式共用其模組。這個想法在某種程度上體現在 JSR 168 和 JSR 286 以及諸如此類的框架 , 和 Magento在我看來，Web應用程式使用的模組越多，它就越美觀。跨平台共享能夠創造更高品質的模組，從而打造更穩定的Web應用程式。
我所說的模組並不是指像 jQuery 或 RequireJS 這樣的函式庫 - 而是更大的實體，例如插件 и 。但對於圖書館來說，這個論點也是正確的，即圖書館的廣泛分佈使其變得更好、更永續成為可能。
哈佛建築
，與目前的裁決球不同 ，意味著程式碼和資料的分離。這個架構並沒有成功，但這個想法本身對我個人來說似乎很漂亮。特別是對於網頁應用程式。任何靜態（HTML/CSS/JS/Images/...）都是程式碼。它可以而且應該緩存在伺服器端或客戶端。數據是 / （美麗）或 / （稍微不太漂亮）。或WebSockets/JSON（可能是最好的選擇，但我還沒嘗試過）。
本土化
在開發 Web 應用程式時，我特別關心兩件事 - 多語言介面和時區。我來自拉脫維亞，我們使用三種語言：LV、RU、EN。一個漂亮的Web應用程式不僅應該允許您在應用程式本身中使用多種語言，還應該允許您使用外部資源來擴展使用的語言數量，例如 。對於組裝 Web 應用程式的模組也是如此。
對於時區，一切都很簡單，在所有情況下，當不清楚如何處理日期時間時，請執行以下操作：伺服器上的所有內容都會發送到伺服器並來自伺服器 - UTC，客戶端上顯示的所有內容-根據使用者個人資料中的時區。很美麗。
鍛造而不是死星
很久以前，每個大城鎮都有自己的熔爐。也許並不孤單。有些更好，有些更差。其中有世界聞名的鐵匠，也有因為別無選擇而來到這裡的鐵匠。有戰爭、流行病和天災。有些城鎮隨著人口一起消失。但鐵匠的手藝仍然存在。在消失的城市的地方，新的城市被建造起來，其中也出現了鍛造廠。
現在來看看這樣的服務 。當根伺服器發生故障時， .
在我看來，一個漂亮的 Web 應用程式不可能像 Facebook 或 Mail.ru 那麼大。這已經接近“「無論是建立所需的資源，或是維持可操作性所需的資源。是的，如果Facebook被摧毀，人類不會消失；它的功能很快就會被其他應用程式接管（同樣） 在俄羅斯聯邦境內及週邊地區，Instagram，Twitter，...）。然而，將地球上很大一部分人口鎖定在一個應用程式上並不是一件好事。此外，考慮到更永續的替代品的可用性（例如 ).
總結
如果您讀到最後並且感到困惑 - “那是什麼？「那麼我向你表示誠摯的同情。我沒有強迫你讀這篇文章。我只是試著將我的想法用語言表達出來，以找到其他有相同想法的人。也許我可以與他們討論創建漂亮的 Web 應用程式的一些方面，並找到我的問題的答案。我有很多。
謝謝閱讀。
來源： www.habr.com
