前后端分离不是目标，而是一类解决方案。如果你的目标是降低总体开发成本，那么前后端应该统一规划全局数据定义，而不应该是单点的数据 API 模式。
第一次做项目是 2005 年底，由于前期学过一点点 PHP / JS / HTML，对于 http://ASP.NET 这种封装的 WebForm 框架各种不适应。 为了使用自己熟悉的方式开发项目，除了表单提交的其它页面都是单纯的 HTML，需要服务端数据的地方都是一个空的 div，每一个这样的 div 都对应于一个服务端的“数据 API”，请求方式和现在说的 JSONP 类似，服务端手工将数据拼接成 JS 字符串，客户端根据数据为 div 手工拼接 HTML。 当时不知道浏览器兼容问题、被 JS 转义符号坑过、被单双引号坑过、被字符 0 / 13 / 160 坑过；因为当时不知道 AJAX，涉及到 URI 不能承载的数据长度的需求时，只能采用 WebForm 的表单提交。 这个时期重心偏向 JS，历时大概 2 年，写了一堆 JS 类库，甚至包括 HTML div 绘图与 Windows 多窗口模拟这种从来没有在实际项目中使用过的比较重的类库。 后期接触到了 AJAX，把除了文件上传之外的所有 WebForm 都清理掉了；慢慢的开始接触并解决碰到的各种浏览器兼容问题。 2008 年中开始在某个使用 WebForm 的公司打了 1 年多杂，重心由 JS 转到了 C#，学习了多线程、网络通讯、数据库优化等技术，接触了一些初级的算法问题，后期开始接触代码生成技术并写了一个简单的 ORM 工具，这个阶段的工作和 WEB 框架基本扯不上关系。 2010 年初加入算法大牛 @李陶冶 所在的公司，跟着学习与讨论了 1 年多基础算法问题。这两年重度使用代码生成这种自动化编码技术，造了一些轮子原型，其中主要包括 TCP 服务框架、前后端一体 WEB 视图框架、ORM 缓存框架、二进制 / JSON 序列化。 在这个 WEB 框架原型中，引入了模板技术，使用 include 支持组件的抽象与重用，客户端实现了简单初级的类 MVVM 模型；框架自动生成数据 API，不再手工拼接 JS 字符串；数据 API 目标不再是 div 而是整个页面；数据 API 与 html 页面自动绑定，不再需要手写 JS 代码来初始化渲染页面。 为了应对搜索引擎的爬虫问题，服务端模板引擎不仅可以对浏览器输出类 JSON 数据，也可以对能够识别的搜索引擎输出 HTML。 当时的 WEB 框架仍然运行在 IIS + ASP.NET 环境中，除了文件上传功能，ASP.NET 基本只是当成一个裸的 HTTP 服务器在使用。 2012 年初 @李陶冶 创业，创建程序员与算法交流网站平台 51Nod 。 2012 年底在 @李陶冶 的支持下，计划开源并重构工作中用到的框架原型与类库，于是我发起了开源框架项目 fastCSharp 。 接下来的 4 年时间主要是根据工作需求扩充框架功能，针对框架性能问题做各种微改进与重构。 框架 WEB 层在开源之前写了一个 HTTP 服务器彻底摆脱了 IIS 与 ASP.NET，后期使用 TypeScript 重写了以前的 JavaScript。个人认为相对于 ASP.NET MVC 的 Razor 模板引擎，主要的缺点是在绑定模板数据的时候没有 IDE 自动提示与完成支持；优点是可抽象程度更高工作量更低，前端交互操作简单。 2016 年底辞职在家至今，一边找工作，一边精简、改进、重写 fastCSharp，也就是现在的 C# 高性能自动化服务端框架 - 凹凸架构，官网由于比较简单，所以采用了基于版本号更新的全站静态缓存策略。 该项目 TCP 框架在测试中支持 200W+/s 的加法函数调用吞吐；WEB 视图框架在 1024 并发短链接测试中支持 3W+/s 吞吐，使用 ab -n 100 -c 1000000 -k 测试支持 22W+/s 吞吐；单线程支持 200W+/s 二进制序列化操作与 30W+/s JSON 序列化操作。 以上测试环境为 Win10 + i5 6400 + 8GB + Hyper-V + Windows 2012 + .NET 4.5。