构建更好Web客户端，Taylor Hughes讲述Skit框架背后的故事
程序员文章站
2022-05-16 09:12:12
...
【编者按】Taylor Hughes是LaunchKit的创建者之一，同时还创建过Cluster。本文讲诉了其与 Skit的故事，而题目也并不是真的在表达其写了一个JavaScript框架，而是一旦着手开始，就发现自己“爱上”了它。以下为译文：
背景
我大约与一年前开始着手这件事，那会我必须考虑所有的事情（这也让我开始对Web开发抓狂），并列举需要解决的问题。
起初我在想，也许有一天这件事将会很酷炫，而那时我会坐收其成。而现在我只需将其变得更现实就好了。
现在我每天都会去使用它，用它来建立每一个新的项目，并继续完善它。通常坏主意变成现实时会变得很糟糕，但是它成为现实时却没有，这是不是意味着它一开始就不是个坏主意呢？
请听我详细的讲述这件事，或许你也会心动。
一切由此开始
在2014年中旬，我工作于Cluster Web应用的第一个版本。logged-in web应用是由RequireJS、Mustache、jQuery和Django构建。它是个单一页面应用。
这个应用做了大量Web应用应该做的事情：
事实证明拥有许多小技巧和非凡配置集的Rube Goldberg machine是可以工作的。
随着时间的推移，我注意到了一些不好的事情发生了：
前端变得如此复杂，一切都太容易让人动怒。人们开始向我投诉，所以发生了什么？配置当道，部分服务和客户端渲染成巨大的上下文切换，将所有事物都包含在内。我想我还能做一些让构建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控制器子类和一个控制器。参考下图：
最后
写这篇文章并不是真的在表达我写了一个JavaScript框架，而是一旦着手开始，我就发现自己“爱上”了它。或许你可以去尝试一下。
Skit是什么？
Skit是一个JavaScript框架，通过下面这个生命周期控制器来创建Web页面：
执行如下：
自动，无需配置。
skit是由什么组成的？
Skit是为了什么？
Skit有利于在现有HTTP基础的API上构建Web应用，该应用类似于你可能已经为移动应用构建的那种。
Skit不是一个完整的框架，甚至不是一个典型意义上的“Node.js框架”。它更像一个能运行于服务器上的客户端框架。
Skit的特点
Skit是如何工作的？
点击此处查看原文大图
FAQ
我可以与一起使用它吗？
也许。如果你现有客户端框架是取决于DOM操纵来呈现的话，它将无法帮助你太多。这里有一个将React成功集成到项目的例子，点此查看。
背景
我大约与一年前开始着手这件事，那会我必须考虑所有的事情（这也让我开始对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控制器子类和一个控制器。参考下图：
最后
写这篇文章并不是真的在表达我写了一个JavaScript框架，而是一旦着手开始，我就发现自己“爱上”了它。或许你可以去尝试一下。
Skit是什么？
Skit是一个JavaScript框架，通过下面这个生命周期控制器来创建Web页面：
执行如下：
自动，无需配置。
skit是由什么组成的？
- 一个网络服务，用于在服务器上运行你的控制器，并在浏览器中通过same-ish状态自动设置它们；
- 一个模块系统，用于构建由模版、样式表和JavaScript共同组成的组件；
- 一组轻量级库，便于发出HTTP请求、管理cookies和处理服务器和客户端上的导航。
Skit是为了什么？
Skit有利于在现有HTTP基础的API上构建Web应用，该应用类似于你可能已经为移动应用构建的那种。
Skit不是一个完整的框架，甚至不是一个典型意义上的“Node.js框架”。它更像一个能运行于服务器上的客户端框架。
Skit的特点
- 共享客户/服务端代码
- 零配置
- 最佳模块
- SEO Natural Way™
Skit是如何工作的？
点击此处查看原文大图
FAQ
我可以与一起使用它吗？
也许。如果你现有客户端框架是取决于DOM操纵来呈现的话，它将无法帮助你太多。这里有一个将React成功集成到项目的例子，点此查看。
上一篇： 为Nutch 1.0添加JE中文分词
下一篇： 有一次出差去一个朋友所在的城市