关于前端开发的互动探讨
最近收到几个关于前端，客户端的问题，借助这篇文章一并回答了。
1 Web开发下一步该如何演进?
【当前三大框架，angular ，react，vue做的足够完善，web的下一步的你觉得会如何演进？】
当前最流行的是三大前端框架： Angular， React，Vue。
这三个框架都是前端开发比较常用的框架，都属于单页应用开发框架，性能上都比过去的传统网络开发架构速度上要快。
所以单页应用开发是前端开发的主流趋势。它的主要思想是把后端的一部分逻辑拿到前端来做，这样可以充分利用客户端的高性能来为用户提供更好的体验。
这三个框架会分别沿着自己的技术特点继续往前迈进，目标应该是大同小异的:
1. 体积更小。客户端下载的程序包越小，那程序的加载速度就越快，尤其是在第1次加载的时候是一次性的把程序包下载到本地，这是目前前端单页应用开发框架的一个共同特点。
2. 运行更快。他们都需要对各自的框架进行精益求精，对编译选项和编译效率进行进一步的提升，同时要关注对浏览器引擎的支持。
3. 易用性的提升。程序的创建越来越容易，只需要一个命令行就可以全部搞定，这里面可以选择自己喜欢的测试框架，自己喜欢的编程语言，自己喜欢的布局风格等等，一旦设定以后，程序员只需要关注业务开发，不需要关注其他的基础配置细节。
2 关于三大框架API不统一的问题。
【（当前这三个框架的api不统一，导致如果存在切换的场景，会给业务带来非常多的成本。）。】
API不统一，技术风格不统一是自然的，其实这也是三大框架区分于彼此的主要特点。
比如说React，它的最典型特点就是jsx和单向数据流。它把模板和逻辑语言融合在一起。对于模板编程和样式编程不太熟悉的程序员，比较喜欢这种模式。所以React在程序员中的受欢迎程度比其他两个框架要高。
在以前处理React程序数据流的时候，选项并不多，Redux几乎是唯一的选项。这种数据流的处理方式会额外的增加程序的复杂度，因为它会单独创建出一套数据流的控制逻辑来。
使用hooks以后多了一个选项。但是目前很多React的程序员甚至都没有开始使用hooks。
Hooks的技术的引用可以增加react代码的可重用性，降低程序代码的规模，简化逻辑，从而增强程序的可维护性。
再比如Angular，它的典型特点是功能全面，模板和逻辑语言可以分开以及多种数据流的控制方式。模板和逻辑语言的分开使得程序结构更加清晰，代码的可重用性更强。
在Angular中可以使用至少三种数据流处理方式, 一个是input&output, 一个是基于Redux的ngrx, 另外一个是通过service。
Angular框架中还提供了很多其他功能, 除了一些特别的ui界面框架选择以外，几乎不需要使用第三方程序库了。
而Vue框架的特点呢，是试图吸收上面两个框架的优点，规避他们的缺点。但是众口难调，也存在很多批评的声音。比如他可以支持Angular的双向数据绑定, 但这一点呢，又跟其所支持的Flux数据流的模式相悖。
对于业务部门来说，在开发的过程中需要结合自己团队的技术能力，选择一种框架即可。
这里面有一点要非常清楚就是每个业务单元应用不要做的特别庞大。
如果业务单元做得特别庞大，以后想重构这个业务的时候，成本和代价会非常的高。
当今的技术发展日新月异，技术发展的趋势只会让我们的开发工作变得越来越简单，程序效能越来越高，所以我们无法避免以后程序的重构。
这里的重构不仅仅是代码层级的，也包括架构层级的。
3 关于框架的大一统问题。
【我猜想后续很可能会有一统大局的一个框架~】
如果有可能将来有一个框架能够大一统的话，这个框架必须具备如下的特点:
1. 比现有框架的体积更小。
2. 比现有框架的执行速度更快。
3. 比现有框架更容易学习使用。
4 关于svelte这个框架的看法。
【类似于https://github.com/sveltejs/svelte，后续web的选型会如何？】
Svelte这个框架相对来说比较年轻, 但是发展速度挺快。因为年轻，没有历史包袱，所以有机会做得更好。
同样功能的一个测试程序，它的产品程序包的体积跟三大框架相比都要小, 在运行速度上也更胜一筹, 并且这个框架学习起来也很容易。
至于风格的喜好，如果一个程序员喜欢React，可能不喜欢Svelte的风格。对于Angular和Vue的程序员来说，学Svelte就比较舒服。
但是Svelte目前的最大问题就是生态系统不是很全, 它既没有像Angular那样全的原生程序库支持，也没有像React和Vue那样多的第三方程序库支持。
5 后续es的webcomponent规范。
【类似于后续es的webcomponent规范起来后，后续web的选型会如何？】
Web Components旨在支持定制化的组件模型，允许单个HTML元素的封装和互操作性。想法是很好的，可是这个出发点导致了把作为模板的HTML元素复杂化。
在任何时候，我们都希望用最少的工作，最简单的工作来解决问题，能用CSS和HTML元素解决的问题尽量不使用Javascript解决。要尽可能的要把CSS与HTML分离，以减少复杂度，增加重用性。
而网络组件的理念则正好相反。它试图把CSS和Javascript以及自定义的一些复杂属性跟HTML元素结合起来，所以这个是设计方向是有问题的。
6 移动端技术会如何演进？
【当前移动端非常多的技术，h5，reactNative，flutter，原生技术等等。后续你觉得会怎么演进？有哪些资料么？ 】
6.1 h5
在手机平台, 跨平台技术里面像h5方案是成本最低的，因为我们开发网页程序的时候，就可以直接支持Responsive的应用程序，也就是支持不同屏幕尺寸的移动设备。
这种技术的一个缺点就是用户的体验并不是非常好。相比使用网页功能，用户更偏好一个独立应用更好的交互性， 从安全性的角度来说也更好。
6.2 React Native
对于安卓和iOS应用来说, 可以达到90%以上的React Native代码重用， 像一些与原生系统的功能需要用原生的代码来写，如图片编辑，视频的播放等等功能需要使用Java或者Swift来写。
这个框架的优势是提供了很多的界面元素，同时又支持热重载。所以相对来说开发的效率比较高，应用也很广泛。
6.3 Flutter
这个框架虽然比较年轻，但是发展势头非常迅猛。只是写代码的风格跟其他的框架不太一样，跟原生的安卓和原生的iOS写代码的风格也不一样。所以对一些老程序员来说有一个适应的过程。
这个框架既支持手机端，也支持了网页端的应用生成。使用dart作为编程语言。
6.4 Xamarin
相比上面的技术, Xamarin作为一个跨平台技术，存在的时间算是最长的。它的开发语言主要是c#。也可以重用90%以上的代码。
这个平台开发移动应用并非是免费的，所以使用的用户并不是很广。
6.5 原生应用开发
如果移动应用使用的很多原生功能在跨平台框架上不好实现的话，原生技术自然是非常好的选择。
另一个如果想追求应用程序性能的极致原生技术也是最好的选择。
关于移动端技术如何演进，主要需要关注如下几点，一个是业务需求，再一个是技术能力，还有开发成本也是一个重要的考量。
- 点赞
- 收藏
- 关注作者
评论（0）