糖饼
art-template 内置两种模板语法，目前它们的界定符是不能直接输出的（后续可能会支持）。目前可以通过自定义解析规则来输出界定符，避免被解析。 ```js template.defaults.rules.unshift({ test: /{{raw}}([\w\W]*?){{/raw}}/, use: function(match, code) { return {output: 'raw', code: JSON.stringify(code)} } }); ``` 例如： ``` {{raw}} {{value}} {{/raw}} ``` 输出： ``` {{value}} ``` 同样，如果前后端的模板混合在一个页面中，也可以使用此方式避免前端模板被后端解析。
前端技术日新月异，前端字符串模板引擎已经逐步被 DOM 模板引擎所取代，以至于 art-template 一度停止维护。 现在，art-template 重新回归，带来了全新的 v4 版本。v4 对 NodeJS 进行了更好的支持，并且拥有领先的渲染性能，同时带来了全家桶：[express-art-template](https://github.com/aui/express-art-template) 与 [koa-art-template](https://github.com/aui/koa-art-template)。 对于浏览器端，[email protected] 带来了基于 WebPack 的 [art-template-loader](https://github.com/aui/art-template-loader)，它能更好的支持预编译，生成非常简洁的代码用于浏览器端使用，它完全可取代年久失修的 TmodJS。 art-template@4 主要特性： ## 高速渲染 毫无疑问，它依然保持了过去的成绩，并且编码函数 `$escape()` 是过去的 4 倍速度。 [](https://aui.github.io/art-template/example/web-test-speed/)...
 字蛛是一个 WebFont 智能压缩工具，它能自动化分析页面中所使用的 WebFont 并进行按需压缩，通常好几 MB 的中文字体可以被压缩成几 KB 大小。 字蛛主页：http://font-spider.org 字蛛从 2014 年 7 月诞生以来，时隔近两年，终于发布了 v1.0.0 正式版本，改进如下： 1. 支持绝大多数的中英文 Truetype 字体 2. 支持开源图标字体库 （New: v1.0.0新特性） 3. 支持 CSS 伪元素解析，支持...
除了中文字体，日本、韩国字体文件都非常巨大，也意味他们使用 WebFont 和中文一样面临挑战，所以现征集翻译志愿者来翻译 README 文档，一起为 WebFont 的推广贡献自己的力量！ 可以参考这一份简化的中文 README 文档进行翻译：[font-spider.md.txt](https://github.com/aui/font-spider/files/233228/font-spider.md.txt)
开发计划
1. [ ] 支持使用 otf 作为源文件压缩 2. [ ] CDN 动态写入解决方案 3. [x] 去掉 Perl 库，使用 fontmin 作为压缩模块 #18 4. [x] CSS 语法容错处理 5. [x] 支持映射 CSS 内部 http 路径到本地...
三年前，有一个设计师面试一位 Web 前端工程师，其中有一段这样的对话： “如果设计师希望用图片实现某个字体样式，而从技术的角度来说这样不合理，但设计师非常坚持，这时候你怎么办？” “我会给设计师讲解工程上面临的问题，争取他理解。例如：如果文本使用图片，以腾讯站点的访问量来说，这里会需要消耗大量的服务器资源，至少需要增加 XXX 台服务器，带宽流量消耗 XXX 万……”。 这是一段真实的面试场景，而我就是那位被面试者。这些年 Web 前端技术在迅猛的发展，这样的问题已经有了解决方案——WebFont，如果再回到当年面试的场景，我想我会给出更好的答案。 WebFont 技术可以让网页使用在线字体，而无需使用图片，从而有机会解决开头设计师提到的问题。它通过 CSS 的 `@font-face` 语句引入在线字体，使用 CSS 选择器指定运用字体的文本。在国外，WebFont 已经非常流行了，大量的网站使用了 WebFont 技术，而业界大佬 Google 也顺势推出的免费 WebFont 云托管服务，这一切甚至带动了国外字体制作行业的高速发展。 ## WebFont 的优势...
为了提高解决问题的效率，这里只接受有价值的问题： 1. 提 Issue 时请附带重现 Demo，否则将直接关闭 2. 标题请简短，把内容写在 Issue 内容中，否则直接关闭 3. 咨询使用问题将直接被关闭，文档有问题欢迎提出建议
近两年由于技术的发展，Web 前端可以通过编译工具来实现 HTML、CSS、JS 所做不到的事情，从而覆盖更多的业务，从技术角度实现更多的价值。社区也在不断的创造更好的编译、构建工具，例如目前大红大紫的 Webpack。正因为这些先进的工具，我们工作效率得到了前所未有的提升。当然，我们也需要面对它们所带来的一些问题：构建速度越来越慢，导致发布速度越来越慢。尤其是在使用持续集成系统来构建的项目中，这个问题越严重。 解决构建慢的问题有很多途径，比如常见的手段是优化构建工具的配置，网上也有很多这样的实践经验文章，这些优化手段大多都是针对具体的工具、本地开发构建进行的，如果使用持续集成服务器进行构建，社区缺乏一些简单可靠增量构建解决方案。针对于此，我给大家分享我们前端团队（厦门欢乐逛）的实践成果：**基于 Git、Svn 的 Commit 实现可增量构建的前端持续集成解决方案**。 ## 背景 大约是 2014 年的时候，我们在 Git 服务器上通过 Githooks 、Grunt 实现了一个复杂的前端增量构建系统：提交代码到对应分支后服务器会自动进行增量构建、增量发布。这套系统这在当时看来自动化程度已经很高了，解决了本地构建、发布所带来的效率以及安全风险，版本发布非常快速。当时前端团队的构建与发布流程： 1. 代码提交到开发分支：自动构建 2. 代码提交到主干分支：自动发布 2014 ～ 2017 年之间，我们业务飞速发展，前端项目越来越多，构建这一块也被更先进的 Gulp 与...
Thank you very much for this library, it makes my router program elegant! I've discovered that URLPattern doesn't work according to web standards when the pathname contains the leading `//`...