构建更好Web客户端，Taylor Hughes讲述Skit框架背后的故事

0顶
0踩

2015-04-10 10:51 by 副主编 mengyidan1988 评论(1) 有4566人浏览

Taylor Hughes Skit 框架 React

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

【编者按】Taylor Hughes是LaunchKit的创建者之一，同时还创建过Cluster。本文讲诉了其与 Skit的故事，而题目也并不是真的在表达其写了一个JavaScript框架，而是一旦着手开始，就发现自己“爱上”了它。以下为译文：

背景

我大约与一年前开始着手这件事，那会我必须考虑所有的事情（这也让我开始对Web开发抓狂），并列举需要解决的问题。

起初我在想，也许有一天这件事将会很酷炫，而那时我会坐收其成。而现在我只需将其变得更现实就好了。

现在我每天都会去使用它，用它来建立每一个新的项目，并继续完善它。通常坏主意变成现实时会变得很糟糕，但是它成为现实时却没有，这是不是意味着它一开始就不是个坏主意呢？

请听我详细的讲述这件事，或许你也会心动。
一切由此开始

在2014年中旬，我工作于Cluster Web应用的第一个版本。logged-in web应用是由RequireJS、Mustache、jQuery和Django构建。它是个单一页面应用。

这个应用做了大量Web应用应该做的事情：

服务最佳化、版本化JavaScript和CSS软件集（来自Cloudfront的产品）
针对Facebook、Twitter和Google，我在页面中呈现各种类型的真实元数据。
在服务器上预渲染一些“一屏显示”的内容，其余部分则放在了客户端。所以用户在页面加载时不会看到一个完全空白的页面。
将服务器上加载下来的数据传递到客户端以作为JSON，这样后续的客户端渲染会立即生效。
……

事实证明拥有许多小技巧和非凡配置集的Rube Goldberg machine是可以工作的。

随着时间的推移，我注意到了一些不好的事情发生了：

引用

最终Web页面变得复杂和笨重，而这是我一开始所极力避免的。

前端变得如此复杂，一切都太容易让人动怒。人们开始向我投诉，所以发生了什么？配置当道，部分服务和客户端渲染成巨大的上下文切换，将所有事物都包含在内。我想我还能做一些让构建Web前端变得简单和有趣的事情吗？

“不讨厌”的前端Web开发是什么样的？

这是我所能想到的样子：

零配置
自动包含相关样式
自动资源编辑
服务端引导

它始终是同构的

解决这种东西需要一系列服务端工作，所以这不仅仅是客户端JavaScript框架的范畴了。

举个例子来说，它需要知道产品是如何绑定和优化客户端文件并在开发模式中如何各自的包含个体的、不可缓存的JavaScript文件集。同时还要以类似的方式处理CSS和软件集，并自动的包括那些对应于我们加载的JavaScript模块。

此外，如果我们想要摆脱配置来引导页面，则需要放弃控制服务端完全呈现。这样的框架最终会是一个整体类，而不是一个“可插拔的库”——没有配置，它需要大量的结构和协定。

最终呈现的是一个 client-side framework，然后就是一个处理HTTP请求的server-side runtime，之后让所有东西都可以运行于一个浏览器里的。

Hello world

Skit，一个充当纯API客户端构建网站的客户/服务端JavaScript框架，

一个Skit应用的代码库是一个单一的代码库，共享相同需求的JavaScript模块、模版等（从服务端到客户端）。代码通过Node.js中的Skit运行时被执行，随后在浏览器中显示出来。

Skit的工作方式是通过抽象化页面生命周期来跨过页面加载障碍。你为一个页面编写单一的控制来操纵加载服务器上的数据，在HTML中呈现数据并与一个浏览器中的DOM挂钩，而所有的这些都在同一个文件里。

数据加载和渲染步骤最初发生于服务器端，然后控制器以same-ish状态自动具体化于客户端。这听上去有点不可思议，不过实际上它是不错的。

Skit中每一个URL路径都对应于一个单一的skit控制器子类和一个控制器。参考下图：