我已经开发Web应用程序很长时间了。 很长的时间。 我当时在Lotus Domino环境中创建了第一个Web应用程序，当时单词“ google”还不是动词，人们使用Yahoo!。 和漫步者。 我使用了Infoseek-他们的搜索范围越来越小 ，而且界面也不像Yahoo!这样丑陋！

开发应用程序，不仅是针对Web的任何应用程序，都是一项创造性的工作。 任何人都不太可能会对此声明提出异议。 创造力之美就像科学知识的实践-真理的标准。 但是，如果科学实践是客观的并且基于测量，那么美是一个主观的主题，它取决于谁在看。 所以我想知道，但是对我个人而言，什么是美丽的Web应用程序？

（KDPV上的眼睛不是我的眼睛，而是女性的眼睛，恕我直言，KDPV上的女性眼睛比男性的眼睛更合适，因为这是KDPV ！）

根据削减，我自己的标准可以使Web应用程序目前被认为是美观的。 由于我的亲身经历，所以非常主观。 也许有人会把我的美容标准视为丑陋的标准。 不要惊讶，您只是拥有不同的经历。

既然您已被削减，请谨慎发表评论。 毕竟，如果您对这篇文章中所提到的内容感到丑陋甚至丑陋，可以立即停止阅读其文章，那么作为作者的我必须阅读所有评论。

生境

通讯协定

我什至不知道这个标准是否应该分开考虑。 Web应用程序存在于Web上，并被迫遵守Web法律（协议）。 Web上的主要协议是TCP和IP 。 许多其他协议都基于它们，但是对于Web应用程序，我认为HTTP是最重要的协议（或者更确切地说，它是基于TLS的HTTPS扩展）。 也就是说，可以通过HTTPS / TLS（作为选项-通过HTTP）获得漂亮的Web应用程序，而其他协议（LDAP，RPC，IMAP4，POP3，SMTP，FTP，NNTP等）则使它们变得不那么美观可选支持的协议。 应用程序本身可以使用这些附加协议来使用外部资源。

至于WebSocket ，我没有足够的经验将此协议用于Web应用程序。 它看起来很漂亮而且很有前途，但是我不能说它多么稳定和实用。

浏览器

Web应用程序只有一只脚站在服务器端，另一只脚站在客户端。 客户端是浏览器。 现代浏览器提供了许多现代Web应用程序可以并且应该利用的功能。 美丽的Web应用程序使用浏览器的现代功能，并且不需要在不提供现代功能的浏览器中工作。 我知道，多亲是必要的措施，但这很丑陋。 最后，不仅开发人员应该跟上现代技术的步伐，用户和业务也将受到影响。

YaP

使用用于创建Web应用程序的编程语言，一切都很混乱。 Web应用程序的客户端有大量技术，使开发人员可以方便地创建HTML / CSS / JS三元组（所有现代浏览器都可以理解的东西）。 但是我曾经与GWT保持密切联系，并认为当开发人员在浏览器中看到原始代码而不是编译或转译的结果时，它非常漂亮。 因此，使用webpack和类似产品生成客户端代码恕我直言是很难的。 在浏览器中执行的代码越类似于开发人员创建的源代码，效果越好。 不信？ 尝试在生产中转移GWT创建的代码。

服务器端（Java，PHP，perl，python，C＃，Ruby等）具有更大的自由度，但是在我看来，当服务器端和浏览器都使用一种编程语言-JavaScript时，它是美丽的。 尽管如此， 语言决定了思维 ，志趣相投的团队生产力更高。

人性化

美丽的Web应用程序将很有用。 首先对最终用户有用。 因此，我不能称Web服务为漂亮的Web应用程序。 对于普通人（不是网络开发人员）来说，这样做很难。 Web服务以其自身的方式是美丽的，

美丽的Web应用程序应具有直观的界面。 您可以争论UI的问题-这是相当主观的事情。 但是对于UX，如果用户在没有令人垂涎的RTFM的情况下无法使用该应用程序，那么一切都会变得更加简单-一个糟糕的UX，一个丑陋的Web应用程序。 仍无法阅读的儿童可以轻松使用有关此标准的最精美的Web应用程序。

反向可伸缩性

从前，程序可以在软盘上传输，现在可以在闪存驱动器上传输，也可以立即从Web下载。 复制常规应用程序并在另一台计算机上运行是一项微不足道的任务。 对于Web应用程序，情况有些特殊。 网络是一个全局环境，在其中不需要具有相同Web应用程序的克隆。 Web上仅一个Facebook，Twitter，Instagram，Mail.ru或Yandex就足够了。 您可以在相同的主题利基市场中拥有不同的Web应用程序，但拥有不同的受众群体（例如Facebook和Vkontakte，Mail.ru和Gmail，Google Maps和Azure Maps）。 硬件资源可以确保此类Web应用程序的全球可用性，这是不平凡的 。

我从未使用过像开发人员这样水平的Web应用程序，而且我无法想象它们在内部的排列方式。 为了确保此类Web应用程序的可操作性，需要相关专家团队和单独的数据中心。 我很欣赏人们在如此规模上合作并创建类似产品的能力，但是我的美丽标准是可以在单独的笔记本电脑上运行的Web应用程序。

一个漂亮的Web应用程序不仅可以（在用户范围内）扩大规模，而且可以在（对于开发人员）范围内扩大规模。

“两栖”

两种类型的设备用于访问现代Web应用程序：

• 计算机（笔记本电脑，台式机）；
• 移动设备（智能手机和平板电脑）；

地平线上某个地方隐约可见另一种“ 物联网 ”，但到目前为止。

来自移动设备的计算机与陆地生物与水禽的差异一样大。 这些是不同的环境，它们对其中生活的生物（程序）有不同的要求。 美丽的Web应用程序不是看起来像两栖动物的应用程序，而是像鱼一样在水中，像动物一样在陆地上以及像鸟一样在空中（ SEO ）的应用程序。

我认为丑陋的两栖动物丑陋，就像试图坐在两把（带SEO-三把）椅子上一样。 像史瑞克的菲奥娜一样好-白天一个，晚上另一个。 是的，更贵。 但是更好。

交叉共享

我已经在“反向可伸缩性”段落中指出，网络的全球性使得在Planet上拥有一个Web应用程序成为可能。 因此，每个Web应用程序必须至少与其他Web应用程序有所不同，以确保其生存。 但是，我在Magento （建立电子商务商店的框架）方面的多年经验表明，各个Web应用程序之间可能有更多的共同点，而没有差异。 漂亮的Web应用程序不仅应模块化，还应与其他Web应用程序共享其模块。 在某种程度上，这个想法反映在JSR 168和JSR 286的规范以及诸如WordPress ， Django和同一个Magento的框架中。 从我的角度来看，其他Web应用程序使用的Web应用程序模块数量越多，它就越美观。 交叉共享使您可以创建更好的模块，从而创建更稳定的Web应用程序。

就模块而言，我并不是说像jQuery或RequireJS之类的库，而是更大的形式，如WordPress和Django中的插件。 但是对于图书馆来说，广泛分布的图书馆可以使我们变得更好，更稳定的观点也是正确的。

哈佛建筑

与当前的普林斯顿大学不同， 哈佛架构涉及代码和数据的分离。 架构并没有成功，但是这个主意在我看来似乎很美。 特别是对于Web应用程序。 任何静态内容（HTML / CSS / JS /图像/ ...）都是代码。 它可以并且应该至少在服务器端，至少在客户端缓存。 数据是REST / JSON （漂亮）或SOAP / XML （漂亮一点）。 或WebSockets / JSON（也许是最好的选择，但我没有尝试过）。

本地化

开发Web应用程序时，我特别关心两件事-这是一个多语言界面和时区。 我本人来自拉脱维亚，我们使用三种语言：LV，RU，EN。 精美的Web应用程序不仅应提供机会在应用程序本身中使用多种语言，还应提供扩展与外部资源（例如Crowdin）一起使用的语言的数量的机会 。 从中构建Web应用程序的模块也是如此。

时区的一切都很简单，在所有情况下，如果不清楚如何处理日期时间，请执行以下操作：服务器上的所有内容都将转到服务器并来自服务器（UTC，客户端上显示的所有内容），具体取决于时区用户个人资料。 好漂亮

锻造而不是死亡之星

从前，每个或多或少的大城镇都有自己的伪造。 也许不是一个。 有些更好，有些更糟。 全世界都知道铁匠师傅，有些人是无可替代的。 战争，流行病，自然灾害席卷了整个世界。 一些城镇和人口消失了。 但是锻造仍然活着。 取代了消失的城市，建立了新的城市，并在其中出现了伪造。

现在看一下DNS之类的服务。 当根服务器瘫痪时， 整个世界都在发烧 。

我认为，漂亮的Web应用程序不能像Facebook或Mail.ru一样大。 无论是在建设所需的资源还是在保持可操作性所需的资源上，它都更接近死亡之星 。 是的，如果Facebook被破坏，人类将不会消失，其功能将很快被其他应用程序取代（俄罗斯联邦中相同的VK以及与之相邻的Instagram，Twitter，...）。 然而，将地球上很大一部分人口锁定在一个应用程序中是丑陋的。 而且，在存在更稳定的替代方案（例如torrent ）的情况下。

总结

如果您读到最后并感到困惑-“ 那是什么？ ”，那么我向您表达我的真诚同情。 我没有让你读这个。 我只是想将自己的想法表达出来，以找到那些想法相同的人。 也许我可以与他们讨论创建漂亮的Web应用程序的某些方面，并找出问题的答案。 我有很多。

感谢您的阅读。