求知若饥，虚心若愚。
最近一年，比较忙，没时间整理相关技术栈。但是不整理呢，又觉得好像少了点什么。
首先想把自己到目前为止，做过的“前端”方面的项目，都大致罗列一下。
毕竟自己从事前端已经6年有余，系统整理下，可以发现自己的不足和需要突破的方向。
回顾做过哪些类型的项目？
什么是大前端及跨平台方案？
除了大前端，自己还接触过什么？
自己还差哪些，给未来的自己?
从工作时长的维度来看自己做过的项目比重如下：
最早接触的技术栈是：jQuery、Zepto
jQuery、jQuery各类插件（忘的差不多了，哈哈，也能写，但比较排斥它）。
当时做的PC管理系统叫Drake X2，我还有点印象的jQuery库有：jQuery UI、jQuery EasyUI，jQuery插件有：jQuery Fancybox、jQuery FullPage、jQuery DialogBox…
其次接触的技术栈是：Vue
从之前Vue1.0出来的时候，就开始使用它，一直用到目前稳定的Vue2.x版本吧，遗憾的是自己还没接触最新的Vue3.x。后面转react了。
用Vue做过的PC管理系统有很多，比如：掌门APP管理后台、升学在线APP管理后台、走步宝管理后台…用的基本都是element-ui、vue-router、vuex那套。
现在接触的技术栈是：React
从公司在用Vue的时候，自己也在用React做自己的项目。
用React做过的PC管理系统也有很多，比如：掌门少儿APP管理后台、米盒云校管理后台…用的基本都是antd、react-router、dva那套，当然也有用redux原生写的。
Vue 和 React 是国内最流行的两个前端框架，孰优孰劣的争论，就从来没有停息过。
要有人提一句：”我觉得 A 比 B 更好”，下面肯定就是一堆回帖。
“ Vue 只适合小项目，大项目扛不起来”
“ React 组件太复杂，代码组织乱！”
“ Vue好上手，岗位多”
“ 大厂基本都用 React，不用 Vue”
其实大可不必，它们各有特点，都能解决前端开发的问题，你只要选择更适合自己风格的那种就可以了。这就像不同品牌的汽车，都能开到目的地，只是你开起来顺不顺手而已。
我就比较SB，两个都学呗，而且学的都不精~
APP里面会有WebView，专门渲染H5代码的，之前公司还专门为此封装了各类JSBridge，让H5可以调用原生的某些事件，比如返回、上传、掉起渠道分享等。
写APP H5页面和PC页面最大的不同点，是需要适配各类机型，使用响应式布局，自适应等。做H5页面，没啥JS逻辑，因此对JS的综合能力不需要太强，但对于HTML、CSS的要求就比较高了。
如果涉及到SEO搜索方面的优化，可能需要用到<header>、<footer>、<article>、<section>、<nav>之类的H5标签。
APP H5技术栈，Vue 和 React都有接触，写H5都没啥太大问题，用Vue写页面相对而言会更快。
自己曾在一家创业公司，负责公司的公众号和小程序。别看小程序不起眼，这个是引流的关键。
自己负责的两款小程序，累计用户超过500万，具体什么小程序，不方便透露，保密。
公众号分为订阅号、服务号。当时重构公司的服务号内的H5页面，从多页面应用转成SPA单页应用，极大提升用户体验。当时技术栈用的就是Vue1.0，将jQuery项目转成Vue项目，也是我第一次接触Vue。
小程序的话，是当时公司关注的核心业务，当时小程序的技术栈可没有那么多框架，所以都是用微信原生JS去实现的，必须用微信官方新定义的WXML（仿HTML）、WXS（仿CSS）编程语言实现，要说小程序比较坑的点，当属于微信实现的各种API和布局问题。微信开发者工具上看样式时一切完美，可是到真机设备一看，傻眼了…
目前在公司主要负责直播教师端相关业务，它是一个从无到有的PC客户端。之前接触过Electron，但不怎么深入。后面边做边研究后，发现Electron的功能十分强大，简单理解它就是拥有Node环境的浏览器，你可以操作该浏览器定做属于自己的产品。像有名的VSCode、WhatsApp都是基于Electron实现的。
多说一句，既然是PC客户端，除了可以使用web技术外，还可以使用c++实现的sdk。这个就和react natve如出一辙，只要有自身封装的第三方组件（java的Drawerlayout组件、object-c的AVPlayerLayer组件、c++的Boost组件），桥接给JS，JS就能实现原生的功能。
同时，既然是客户端，有些偏客户端的功能，比如升级、windows签名、mac OS签名、公证、音视频流等，并非纯前端就能驾驭的，我们只是在用别人底层的库或sdk，遇到问题，很难自己搞定。
之前提及过，公司在用Vue的时候，自己也在用React做自己的项目。截止目前为止，通过React Native实现过三款APP，都成功上架App Store、应用宝、Google Play，分别是2017年的找车场、2018年的享健身、2019年的享学习。
JS的强大之处是可以使用Android/iOS UI组件，react方面是react native，vue方面是weex。
自己喜欢研究react native，做过微信登录/分享、极光推送、微信支付、支付宝支付、原生播放器的使用等。
react native能让web前端，做和android、ios前端的事情，这点是比较牛逼的，不用再额外去学java和object-c。
PAD H5：
机顶盒 H5：
这两个项目，是之前公司在给华为合作的时候，给海外运营商做的IPTV产品。其实现并非Web 、也非Native，而是一个Hybrid App。后面会有具体介绍。
简单形容下自己：我是一名大前端开发工程师。
虽然自己目前没这么多，给自己奋斗定的目标！
简单来说，大前端就是所有前端的统称，比如android、iOS、web、各类终端等，最接近用户的那一层也就是UI层，然后将其统一起来，就是大前端。大前端是web统一的时代，利用web不仅能开发出网站，更可以开发手机端web应用和移动端应用程序、桌面应用程序。
大前端的主要核心就是跨平台技术，有了跨平台技术，各个平台的差异性就抹平了，开发者只需要一套技术栈就可以开发出适用于多个平台的客户端。
大前端跨平台方案简介：
上面提及的纯原生开发，不在这里说明，自己没怎么接触过。
这种模式又称为Hybrid开发，现在很多App都用这种模式去开发，常见的有微信、淘宝、美团、爱奇艺等知名移动应用等。国内也有很多公司使用Hybrid模式去开发平台，供开发者使用，像Dcloud、AppCan、Inoic等，基本上都是参考Cordova衍生出的混合开发框架。
这类框架主要原理就是将APP的一部分需要动态变动的内容通过H5来实现，通过原生的网页加载控件WebView (Android)或WKWebView（iOS）来加载，H5部分是可以随时改变而不用发版，这样就解决了动态化的需求。同时，由于H5代码只需要一次开发，就能同时在Android和iOS两个平台运行，这也可以减小开发成本，我们称这种h5+原生的开发模式为混合开发。
采用混合模式开发的APP我们称之为混合应用或Hybrid APP。
由于原生开发可以访问平台所有功能，而混合开发中，h5代码是运行在WebView中，而WebView实质上就是一个浏览器内核，其JavaScript依然运行在一个权限受限的沙箱中，所以对于大多数系统能力都没有访问权限，如无法访问文件系统、不能使用蓝牙等。
所以，对于H5不能实现的功能，都需要原生去做。而混合框架一般都会在原生代码中预先实现一些访问系统能力的API，然后暴露给WebView以供JavaScript调用，这样一来，WebView就成为了JavaScript与原生API之间通信的桥梁，主要负责JavaScript与原生之间传递调用消息，而消息的传递必须遵守一个标准的协议，它规定了消息的格式与含义。
我们把依赖于WebView的用于在JavaScript与原生之间通信并实现了某种消息传输协议的工具称之为WebView JavaScript Bridge, 简称 JsBridge，它也是混合开发框架的核心。
混合应用的优点是动态内容是H5，使用web技术栈就可以开发，社区及资源丰富，缺点是性能不好，对于复杂用户界面或动画，webview不堪重任。
这类开源框架的代表主要是Facebook的React Native、阿里的Weex，当然也有未开源的美团的Picasso，以及推出的快应用。
JavaScript开发+原生渲染的方式主要优点如下：
当然也有缺点如下：
渲染时需要JavaScript和原生之间通信，在有些场景如拖动可能会因为通信频繁导致卡顿。
JavaScript为脚本语言，执行时需要JIT，执行效率和AOT代码仍有差距。
由于渲染依赖原生控件，不同平台的控件需要单独维护，并且当系统更新时，社区控件可能会滞后；除此之外，其控件系统也会受到原生UI系统限制，例如，在Android中，在使用不同人写的控件嵌套时，手势冲突问题将会变得非常棘手。
React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的JS框架 React 在原生移动应用平台的衍生产物，目前支持iOS和Android两个平台。
RN使用Javascript语言，类似于HTML的JSX，以及CSS来开发移动应用，因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域。
React Native的原理和React设计一致，React中虚拟DOM最终会映射为浏览器DOM树，而RN中虚拟DOM会通过 JavaScriptCore 映射为原生控件树。
JavaScriptCore 是一个JavaScript解释器，它在React Native中主要有两个作用：
而RN中将虚拟DOM映射为原生控件的过程中分两步：
由于React Native是原生控件渲染，所以性能会比混合应用中H5好很多，同时React Native是Web开发技术栈，只需维护一份代码，即可在多个平台上使用。
Weex是阿里巴巴于2016年发布的跨平台移动端开发框架，思想及原理和React Native类似，最大的不同是语法层面，React Native使用React.js作为开发框架，而Weex则使用Vue.js作为开发框架。
Vue和React堪称前端领域最火的JavaScript框架，它们的易用性和功能性都非常强大，Weex在淘宝上也有广泛的应用。
快应用是华为、小米、OPPO、魅族等国内9大主流手机厂商共同制定的轻量级应用标准，目标直指微信小程序。它也是采用JavaScript语言开发，原生控件渲染，与React Native和Weex相比主要有两点不同：
1.快应用自身不支持Vue或React语法，其采用原生JavaScript开发，其开发框架和微信小程序很像，值得一提的是小程序目前已经可以使用Vue语法开发（mpvue），从原理上来讲，Vue的语法也可以移植到快应用上。
2.React Native和Weex的渲染/排版引擎是集成到框架中的，每一个APP都需要打包一份，安装包体积较大；而快应用渲染/排版引擎是集成到ROM中的，应用中无需打包，安装包体积小，正因如此，快应用才能在保证性能的同时做到快速分发。
Flutter 是 Google推出并开源的移动应用开发框架，主打跨平台、高保真、高性能。开发者可以通过 Dart语言开发 App，一套代码同时运行在 iOS 和 Android平台。 Flutter提供了丰富的组件、接口，开发者可以很快地为 Flutter添加原生扩展。
Flutter既不使用WebView，也不使用操作系统的原生控件。 相反，Flutter使用自己的高性能渲染引擎来绘制widget。这样不仅可以保证在Android和iOS上UI的一致性，而且也可以避免对原生控件依赖而带来的限制及高昂的维护成本。
Flutter使用Skia作为其2D渲染引擎，Skia是Google的一个2D图形处理函数库，包含字型、坐标转换，以及点阵图都有高效能且简洁的表现，Skia是跨平台的，并提供了非常友好的API，目前Google Chrome浏览器和Android均采用Skia作为其绘图引擎，值得一提的是，由于Android系统已经内置了Skia，所以Flutter在打包APK(Android应用安装包)时，不需要再将Skia打入APK中，但iOS系统并未内置Skia，所以构建iPA时，也必须将Skia一起打包，这也是为什么Flutter APP的Android安装包比iOS安装包小的主要原因。
Flutter就是通过在不同平台实现一个统一接口的渲染引擎来绘制UI，而不依赖系统原生控件，所以可以做到不同平台UI的一致性。注意，自绘引擎解决的是UI的跨平台问题，如果涉及其它系统能力调用，依然要涉及原生开发。这种平台技术的优点如下：
由于自绘引擎是直接调用系统API来绘制UI，所以性能和原生控件接近。
由于UI渲染不依赖原生控件，也就不需要根据不同平台的控件单独维护一套组件库，所以代码容易维护。
由于组件库是同一套代码、同一个渲染引擎，所以在不同平台，组件显示外观可以做到高保真和高一致性；
另外，由于不依赖原生控件，也就不会受原生布局系统的限制，这样布局系统会非常灵活。
不足之处：
为了保证UI绘制性能，自绘UI系统一般都会采用AOT模式编译其发布包，所以应用发布后，不能像Hybrid和RN那些使用JavaScript（JIT）作为开发语言的框架那样动态下发代码。
因此Flutter也有不足之处，不支持动态下发代码和热更新。
上面说到的技术栈只是移动端应用程序，下面来说说桌面端应用程序。
NW.js从DOM/WebWorker层,直接调用所有的Node模块，使用现有的web技术，开启一个全新的编写应用的方式。
NW.js基于Chromium 和 Node.js。 NW.js利用Web技术结合Node.js及其模块进行桌面应用开发。
从开发角度来说，选择用 nw.js 还是 election，区别其实不是很大。大部分工作还是在自己的 javascript上。
说个小插曲：nw.js的创始者就职于Intel，用业余时间开发了nw.js。创始者自己说了，精力不够，希望大家踊跃pull request，如果有功能需求可以付费在某网站(具体网址记不清)请人写功能代码提交到项目中来。现在issue的处理速度不容乐观。Electron由github主导，有成熟的杀手级产品atom和vs code，Intel和微软都有参与，社区还是很活跃的。
因此nw.js逐渐被electron取代，介于nw.js的日渐式微，所以更推荐electron一些。
Electron 是一个能让你使用 JavaScript, HTML 和 CSS 来创建桌面应用程序的框架。 这些应用程序可以打包后在 macOS、Windows 和 Linux 上直接运行，或者通过 Mac App Store 或微软商店进行分发。
如果你可以建一个网站，你就可以建一个桌面应用程序。
electron优点：
electron缺点：
1.卡，启动慢，这可能是webkit的锅。毕竟一个浏览器要支持的功能确实有点多。
2.除了主进程 你可能还需要启动一些辅助进程来完成工作。而每当你新开一个进程，起步价就是一个nodejs的内存开销！
3.丢帧，mac下感觉还可以，win下稍有点够呛。
4.打出来的包太大。（很显然，即便是一个空包，也至少包含了一个浏览器的体积）
如果程序只是跑在Windows上，就不用考虑electron了，原生WPF是最好的选择。
QT，用C++实现的，是一个神奇的存在！
如果想要跨平台，且想比electron性能高的话，就选Qt。
PyQt，是Qt库的Python版本，比c++方便的多，但是和electron相比没什么优势，因为electron和pyQt这两个都不如Qt稳定、快。
跨平台解决方案中，Qt 和 Electron 孰优孰劣？Qt适合一些性能要求高的桌面应用，如果你只打算做桌面端的话。或者是一些特殊的场景，比如你要做个类似绘声绘影的视频编辑器，做个类似word之类的桌面应用，那你用electron要么是没法做，要不就是体验非常烂。实际应用上，比如wps，yy语音，VirtualBox，以及部分adobe的桌面工具都是Qt做的。
Electron适合一些偏业务的应用，对性能没有很多要求`，主要是业务逻辑和UI展示，比较轻量级的应用。因为Electron可以一份代码同时得到网页版和桌面版，所以如果你的应用还需要网页版，那么Electron可以极大地节省你的开发和维护成本。比如钉钉，slack，现在越来越多的偏业务型（并不是需要高性能的专业工具）应用开始使用Electron来做了。
当然了，native还是web只是一种权衡，并不是有唯一答案的。
比如微信桌面版是native（当然不是Qt，是腾讯自己的UI库）而定位类似的钉钉则是web。豌豆荚这个不需要网页版的应用居然也是web方案（不是Electron，不过方案类似），wunderlist的win32版本也使用了web方案和网页版共用一套代码。
总的来说，native方案（Qt，WPF等）适合于高性能的专业应用，Electron适合想要把网页版和桌面端共享代码，同时对性能没有苛刻要求的场景。如果不在乎成本，native一定是体验更好的（微信），但是如果认为桌面端复用网页版的体验也能接受，那Electron成本会更低一些。
大前端讲完了，在来说说自己还接触过哪些知识点？
这些知识点其实没啥好说的，因为这些都是自己的过去式，这些只是在做项目和自己感兴趣的爬虫上或多或少接触过，但都不是特别擅长，自己瞎玩玩可以。
简单总结下自己：
一个词来形容自己：广而不精。
一句话来形容自己：然而这并没有什么卵用。
将这两个连起来，就是说自己在技能上广而不精，然而这并没有什么卵用。
要真说有用？那只能说经历多、接触多，仅此而已。恐惧来源于未知，其实接触过就不会感到恐惧了~
以前nginx不会，接触了也就那么一回事。以前觉得爬虫挺厉害的，接触了也就那么一回事。你爬虫写的再好，也会有新的反爬虫机制来阻止，扯远了哈。
仔细想了下，自己需要突破的方向。
1.继续深入技术栈react，从掌握到精通，尽量往更底层的知识点走。
努力往前端架构方向靠近，同时尽量学习源码和react17新特性。
2.学会组件封装、工具脚手架的自我开发。
3.学会封装工具类、actioin/dispatch、fetch等常用工具。
4.掌握新思想、ts、hooks、redux这些主流知识点，redux那套就目前而言理解的还不算特别透彻。
感谢2020年，这一年我抛弃了自己特别熟悉的vue技术栈，真正意思上转成react技术栈；
感谢2020年，这一年，让我接触到electron技术体系；
我喜欢vue、但更喜欢react，因为它高级~
自己特别喜欢的一句话：昨日种种，皆成今我。
过去经历造就现在的自己。不要总是回忆过去，也不要去为了过去的事情后悔。想成为什么样的人，想做成什么样的事情，就要想着从现在开始怎么去做。
去年努力的自己，在今年一定会有所回报的，因为这是自我认知的结果，而且理所应当。
生如蝼蚁当有鸿鹄之志，命如纸薄应有不屈之心。2021年，大家加油！