文章的名字我想了很久，备选项有“我再不推荐 Redux”，“Redux 为什么令我头疼”，“Redux 进化启示录”等等。通过这一系列名字我想你大概能猜到我接下来想聊的问题是什么，但这个问题放眼望去不是 Redux 独有，而是在做技术决策时经常会遇到的，即使对于非前端背景的开发者也同样成立。最后决定用一个带有开放式标题也许能够引起更多的共鸣。

react redux frontend

上篇请访问这里做一个能对标阿里云的前端APM工具（上）

performance frontend

APM 全称是 Application Performance Monitor，即性能监控

performance frontend

技术具有商品属性，这是常常被我们忽略的一个事实。且不谈垄断之后带来的商业利益，一方面技术依赖市场的认可来彰显它的价值，另一方面技术还需要依靠大众的反馈才得以完善自己，所以庞大的用户群体是它繁荣的基石，它需要尽可能的为人所知。 无论你是想吸引更多的项目和开发者加入某个社区中，还是想让某个框架摆脱默默无闻乃至脱颖而出，过程都务必依赖于大量的运营活动，其中不少也要倚靠背后大厂的资源投入。从近乎寿终正寝的 Silverlight 到近些年大火的 Flutter，无不遵循着类似的模式。

serverless backend frontend

之所以限定于“入门”是因为我算不上 SQL Server 专家，只不过在最近做性能优化时积累了一些经验，虽然不深但足以应付我们日常需要解决的一些 SQL 语句方面的性能问题，因此分享出来供大家参考。自私点说哪怕长时间用不上这技能，生疏之后靠回顾自己的文章也能很快的捡回来。

sql performance backend frontend

在历数技术进步的代价时，弗洛伊德遵循的路线使人感到压抑。他同意塔姆斯的评论：我们的发明只不过是手段的改进，目的却未见改善。 ——尼尔波斯曼《技术垄断》

css architecture frontend

正在阅读这篇文章的你，或多或者接触过前端性能优化，这样的接触可能是来自你的阅读体验也可能是来自工作经验。那我们不妨从一个非常简单的思想实验开始，请你借助你对这个领域的理解，来回答下面的几个问题：

performance frontend

编程框架日新月异，工具平台推陈出新。但有意思的是，代码的坏味道不会因为你使用工具的时髦而自行消散，团队成员的编程水平也不会随着工具的进化而水涨船高。

code design vue frontend

随着应用程序的日趋庞大，它变得越来越难以维护。随着可复用模块的重要性逐渐递增应用的复杂性也随之增长。我们都意识到我们应该在它面临难以维护的风险之前做些什么

mvc architecture frontend

这篇文章或许看上去仅和 Angular2 开发者相关，但我相信它也适用于其它的框架。这只是一份关于编写具有可拓展性和可维护性单页面应用的指南。需要指出的非常重要的是，这并不是达成目标的唯一方式，但是对我个人而言它们在不少的场景中都行之有效

angular architecture frontend