阿里巴巴高级程序员告诉你，前端到底难不难

先说一下个人认为：整个Web层的纯业务开发可以说都没有难度，后端业务基本就是CURD，前端基本就是数据渲染到视图。

1.逻辑部分: 后端业务层的代码大多数时候只是在处理数据库中的数据，即便是双十一这种场景大部分难点也基本是在业务框架（HSF分布式服务框架）、数据库（OceanBase）、网关（SLB负载均衡）、缓存（分布式KV存储Tair）、计算平台（Blink）、调度平台（Sigma）等等层面被解决了，而不需要过度侵入业务层。所以对比前端将数据稍加处理渲染到页面上，后端的CURD也没有凸显出什么难度。

2.性能优化：服务端的性能优化基本离不开负载均衡、缓存、资源池，至于IO优化（异步、非阻塞）一般也是在框架或者语言层面解决了。

我承认有在有线程与锁的语言（例如Java）中，并发场景下做好多线程优化和锁的优化不简单，但是并发编程的范式不仅限于线程与锁啊，还有CSP和Actor等等，我作为一名前端过了一遍Go语法和框架文档后就能快速上手写出性能不算太差的后端Go代码了，基本不用去考虑线程和锁。

数据结构这个点，一方面是由前后端的运行场景不同而决定的，服务端数据结构的优化确实可以给内存占用、运行耗时带来用户数量级的减少，用户量越大效果越可观。而前端是运行在客户端上的，大多数时候即使是10倍的速度提升，也不过是从0.01s优化成了0.001s，用户体验上的改变不是很大，甚至不如优化动画带来的提升明显。另一方面，则是由于JS本身比较弱，没有很成熟的类似于Java集合框架、C++ STL的数据结构库，而且前端会对打包大小比较敏感，一般生产环境直接引入第三方库前会反复review。至于网络优化，大多是在架构的层面去做的，业务层不会去考虑。

3.工程复杂度： 我没有在淘宝和天猫工作过，但我在淘票票（淘宝电影）实习过大半年。淘票票作为典型的淘系业务，确实符合你说的后端人数远超前端，但这个很大程度上是业务和领域模型导致的。

最典型的例子，淘票票后端需要对接很多第三方的院线，有万达、大地、幸福蓝海等等；还会和第三方售票系统例如满天星对接，而这些对前端几乎是没有感知、不需要也不应该去关注的。

而我现在所在的团队，同样由于业务的原因，前端人数是大于后端人数的，前端团队维护的业务产品线与代码量绝不亚于后端。

总结

说了这么多，个人认为，如果是狭义上的前端业务开发，几乎是没有难点的，后端也是。逻辑、性能优化、工程三个方面的复杂度都是由业务决定的，不能一概而论的认为前端比后端复杂或者后端比前端复杂。

感谢阅读