急于开发Web的客户端

在过去的几个月中，我意识到Web开发中的客户端脚本令人兴奋。但是，尽管服务器端技术已经成熟，稳定并且为后端开发人员所接受，但是客户端技术还不成熟（即与大型服务器端框架相比），并且被许多历史悠久的开发人员所讨厌。然而，如今，每个人都在进行客户端开发。我个人希望大型服务器端框架在2-5年内消失，并关注当前趋势。

为什么会这样？用HTML5 / JS开发的新的和“分散的”客户端怎么可能优于大型且经过深思熟虑的服务器端解决方案？

这是真的：

急于开发Web的客户端

但是它不仅限于客户端，它是一个完整的堆栈运动。

我知道这可能令人惊讶。拜托，听我说。

为什么会这样？用HTML5 / JS开发的新的和“分散的”客户端怎么可能优于大型且经过深思熟虑的服务器端解决方案？

首先，两者都经过深思熟虑。

其次，因为它更好。

好问题。

但是“更好”是主观的，因此，您的问题的答案是：哪种更好？

重新查看问题：

用HTML5 / JS进行“分散”的客户端开发怎么可能优于大型服务器端的解决方案？

Because small is nimble.
And big is clunky.

这是灵活性。

似乎没什么大不了的。可以？灵活性。

但是，灵活性是一切的基础。灵活性方面的一项改进-全面改善。

可维护性。可扩展性。可扩展性。模块化。可用性。用户体验。

而且实施起来更快。这是现实。更快更好。

This is why Windows 8 made JS a first-class citizen.

HTML5-JS，不是时尚，它不会消失。我们只是看到了将增长为平板电脑提供计算内容和交互行为的技术的种子。平板电脑。

智能手机是自1950年代电视以来使用最快的大众媒体。现在，我们不仅拥有智能手机-我们还有平板电脑。

Mozilla和Windows已经在开发该操作系统，它将在其市场上的未来设备上运行-> HTML / JS。

仍然存在许多解决方案和创新。

基于灵活性，正在出现一堆完整的JS。

希望对您有所帮助。

这个故事总是有两个方面。服务器端和客户端代码都有其优缺点。

客户端脚本的优势包括：

• 可以使响应速度更快，无需服务器往返即可进行广泛的更改。
• 代码在客户端上运行，从而减少了服务器上的资源使用。
• 逻辑和表示之间的分离变得物理上的。
• 有时更容易实现负载平衡，尤其是在使用按请求身份验证的情况下。

但是服务器端脚本也有很多优点：

• 您可以控制运行代码的机器。
• 几乎一切皆有可能-如果您的服务器可以做到，那么脚本也可以。
• 用户无法在运行脚本之前对其进行修改。
• 用户不能使用脚本阻止程序阻止脚本运行。
• 用户看不到脚本的作用，只能观察输出。
• 该代码将与您可以想象的每个客户端可靠地协同工作，包括屏幕阅读器，文本Web浏览器，搜索引擎蜘蛛，抓取工具，累加器，IRC机器人，超低端计算机，脚本阻止的浏览器，随便您如何命名。
• 用户插件不太可能损坏。

对于高度动态的Web应用程序，以客户端为中心的方法一直是一种流行的选择，因为它是提供像桌面一样的响应式用户体验的唯一方法：如果没有客户端脚本，则用户的每一项操作都需要一轮回合。跳闸，这意味着至少延迟半秒，通常会更长。但是对于一个信息站点来说，该站点基本上只是一堆从数据库提供的静态页面（例如Wikipedia），其优势是微不足道的，而服务器端脚本的优势仍然是压倒性的。

观察到的炒作来自两个最新发展的组合：

1. HTML5及其相关技术的日冕。花费了太长时间，但是现在我们终于有了一个标准，其中包含制作这些动态桌面式Web应用程序而不堆积黑客的一切所需的一切，以及能够正确实现它们的主流浏览器。
2. 可用的处理能力。当今的商用台式PC的功能与入门级Web服务器一样强大，客户级手机实际上是2005年的台式计算机，现代javascript实现足以有效地实现性能平衡：到目前为止，客户端资源比服务器便宜资源。

实际上，就以服务器为中心和以客户端为中心的方法所擅长的方面而言，没有任何改变。改变的是，以客户为中心现在比以前更容易，更便宜并且性能更好，这使其成为比以前更多的应用程序的可行选择。

服务器端将始终存在。您不能坐在客户端上处理所有事情。例如，您不想为微控制器使用Backbone.js MVC设计，而是从生产车间桥式起重机实时向您发送参数。

不要相信炒作。

2009年，我已经从服务器端PHP框架切换到与服务器端Web服务绑定的客户端ExtJS解决方案。

我迁移的原因是：

1. 通过减少服务器上的端点和代码数量来提高安全性。
   通过使用Web服务，您可以验证Web服务边界上的输入，并可以更精确地控制服务器的I / O。没有服务器端UI层可以混淆您的安全体系结构。
2. 由于减少了服务器往返次数
   ，因此提高了性能。体系结构发生了变化，因此数据获取的发生频率可能​​降低，并且可以使用UI呈现在本地缓存数据，而根本不需要往返。往返是导致Web应用性能下降的原因。
3. 由于UI
   的可缓存性，因此提高了性能。UI层可以完全托管在CDN上。我什至通过将UI代码放入HTML5应用程序缓存中来构建脱机Web应用程序。
4. UI的保真度更高（丰富的客户端控件）
5. 第三方开发人员可以使用与我自己的前端使用的相同的API，并且如果他们共享功能，我可以轻松地跨模块重复使用API​​。
   这意味着更少的开发，质量检查，文档等。
6. 我更喜欢用JavaScript编程，而不是PHP，Python或Java

但是，毫无疑问，现在发生的是炒作。它将崩溃，许多Web应用程序将再次使用服务器端UI架构。

推动客户端解决方案热情的另一个因素是移动应用程序的增长。如果您主要基于客户端JavaScript和AJAX创建网站，并且还构建本机iOS和Android应用程序，那么这三个人很有可能可以使用相同的REST服务来处理所有数据。 。

首先，用户看不到（有时甚至不在乎）没有服务器的情况。不管服务器端代码编写得如何好，如果客户端部分做得不好，用户将不会欣赏该应用程序。有时，即使是漂亮的UI也比功能更重要。

大型而强大的服务器托管非常昂贵。在客户端实现某些逻辑（验证除外）会便宜得多。因此，您可以使用较小的（因此，更便宜的）服务器托管，因为它不会加载太多。

这些都是尽管不稳定的原因，客户端技术却越来越受欢迎的原因。此外，（几乎）所有现代浏览器都支持JS和HTML / CSS。

应用程序的这两部分不能分开存在。而且互联网在不久的将来似乎不会消失。
我也不认为这种big server-side frameworks可能性也不会消失。总会有一些公司负担得起，并会利用它们的显着优势。

客户端Web开发与Web浏览器以及随时间变化的浏览器紧密结合在一起。由于Web浏览器的页面呈现引擎发生了重大变化，因此您现在提供的解决方案可能在几个月内无法工作。某些浏览器与标准不兼容，因此为了获得预期的结果，开发人员需要付出更多的努力。

有一些解决方案试图解决此问题。例如，如果您使用jquery，则可以确保您的脚本将在此特定jquery库支持的浏览器上运行。但是，只有它的作者才能为您提供与某些/大多数/所有浏览器的兼容性。问题是哪个团队会更好地支持您。会是motools团队，jquery团队或其他团队吗？如果他们不提供对特定Web浏览器的支持，则您的项目可能无法在该浏览器中运行。

您似乎已经兴奋了很长时间。当引入Shockwave及其后续Flash时，我看到了它，一旦交付了复杂的js库，首先是使用motools，然后是jquery，我就开始经历了丰富的用户界面的“大逆转”（我开始以此顺序使用它们）。有Flex和JavaFX。但是它们都无法在市场上获得很大份额。有些要求使用及时将最终用户暴露给安全漏洞的插件，而有些则由于某些自定义设置（例如，在客户端浏览器中禁用了JavaScript）而无法在客户端上运行。

另一方面，服务器端解决方案通常只编写一次。您无需担心一切都会失败，并且在新的Firefox / Chrome / IE / Opera交付后就必须重写。您也不必担心客户端会尝试篡改您的应用程序和/或破坏数据。

完全同意您的观点。我还相信，除了您要说的以外，我们还将看到REST的大幅下降和websocket的大量增加，这是我们看到站点与服务器进行通信的主要方式。Vert.x，Node.js等。整个服务器端以及客户端都在转向事件驱动的编程。Java EE，PHP，Rails等。它们都需要适应，否则很快就会丢失。