changfuguo
commented
4 years ago 有同样的感慨，可视化我们正在做，有几点感悟吧
组件库；
- 通用的组件库，比如antd，已经覆盖的差不多了，对team的要求个人感觉就是要吃透，吃透1-2套业界常用的即可。剩下的就是根据自己的业务需求封装业务组件，这个每个产品线都有自己的诉求，所以开发出来的不具有普适性，但是对每个team 是必须的
- 关于组件库的开发，我觉得是最基础的，但不一定是最重要的。往往就是每个team 都有自己的一套组件库，花了大量的人力和事件，最后不一定有对应的回报（领导认可+自我成长）。所以这个需要领导给与一定的人力和时间支持
可视化
目前我们也在做，这个的话就需要一套完备的基础组件做支撑。并且这套组件库是不能拿来直接用的，因为在可视化的编辑状态和实际release 状态的组件库是两种形态，要用更高阶的组件处理：
- 处理掉编程会用到，但是不好配置化实现的接口
- 处理掉无用的属性和事件
- 增加编辑状态需要的东西，比如统一事件传入到导出
- 适当支持一些简单的编程配置，数据的简单映射
- API如何接入和可配置化？参数如何传给api？拿到数据如何返回给页面？这些都是要约定一些通用属性，在高阶组件内部消化掉，再传递给真正的基础组件
等等，要解决的问题不仅仅是这些，百度的amis，阿里的飞冰，宜搭吗，uform等都是在积累沉淀
工程化
工程化目前也有现成的套件，react 有阿里的umi，react官网的，vue有自身的cli，但是这些或多或少都不能满足自己的需求，比如每个公司都有自己的一些服务，如图片，cdn之类的，所对于工程化的问题，我有几点感悟吧
-
脚手架一个重要目标，减少配置，方便开发，提高效率，持续集成。
快速方便生成一个项目，如css处理，babel 转换，ts 支持，热更新，不同环境支持，不同语言支持，输出优化，目录的约定，路由支持，语言包等等；也是一个脏活累活，但对于team发展来说，也是必须要过的一关 。
拿umi 来说，他开箱即用，上面说到的一些特性大部分都支持，再加上自己的antd组件库，简直就是如虎添翼，在加上ant pro，看来他们的意图很明显，就是要让你只关心自己的业务代码。但是他们对开发者暴露的东西很少，要定制化还是不方便，所以这块要想玩好，还是有些难度
-
另外一个，要能审时度势实事求是和自己公司的现状结以及人力合起来，比如打通一些服务，产出的js和图片 是否要存储，是否要combo等等；结合team的技术广度和深度有序展开，比如是否有必要支持pwa以及ws 等，要看自己的业务需求
-
在此基础上 积累组件库，自己的基础架构（主要是ant pro类似的架构设计，基本目录结构都有）
关于跨端，现在其他兄弟组也在和公司其他部门在做thonas，node这个我觉得前端出身做工具还中，真正做服务端做精深的还是少，io 网络 事件，多进程？大多数应该都是浮于皮毛（哈哈我自己也是），所以现在我觉得要做就要做深了
早上来了看到这个话题，感悟特别多，提笔写了一些感悟，可能文不对题。
目前的话在业务上来看，组件->脚手架->业务框架（ant pro）->可视化->node 是一个大家常用的路线。 不过这条路线对于大家来说都比较熟悉了，以至于前端在晋升的时候问你，你都做了啥？ 答曰，积累xx组件库，搞了一个yy的脚手架，写了n个模块，支持了多少业务，评委绝壁在心里唏嘘~ 答辩的人只好露出一个尴尬但不失礼貌的微笑~~
在日常业务开发中，前端的工作大多是“写界面加事件”，但是现代前端的内容远不止此，这里整理几个方向，有其他的见解欢迎探讨和补充。
1. 常规表单
这是从事B端/内部系统工作的主要内容，典型的例子是各种后台管理系统，技术上仅使用 DOM 接收和展示数据即可满足绝大部分需求。对 css 和动画的要求不高（毕竟可以“css 不够，js 来凑”），也很少有深度使用 svg/canvas 的场景。
这个方向的追求，个人认为是统一设计语言下的 标准化组件库，以大幅降低重复劳动，快速响应业务需求。
2. 可视化
这个方向不再主要使用 DOM，而是以 svg/canvas 为主了，需要掌握大量 svg/canvas api，以及一定的计算机图形图像知识。应用场景主要有两类，统计图表 和 3d 画图，这些图一般都不是静态图，因此对动画的要求也比较高。
这个方向侧重视觉效果，因此是前端里最炫酷的领域了。
3. 工程化
这是为了支撑大规模前端应用的方法论和工具集，比如静态语言 TypeScript，开发框架 React/Vue/Angular，css 预处理 Sass/Less，打包工具 Webpack，代码压缩 UglifyJS/cssnano 等。除了开发、编译，还应该包括部署方案，比如 serverless 下的容器部署、cdn、缓存等。
这个方向的目标是让开发人员能够专注业务实现，而工程化工具能保证上线的一定是 符合预期且性能最优 的。
4. 编辑器
编辑器以 功能复杂 和 允许用户任意操作 的特点，成为前端最有挑战性的领域之一。编辑器功能众多，不同功能难度差异巨大，比如 BIUS（加粗、斜体、下划线、删除线）一行代码就行，但像插入表格，则难度很大。类型上除了文本编辑器，还有表格、幻灯片、日历、脑图等，不同类型的技术架构和实现方案截然不同。
随着在线文档的流行，业内对 Web 编辑器的需求和期待也越来越高。
5. 跨端跨平台
在移动端上，指 H5、iOS/Android 原生应用、小程序；在 PC 端上，则是浏览器和 Windows/Mac/Linux 客户端。对于一个产品，特别是轻应用来说，每个场景都单独开发成本巨大，因此需要一套或几套跨端跨平台技术。目前 PC 端主要是 Electron，移动端则 Flutter 呼声最高。
6. 偏 Node
这时已经不太能称之为前端工程师，而是 “JavaScript 后端工程师”。除了开发语言，所做的工作及技能要求和后端基本没有差别，需要掌握 HTTP 服务框架、数据库 ORM、高并发、缓存等等，常见的工具有 koa2（或者 egg.js）、sequelize 等。
埋头搬砖，抬头看路，从这些方向可以看到，我们的征途是真的星辰大海！