乱七八糟的 web 项目又做了有一阵子了，通过去探索和尝试各种好玩的框架和比较新的技术对目前很多东西有了更深的了解，这里写下一些最近的体会。

在评价各种技术的好坏之前，是想要说清楚自己从什么方面去衡量一个技术的好与坏。个人认为从技术与商业的关系上，如果非要分开的话，那么技术是必要服务于商业。商业的决策的执行受制于诸多因素，当然技术也是其中的一个方面。技术的灵活和高效支持了商业的灵活与高效。假如让商业和技术彻底的分开各自作为一个黑盒，那系统的运作应该是每次商业的变化都需要技术随之变化并且尽量快的完成这个变化，也就是说，我们需要的是一种能力，这个能力就是让商业决策付诸实施的速度尽量快的能力。这就要求技术去 拥抱变化，能够快速的响应需求，响应变化。那么，在技术的选型上就会有一个非常重要的标准就是开发效率了：如何完成同一个功能所用的时间尽量的少，当然这不是建立的偷工减料的基础上。当然对于形形色色的指标还有很多，比如稳定性，比如可扩展性，比如可靠性，比如安全性。但这些指标在现在的技术体系中已经逐渐在变成类似于基础设施的东西了，暂不考虑。

对比了一些主流的技术之后，如果从 get-started 的水平来讲，django ror 这样的框架非常的快。尤其是 rails 里面默认包含了当时 migration coffeescript scss 等等 web 开发的最佳实践，并有一个非常易于扩展的 plugin 体系，可以通过安装额外的 gem 就完成了一个个完善的功能。例如 devise 可以独当一面提供完整的用户系统，active-admin 则可以为软件提供一个完整的后台管理页面。如果是要做一个简单的项目的话，rails 绝对是最佳选择。最近的一个内部项目就需要快速的给财务的同学们搭建一个小的内部资产管理系统。通过 rails + active-admin +wice_grid 一周就搭建起来了这个体系，换用别的技术栈从头做起那简直是噩梦。

但是，rails 这种后端渲染的应用没办法兼顾目前诸多 client 的问题。并且在目前的发展过程中，我当年所期望的 html 统一天下的情况果真在逐渐成为现实。Mobile 端的 React Native，桌面端的 Electron，虽然这并不代表一次编写到处执行。它仅仅代表我可以采用 html 这种更简单的技术栈去替代复杂的技术栈进行开发了。那么，为了更好的支持多平台，将前后端分离后让一个后端可以支持所有的前端的方式胜过了同时提供 html render 以及 api 的模式。并且，它带来另外一个非常大的好处：separation of concern。这看似是将原来的逻辑分类转变成了仓库的物理分离，但这确实提供了并行开发的可行性，也让后端 API 的测试方便了许多。通过项目构建时将 RESTful API 作为前后端开发的契约可以保证双方开发不会出现太大的问题。

还有，简单 这个状态是带有时间戳的。现在的系统都很少有一锤子买卖，都可能有一个持续发展的过程。那么，一个一开始认为的 简单 的东西到底会变成什么样子真不好说。从维护的角度去讲，能够轻易的重构的强类型语言远胜过了弱类型的语言。那么，ruby python js 这种当年被认为是脚本语言的弊端就出现了。对我来讲 java 里面的 interface 和完善的 class 体系对于构建复杂的 oo 设计模式以及复杂的领域模型实在是太方便了，加上一些好的编辑器对 java 的增益效果，我更希望在业务逻辑可以无限复杂的后端采用这样的静态语言来屏蔽未来产品扩张时所带来的问题。甚至对于复杂的前端应用来说，大家也受不了弱语言 + 单线程的 js 了，typescript 在很大程度上填补了 js 的弊端，再加上快速的为 js 中添加 es6 甚至是 es7 的特性去屏蔽无结构、回调地狱这样一系列的问题。即便是 promise 也一直存在一个吞食内部报错的情况，实在是不好用。

而前端则倾向于采用 react angular 这样的框架去处理前端应用模块化、路由、异步、渲染等一系列的问题。但是这也减缓了页面第一次加载的速度：在第一个页面打开的时候需要加载大量的基础代码，这虽然可以通过分块加载以及初始页面的 server side render 在一定程度上有所缓解，但我总觉得这一定只是临时的解决方案。并且 server side render 也大大的增加了应用的复杂度，在我看来利大于弊。

UPDATE 目前像 next.js 采用的 server side render 和我在这里所说有所不同。next.js 希望实现 react component 直接在后端渲染，而我这里讲的是在 redux 中提及的首次 render 采用的技术。

总结一下呢，为了支持多平台以及更方便的对后端做 scale，前后端分离是一个不错的选择。并且在构建复杂的、或者说是需要持续维护的 web 产品的时候，如果可以尽量多的重用已有的东西，方便大家快速的认识很了解项目的内容，那么支持重构的强类型语言相对于动态语言有更多的优势。但是 rails 等动态语言确实很好用，我始终没有在 java 下看到像是 active-admin 这样的后台管理界面可以几个命令拔地而起。有的时候就在想是 java 这样的强类型语言这么多年为什么就没有做出来像 rails 那样的非常多的可重用模块呢？是自身的语法限制么？我深表怀疑。事实上，最近我也看到了 spring 下一些很有一些的东西包含了像是 active-record 的一些功能，但是又拥抱了 ddd 的思想，让持久化作为一个依赖出现在项目中。之后的日子里一方面会多多关注大型的 webapp 构建的问题以及在不同平台下前端的开发效率的问题，另一方面会看看 java 体系下的一些新进展，如果真的可以兼顾 get-started 的开发效率又能保证以后的维护问题，那么该体系会逐渐成为未来开发的主流。

当然，还有一些问题没有解决，比如部署，比如前后端的契约如何实施，比如 scale 等等。这个我理清了写吧.