<b>本文讲的是为什么我们要用网页端组件去构建服务器？该怎么做？，</b>
Web components（网页组件）用在服务器端渲染早已被大家所了解，在本文中，我想谈及的是：你还可以用 web components 构建服务器端应用。
声明式
模块化
通用化
可共享
可调试
更平缓的学习曲线
客户端结构
现在你可以使用 HTML 语法来声明路由了。比起纯 JavaScript 语法，现在的路由可以体现出视觉层次感，看起来更加形象和易于理解。拿上面的例子来说，所有和 Express 框架有关的 endpoints(路由) / middleware(中间件) 都嵌套在 <code><express-app></code> 元素，连接 app 的中间件按顺序放在 <code><express-middleware></code> 元素中。而路由也可以很容易地嵌套，<code><express-router></code> 中包含的每个中间件都会连接到 router，你还可以把 <code><express-route></code> 放在 <code><express-router></code> 元素中。
<code>index.html</code> 是入口文件，实际上我们需要关心的地方只有一个，就是 <code><na-app></na-app></code> ：
我们启动 Express 应用，监听 port <code>8080</code> 或者 <code>process.env.PORT</code> 端口，然后定义了三个中间件和一个自定义元素。希望你直觉上就能理解那三个中间件会在<code><na-api></na-api></code> 之前运行的工作原理：
所有 <code><na-api></na-api></code> 的内容都包裹在 <code><express-router></express-router></code> 当中。组件里的所有中间件都在访问 <code>/api</code> 时生效。接下来再看看 <code><na-bears></na-bears></code> 和 <code><na-bears-id></na-bears-id></code>：
如你所见，所有路由都被分离到各自的组件中，并且要包含在 app 中也很容易。在 <code>index.html</code> 文件中的 import 引入方法非常浅显易懂，
我喜欢 JavaScript 的原因之一，就是可以在客户端和服务器端共享代码。虽然现在某种程度上可以说这是可行的，但实际上，由于某些 API 的缺失，依然有一部分客户端的库不能在服务器端工作，反之亦然。从根本上说，Node.js 和浏览器依然是提供不同 API 的两套环境。那有什么办法可以结合呢？我们想到了 Electron，Electron 把 Node.js 和 Chromium 项目结合成为一个单独的运行环境，使得客户端代码和服务端代码结合运行成为了可能。
我只需要导入这个库，无需任何代码改动，就顺利在服务端运行起来了！
Electron 和 Scram.js 提供了 LocalStorage, Web SQL 和 IndexedDB，使得 localForage 成为了可能。我们就这样搭建起了一个简单的服务器端数据库！
虽然我不确定怎样测量其性能，但至少这个方法是可行的。
这点完全得益于 web components，因为 web components 的其中一个主要目标就是使得组件易于共享，实现跨浏览器通用，并停止在同一个问题上因为框架或者库的改变而不断重复实现。共享之所以变得可能，是因为 web components 基于现有的或者提出的标准，所有主流浏览器的厂商都会想办法去实现。
这意味着 web components 不依赖于任何框架或者库，就可以在任何 web 平台上通用。
我希望有更多人能参与到创建服务器端 web components 的创建当中，并把各种功能打包成组件，就像前端组件那样。我从 Express components 开始了这项工作，但我还期待看到 Koa, Hapi.js, Socket.io, MongoDB 等组件的出现。
Scram.js 有一个 <code>-d</code> 选项，让你可以在调试时打开 Electron 窗口。现在你可以使用 Chrome 开发者工具的所有功能来帮助你调试服务器了。断点、控制台日志、网络信息等都可以在里面看到。Node.js 的服务端调试似乎总是我的第二选择，但现在它的确已经集成到了平台中：
服务端 web components 对降低后端编程学习难度有帮助。要知道有很多 web 设计师、交互设计和其他一些只懂 HTML 和 CSS 的人希望学习服务端开发，但现有的服务器端代码对于他们而言很难理解。然而，如果使用他们熟悉的 HTML 来编写，特别是用上语义化的自定义元素，他们就能更容易地上手服务器端编程了。至少我们可以降低他们的学习曲线吧。
客户端和服务端 app 的架构正变得越来越像了。每个 app 以 <code>index.html</code> 文件开始，然后引入相关组件。这只是一种新的统一前后端的方法。在过去，我觉得想要找到服务器端应用的入口多少有点困难，如果后端能像前端应用一样，以 <code>index.html</code> 作为标准的入口，不是挺好的吗？
以下是使用 web components 构建的客户端应用的一般结构：
以下是使用 web components 构建的服务端应用的一般结构：
这两种结构应该都可以很好地工作，现在我们成功减少了从客户端到服务端切换的上下文数量，反之亦然。
Electron 在服务器生产环境中的性能和稳定性，是最有可能导致应用崩溃的原因。话虽这么说，我并不觉得性能在将来是一个大问题，因为 Electron 只是通过一个渲染进程运行 Node.js 代码，我猜想和原生 Node.js 的运行状况差不多。最大问题是，Chromium 的运行时能否足够稳定，坚持运行足够长时间（而不发生内存泄露）。
另一个潜在问题是冗余性，相比原生 JavaScript 逻辑，使用服务端 web components 完成相同任务会花费更多时间，因为标记语言需要解析。话虽这么说，我依然希望付出冗余的代价，能换来更容易理解的代码。
在本地机器上运行
每秒递增 100 次 GET 请求
运行直到有 1% 的请求返回不成功
对于 Node.js app 和 Electron/Scram.js app 版本，分别运行 10 次测试
Node.js app
使用 Node.js v6.0.0 版本
使用 Express v4.10.1 版本
Electron/Scram.js app
使用 Scram.js v0.2.2 版本
默认设置（从本地服务器加载起始 html 文件）
调试窗口关闭
使用 electron-prebuilt v1.2.1 版本
运行命令: <code>nab http://localhost:3000 --increase 100 --verbose</code>
以下是结果 （QPS: Queries Per Second 每秒查询数）：
出乎意料，Electron/Scram.js 比 Node.js 性能更佳。我们对这个结果持保留意见，但起码还是能反映出使用 Electron 作为服务器的性能不会比 Node.js 差很远，至少在短期内处理原始请求的效果是如此。还记得我之前说过“我并不觉得性能在将来是一个大问题”吗？结果证实了我的描述。
Web components 很好很强大，给 Web 平台带来了标准化、声明式的组件模型。Web components 不仅能给客户端带来便利，而且在服务端也获益良多。客户端和服务端之间的差距正在缩小，我相信服务器端 web components 是正确方向上的一大迈进。因此，一起来使用它们构建我们的应用吧！
<b></b>
<b>原文发布时间为：2016年08月02日</b>
<b>本文来自云栖社区合作伙伴掘金，了解相关信息可以关注掘金网站。</b>