前端技术选型

前端技术选型

    • 选型该怎么选型
      • 有了需求才有技术选型
    • 运行环境和容器选型
        • PC
        • PC and mobile
        • 移动端 (Android,IOS),小程序,H5
    • 选型共同特点

选型该怎么选型

  1. 根据需求
  2. 项目运行环境和容器选型
  3. 运行方式
  4. 团队主要技术栈选型
  5. 开发周期选型
  6. 后期项目扩展性选型

有了需求才有技术选型

当提出项目需求后,要根据项目整体进行技术选型,不要根据 会什么技术或者想用什么新的技术而选型

如果项目要求兼容 IE11 就可以了,那就可以放心选择现在主流的前端框架 (vue 3.0 以下,React)

如果项目要求兼容 IE9 以上 那就可以放心选择现在主流的前端框架 (vue 2.6 以下)

react-app-polyfill (IE兼容插件)

import 'react-app-polyfill/ie9';
import 'react-app-polyfill/ie11';
import 'react-app-polyfill/stable';

要求兼容 IE8 又要使用前端框架 [email protected]
vue 2.6 版本要依靠 babel-polyfill 插件

兼容 IE6 avalonJS,或jQuery,bootstrap 或者纯JavaScript

运行环境和容器选型

运行环境和承载容器(更一步缩小选型范围)

  1. PC (所有浏览器)
  2. 移动端 (Android,IOS)小程序 (国内不计其数的小程序容器)或者 FinClip (小程序容器)H5
  3. 指定容器这里指,某一个App 内部的webivew
PC

如只考虑主流浏览器,以及业务场景只在PC 浏览器端运行 ,此场景就可以使用前端任意 mvvm 框架 (vue,react,sveltejs,等,或者原生技术进行开发)

PC and mobile

此应用场景 多数为 (门户网站,和极少数的管理类型网站),此时的技术选型就得 根据使用场景和运行容器来选择,布局方式采用媒体查询,根据不同尺寸的终端来适配不同的样式,如果要使用css 框架,就尽量选择PC和移动兼容的 (可参考 bootstrap,以及栅格化布局,百分比布局不推荐在次场景使用).

移动端 (Android,IOS),小程序,H5

分析客户寻求就能很快确定,客户到底想要开发一个什么类型的东东,问项目来干什么的,现在互联网的入口主为手机,换一个思维来想 (除了管理类的项目多数都是在移动端)

  • 移动端对于前端来讲,就是H5, H5主要运行场景在手机上,如(微信公众号,朋友圈的分享链接,一些App分享出来的链接,或者在App 内容打开的活动页)
  • 如想要依靠微信或者抖音的流量还想要体验好就小程序,目前主流应用App都有自己的容器 (所谓的小程序),小程序缺点内容量有大小限制(微信小程序如主包限制在2M,一共包的大小,不超过4M,这个规定可能会根据时间而改变)
  • 移动端 (Android,IOS)自己产品,自己运营,体验比小程序好,没有开发限制

如何进行此类项目进行选型呢?

根据

  1. 开发效率
  2. 扩展性
  3. 是否长期迭代更新
  4. 团队技术栈
  5. 团队成员数量
  • h5 (如商城,团队技术栈为,vue , React)

    • vue
      目前vue分为 cli 和uni-app(跨端框架)
      1.如该项目时间周期短 (后期想扩展为小程序或是独立的 应用),就选用uni-app ,为啥?因为团队成员都会vue,可以很低成本,生态好(vue 的组件能够使用,但是uni-app的组件vue不一定能使用),在移动端适配方面uni都把基础的都弄好了,不需要我自己去解决一些基础问题,比如说移动端不通手机的适配,和uni 提供的api 移动端都是能够兼容
    • React
      React 分为 cli 和 Taro (跨端框架)
      1.如该项目时间周期短 (后期想扩展为小程序或是独立的 应用),就选用Taro ,因为团队成员都会React 或者 vue,可以很低成本,不需要我自己去解决一些基础问题,比如说移动端不通手机的适配,和 Taro 提供的api 移动端都是能够兼容 还有自己 组件厂 都是为了解决业务场景的,很多都可以自己改
  • 小程序

    • 移动端开发框架对接,包含,小程序,h5 ,app
      • 原生小程序
  • 原生小程序开发的体验和调试肯定会比跨端框架 好些,因为直接在工具里面编译运行,内部API 可以直接使用,
		- uni  (跨端框架)	

如果你会用vue那就选择unia-app ,虽然uni-app 跟小程序开发的如法出入不是特别大,uni-app 开发体验肯定没有原生小程序开发体验好,但是uni-app的生态和轮子肯定要比,微信小程序好 (官方不支持动态代码转译,无法把已有的微信小城代码转为uni,但是社区有其他方案)有自己的插件市场,也是为了解决业务场景,在 (Android,IOS) 渲染方式有 webivew 和 Wexx 渲染,(Wexx 有一定学习成本,并且跟 css 有所差异)并且有自己独立的Native库,可以单独使用,可以配合uni使用,(uni-app 由 dcloud 团队维护开发,前身可能是 mui )

		- Taro (跨端框架)

有react 基础 和 Vue 基础都可以 选择 Taro 官方(支持使用 React/Vue/Nerv )进行开发 ,Taro 官方支持把微信小程序代码转译 到 Taro ,同样也有自己的插件市场,也是为了解决业务场景的,并且 跨端到 (Android,IOS) 用的 ReactNative (58团队维护)

		- 跨端跨级啊共同特性(跨端框架)

跨端框架 是进过编译后在再微信小程序工具运行的(H5可直接运行在浏览器),编译后的源码不太好理解(除非js功底很好),因为特性为跨端,内部API需要不同终端运行进行条件编译,跨端框架 编译过程可能,会存在,编译不上代码,编译时间过长,编译卡顿,或者一些动态属性微信小程序不支持,然后H5是支持,这样的坑反正是不少

  • (Android,IOS)

    • 这里只考虑,前端能够用的技术栈 HybridApp ,webApp,reactNative(flutter除外)
      目前 能用开发 app 国内有很多跨端框架 如 (uni-app ,Taro ,Chameleon,Hippy,hummer )都属于混合开发

      • uni-app 开发时间和周期是很快,但是体验和性能是相对来说是低的 (除了选用Wexx),一般为初创公司首选(开发成本和周期都低,容易找到开发人员,小外包公司首选,或者控制人力成本和周期,一般选用的是webview 渲染,因为wexx 有学习成本)

      • Taro 的效率是没有 uni-app 高,但是用户体验是比uni-app 好 因为选用的 ReactNative

      • Hippy 腾讯在维护,支持 React 和 Vue 两套界面框架,从底层做了大量工作,抹平了 iOS 和 Android 双端差异,提供了接近 Web 的开发体验,在安装包和内存,都比ReactNative控制的好,腾讯主流应用都有使用

      • ReactNative 开发成本和学习成本是较高的,很uni-app 一样需要先学习React 基础语法后在能进行开发,用户体验是优于uni-app,目前有(云闪付,小红书,京东,Edge手机浏览器 )等主流应用在使用,ReactNative 重构已经完成,目前内部在使用今年内 社区能够使用重构的版本

  • 指定容器运行

    • 如运行到微信小程序,或者企业微信 (如字节旗下应用内部运行,抖音,今日头条等)
      考虑 ?
      会不会后期需要运行到其他平台 ?
      1. 不确定,建议选用跨端框架进行开发,因为后期转化成本相对于来说是低的
      2. 确定,建议使用原生小程序开发,调试成本和开发体验比混合开发好
      是否需要微信授权登录,如获取用户信息 (这里H5 (需要SDK) 和小程序都能实现),和要求用户体验性
      1. 需要,建议使用原生开发 (包大小有限制,发布版本需要时间审核)
      2. 不需要,使用 H5 开发,成本低,效率高,版本更新迭代快
    • 指定应用内部运行 (App 或者 webivew)
      如只有App内部 (这里指原生和混合)
      1. 原生开发,能再应用内部埋点(定义好H5可以调用的App内部的函数,在H5中可以调用原生方法)
      2. 混合(uni-app)在App内部运行,可以在H5中调用uni-app 的app中的 Native,实现与原生交互,又可以快速更新迭代
      3. 在其他的webivew 运行,很多应用内部都 webivew 运行H5,避免了应用的跳转,这一类的运行方式,一般app的开发者会限制webivew 一些 JavaScript函数或者过滤一些函数,如 alert

选型共同特点

  1. 长期迭代更新,这个对于前期的技术选型很重要 ,是否采用项目规范化管理和开发流程,如(需要长期更新迭代,考虑加入TS,和eslite,和一些样式命令规范)在项目基础建设的时候都要去做

  2. 团队成员数量,俗话说,无规矩不成方圆,一个人单打独斗,二个并肩作战,三个人团队作战,个人独立开发项目和自己后期维护,根据自己技术栈和是否长期迭代就可以选择技术栈,二个人,各做各的,可能期间回去改对付代码,这个时候就要要求,代码注释和命名规范了,不然越往后(离职)就越难受,只敢加代码,不敢动原有的代码,团队开发时候,更加要注重和加强

你可能感兴趣的:(前端,javascript,开发语言)