西安app开发技术发生了很大的变化

作者：admin 时间：2019-01-23 浏览量：1006

近几年前端有着不小的变化，作为前端技术人员，一方面感慨有些自己熟知的技术逐步落幕消亡，另外一方面又看到新事物不断出现，以种种方式改进和冲击着我们的开发方式。生在这个时代是一种不幸，也是幸运。
前端的优势一是动态发版。动态发版要遵守用户协议，用户协议是不允许在Webview之外的地方执行Script，也就限制了Script只能是Javascript，因为Webview不支持别的脚本。
第二个优势是功能解耦，这一点很容易被大家忽略。随着客户端越做越大，它会变成非常依赖强力的架构师和强力的项目管理机制。这个要求对于很多小公司来说是致命的。前端就没有这个问题，每个人写各自的网页，浏览器天然隔离，相互不受影响。
还有就是前端技术非常适合三方，三方就意味着不可能要求三方使用指定技术。html本来就是一个各公司妥协的结果，即使是苹果的iOS这么这么强势还是给它留了Webview这么一条活路。客户端有三点非常直白的优势就是体验、设备特性和性能。这都是前端技术目前达不到的。

前端工程技术变化

看了React Native之后，我们开始往这个方向去思考。我们需要的是一门真正可以在上面做开发的语言，答案是weex。我们得到的就是前端的开发体验和客户端的用户体验。开发体验就是说其实整个工具栈全都是前端，但实际上渲染出的东西是weex。现在在我们淘宝的应用上，除了一些多年不变的基础业务，几乎所有业务都已经用前端来做了。

前端工程体系变化

以前我们要做一个网页，前端负责开发，做出一个demo性质的前端页面，然后做套模版。服务端把模版套好，和代码结合在一起，最后进行发布。之所以说前端特别薄弱，因为它没有自己的发布，只是一道工序，而不是一个工种。
另外套模版这件事非常繁琐。我们在2013年的时候，大家一直在讨论“前后端分离”，提出了各种各样的技术来解决套模版这件事。随着手机淘宝在整个集团的比例上升，手机淘宝这个方案基本上取得了胜利，并且是前后端同构。让前端独立去发布，就是最终极的前后端分离方法。独立发布前端只能发html，服务端所有东西要API化。现在我们的前端有一条自己的发布线，开发、构建、联调、发布。服务端是在联调环境参与进来的，拿它的API去做联调，然后前端自己进行发布。

这里对于前端来说多了两个环节，一个是构建。有了构建后想象空间非常大，之前前端就是Javascript，现在甚至引入了一些模版构建的技术，有一些外部的像unity也进来了。这样做丰富了整个生态，也让一些之前不是前端的人开始逐渐进入到前端的体系里来。
另一个就是发布环节。有了发布就意味着前端开始关注线上的东西，随之而来前端的工程体系，包括持续集成这样的概念早09年、10年的时候对于前端来说是个不可思议的话题，到今天在一些大公司的前端圈子里已经把这个话题当作非常自然的一件事了。

前端职责变化

还有一个更大的变化就是前端职责变化。我们曾对前栈有过一个想象，前端如果具备了服务端能力，我们会不会越做越“胖”，把服务端挤得只剩一小点了。但实际上如果这样做会导致一个严重的问题，缺少前端。后来我们在思路上发生了一个重大转变，就是赋能。从“把自己做成全栈”变为“帮别人做成全栈”，降低服务端的人去做前端的成本。

另外当服务端把能力输出给服务端的时候，服务端也会输出能力给前端。前端输出给服务端的能力就是组件体系和搭建体系。服务端输出给前端的能力是对数据做一定的标准化和校验。把不同前端的业务平台化，在业务层面上是不一样的，实际上是从同一个平台出来，这样前端也具有了一定的全栈能力。最后变成了一个“你中有我，我中有你”的状态，大家又各自在负责自己擅长的部分。这是真正意义上的全栈最终在我们团队落地产生的场景。

未来：前端技术云化

我的理想是将来以前端为中心去开发应用开始成为一种可能。只需以前端技术为核心去构建一支团队，它就可以独立地开发一个应用。

“云端配合”的概念可能会取代现在纯粹云服务的概念。

将来的前端不仅仅是现在已经在做前端的人，还包括了一些更广泛的群体。比如被输出了前端能力、被赋能的那些服务端的同学，以及做更底层的功能、给我们提供插件能力的服务端同学，他们都会变成一个模糊的“大前端”概念。这是我认为未来前端的一个发展趋势。