视图争霸:Q&A

举报
Jet Ding 发表于 2021/07/22 18:30:53 2021/07/22
【摘要】  最近收到几个关于前端,客户端的问题,借助这篇文章一并回答了。 1       Web开发下一步该如何演进?2       关于三大框架API不统一的问题。3       关于框架的大一统问题。4       关于svelte这个框架的看法。5       后续es的webcomponent规范。6       移动端技术会如何演进?6.1        h56.2        React...

 

最近收到几个关于前端,客户端的问题,借助这篇文章一并回答了。

 

1       Web开发下一步该如何演进?

2       关于三大框架API不统一的问题。

3       关于框架的大一统问题。

4       关于svelte这个框架的看法。

5       后续es的webcomponent规范。

6       移动端技术会如何演进?

6.1        h5

6.2        React Native

6.3        Flutter

6.4        Xamarin

6.5        原生应用开发

 

1         Web开发下一步该如何演进?

 

【当前三大框架,angular ,react,vue做的足够完善,web的下一步的你觉得会如何演进?】

 

当前最流行的是三大前端框架: Angular ReactVue

这三个框架都是前端开发比较常用的框架,都属于单页应用开发框架,性能上都比过去的传统网络开发架构速度上要快。

 

所以单页应用开发是前端开发的主流趋势。它的主要思想是把后端的一部分逻辑拿到前端来做,这样可以充分利用客户端的高性能来为用户提供更好的体验。

 

这三个框架会分别沿着自己的技术特点继续往前迈进,目标应该是大同小异的:

1. 体积更小。客户端下载的程序包越小,那程序的加载速度就越快,尤其是在第1次加载的时候是一次性的把程序包下载到本地,这是目前前端单页应用开发框架的一个共同特点。

 

2. 运行更快。他们都需要对各自的框架进行精益求精,对编译选项和编译效率进行进一步的提升,同时要关注对浏览器引擎的支持。

 

3. 易用性的提升。程序的创建越来越容易,只需要一个命令行就可以全部搞定,这里面可以选择自己喜欢的测试框架,自己喜欢的编程语言,自己喜欢的布局风格等等,一旦设定以后,程序员只需要关注业务开发,不需要关注其他的基础配置细节。

 

2         关于三大框架API不统一的问题。

 

【(当前这三个框架的api不统一,导致如果存在切换的场景,会给业务带来非常多的成本。)。】

 

API不统一,技术风格不统一是自然的,其实这也是三大框架区分于彼此的主要特点。

 

比如说React,它的最典型特点就是jsx和单向数据流。它把模板和逻辑语言融合在一起。对于模板编程和样式编程不太熟悉的程序员,比较喜欢这种模式。所以React在程序员中的受欢迎程度比其他两个框架要高

 

在以前处理React程序数据流的时候,选项并不多,Redux几乎是唯一的选项。这种数据流的处理方式会额外的增加程序的复杂度,因为它会单独创建出一套数据流的控制逻辑来。

 

使用hooks以后多了一个选项。但是目前很多React的程序员甚至都没有开始使用hooks

 

Hooks的技术的引用可以增加react代码的可重用性,降低程序代码的规模,简化逻辑,从而增强程序的可维护性

 

再比如Angular,它的典型特点是功能全面,模板和逻辑语言可以分开以及多种数据流的控制方式。模板和逻辑语言的分开使得程序结构更加清晰,代码的可重用性更强。

 

Angular中可以使用至少三种数据流处理方式一个是input&output, 一个是基于Reduxngrx, 另外一个是通过service

 

Angular框架中还提供了很多其他功能除了一些特别的ui界面框架选择以外,几乎不需要使用第三方程序库了。

 

Vue框架的特点呢,是试图吸收上面两个框架的优点,规避他们的缺点。但是众口难调,也存在很多批评的声音。比如他可以支持Angular的双向数据绑定但这一点呢,又跟其所支持的Flux数据流的模式相悖。

 

对于业务部门来说,在开发的过程中需要结合自己团队的技术能力,选择一种框架即可

这里面有一点要非常清楚就是每个业务单元应用不要做的特别庞大

如果业务单元做得特别庞大,以后想重构这个业务的时候,成本和代价会非常的高。

当今的技术发展日新月异,技术发展的趋势只会让我们的开发工作变得越来越简单,程序效能越来越高,所以我们无法避免以后程序的重构

 

这里的重构不仅仅是代码层级的,也包括架构层级的

 

3         关于框架的大一统问题。

 

我猜想后续很可能会有一统大局的一个框架~

 

如果有可能将来有一个框架能够大一统的话,这个框架必须具备如下的特点:

 

1. 比现有框架的体积更小

2. 比现有框架的执行速度更快

3. 比现有框架更容易学习使用

 

4         关于svelte这个框架的看法。

 

【类似于https://github.com/sveltejs/svelte,后续web的选型会如何?】

 

Svelte这个框架相对来说比较年轻但是发展速度挺快。因为年轻,没有历史包袱,所以有机会做得更好。

 

同样功能的一个测试程序,它的产品程序包的体积跟三大框架相比都要小运行速度上也更胜一筹并且这个框架学习起来也很容易

至于风格的喜好,如果一个程序员喜欢React,可能不喜欢Svelte的风格。对于AngularVue的程序员来说,学Svelte就比较舒服

 

但是Svelte目前的最大问题就是生态系统不是很全它既没有像Angular那样全的原生程序库支持,也没有像ReactVue那样多的第三方程序库支持。

 

5         后续eswebcomponent规范。

 

【类似于后续es的webcomponent规范起来后,后续web的选型会如何?】


Web Components旨在支持定制化的组件模型,允许单个HTML元素的封装和互操作性。想法是很好的,可是这个出发点导致了把作为模板的HTML元素复杂化

 

在任何时候,我们都希望用最少的工作,最简单的工作来解决问题,能用CSSHTML元素解决的问题尽量不使用Javascript解决。要尽可能的要把CSSHTML分离,以减少复杂度,增加重用性。

 

而网络组件的理念则正好相反。它试图把CSSJavascript以及自定义的一些复杂属性跟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    原生应用开发

 

如果移动应用使用的很多原生功能在跨平台框架上不好实现的话,原生技术自然是非常好的选择。

 

另一个如果想追求应用程序性能的极致原生技术也是最好的选择

 

关于移动端技术如何演进,主要需要关注如下几点,一个是业务需求,再一个是技术能力,还有开发成本也是一个重要的考量。

 

2020-07-14

Jet Ding

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。