所以这方面就没有太多的投入了?前端规划

作者:admin 来源:未知 点击数: 发布时间:2020年10月11日

  lighthouse/perf curve/perf budget这些都是作为性能监控的工具,不仅仅可以得到线上环境真实数据,还能在开发阶段提前预警性能问题、落地性能优化的最佳实践,也是小伙伴们不可或缺的好伴侣~

  打包前端工程打包工具强烈推荐webpack 4,强大的插件能力能够让你做几乎任何事情。webpack4中引入了更为强大智能的code split能力,能够极大缩减包大小,经过实践通常减小幅度都在30%-50%,而且在打包速度上也有很大改进,通常也有30%的提升。

  还有啥比较火?对,faas。faas的核心是什么?好像也是游说,以及你需要掌握k8s和docker的分布式架构,以及后续的一系列自动部署方案。有了这些,才轮得到谈服务端框架得问题。

  从去年开始带着团队研究可视化方向,目前还主要在可视化的2D图形展现上,去年我们做了spritejs库和周边一些子项目,解决我们自己可视化项目的问题,今年我想深入研究3D这块,从底层开始学习,把以前图形学的一些知识从新捡起来。有机会我想再给开源社区贡献一个高性能跨平台可扩展的2D/3D底层渲染库。

  所以19年的规划里面,应该有游说能力的提升,19年我特别想听到一场题目是《如何游说团队引入GraphQL》的分享。

  后来由于本人不喜欢动态语言,加上动态语言在有一定规模项目上表现出来的孱弱,我们团队进行了Typescript 改造,开发体验发生质变,node 真得感谢 JavaScript 生态,如果没有 TS 我们早就抛弃 node 了,Typescript 在类型系统上卓越的设计是我个人现在还在小项目上使用 node 的唯一原因了,Anders 不愧是程序语言设计大师.

  构建工具:Webpack 一家独大,第二是 gulp,第三是 Grunt,后两者应该都在慢慢下降。

  Electron: 分别在两家公司做了两个不算完整的桌面应用,只能算是会用了,了解架构

  以上是我个人想法,暂时就想这么多了,年纪大了学东西没有90后年轻人快,不敢贪多。

  Flutter跨平台解决方案Flutter作为一个跨多端(iOS,Android,PC,Embedded),具有美观、快速、高效、开放的特点,目前在闲鱼、贝壳、阿里等公司都有落地场景,作为下一代跨平台解决方案我们可以持续关注,它具有一个非常宏大的野心,背靠Google大厂,能够从系统底层开始抹平各端差异,具有一个强大的技术架构来支持,长期来看还是挺值得期待的。

  umeng作为移动端行为分析工具已经有非常广泛的使用,不过对于大厂而言用户数据非常关键,如果有能力还是建议自研,毕竟用户的行为数据是核心资产,将来可以基于这些数据做推荐、分析等等有价值的事情。

  Electron: 这玩意简直是做团队内部工具的利器,也是前端老手秒上手的东西,可以给团队做些玩意了。

  最后,我想说的是,各位同学,计算机科学基础很重要,学无止境,路漫漫其修远兮,吾将上下而求索,这是我对未来,永远的心态;

  终上所述,未来浏览器越来越重要,web os的概念正在慢慢落地。另外三大框架趋于稳定,写法上也越来越像,学习成本是降低的。但周边应用层面的封装还会是爆发式增长,更多复杂的细节会背包装到应用框架里,可能还有很多不一样的开发方式需要大家熟悉。

  写在最后大前端的技术非常繁杂,由于个人和团队精力有限,总是有不少遗漏还需要各位小伙伴们补充。对于各个技术所处的采用生命周期也限于个人的体验,总是难免有些争议,我只能尽可能做到相对合理。将各个技术放在不同的生命周期中,本意不是去贬低某项技术,其实恰恰相反,能够出现在Laggards周期往往说明这个技术得到岁月的洗礼,经过长时间的验证。只是一个时代总是有一个时代主流的技术,这个总结期望大家能够不断自省审视当前的技术栈,保持在业界主流对于未来项目维护、吸引人才都是很有帮助的。无论什么样的技术总会有过时的那一天,身为码农还是要持续不断学习,不要仅仅修炼术的方面停留在各种技术的使用之上,还要多多修炼道的方面,能够拨开技术的表面,看清它背后的原理以及解决问题的本质。已经写了不少了,大家也看的挺辛苦的吧,由于个人精力有限并且结合当前团队情况,一定有不少缺失,欢迎小伙伴们补充。有兴趣同学可以关注微信公众号奶爸码农,不定期分享关于投资、理财、IT的信息

  :因为在 AI 来临的时候,我们能否从一个 Design 变成一个 Code?今天每个公司的前端都有大量的设计、大量原代码,我们通过大量设计稿和原代码进行机器学习,让中间的布局可学习,让中间的元件可学习,我相信未来 D2C 一定能够解决前端生产力瓶颈,让前端从今天大量低端开发、手工工作中解放出来,将精力转移到很多领域深度的参与、深度的突破。

  我以前很少写这种规划,因为总担心计划赶不上变化,但是我也每年关注着前端趋势,学习了不少东西,还算是这几年技术上没有荒废。

  其他的还有黑马 Vuex ,没有投票选项,但被提到最多,得去看看它的 State 管理设计跟其他的有什么不同。然后最近很火的 Flutter 也可以关注下,但从 RN 的实际数据和市场来看,个人保持中立偏悲观一点点,但还是要了解至少做点 Demo 调研一下。国内市场小程序挤压原生应用,这又是要用 Dart 新的语法来开发,不好说在国内的前景。

  不过我这里提到 TypeScript 是想邀请感兴趣的朋友深入浅出一下 TS 的类型系统,蛮有意思的。这些不一定能在业务中用到,但是做 infra 的朋友可以用上,用类型约束来帮助梳理抽象设计,增强代码的健壮性与可拓展性简直再好不过。

  新项目是团队第一次脱离 node 进行后端开发,而且属于内部项目,所以后端的选型其实是很 open 的,其实抛开 Java 之后能做企业级 web 开发的语言真的凤毛麟角了,小众语言比如 Scala(据说 Twitter 在用)一是上手难度大二是小众语言的各种通病,平台语言比如 c#,虽然微软改过自新了,但是互联网公司基本很少用了,各种脚本语言首先就没考虑过,最后一看就剩 golang 了...

  计算机基础很重要,要不工作永远是学个语言调平台api,没意义,且不可替代行太低。

  Mobx是一个非常轻量级的状态管理框架,引入了observable state、computed value,极大的简化了状态修改的方式,相对于Redux减少了不少模板代码,上手迅速使用友好,不过由于缺乏Redux这类的强制规范,需要在使用中进行必要约束。dva是蚂蚁金服出品的数据状态管理框架,dva=React+Redux+Saga,通过约定大大简化了编程体验,值得持续关注。状态管理不是每个前端应用都必须使用的,要结合自身业务复杂度来决定,只有业务逻辑有一定复杂度需要做到各个模块解耦才考虑采用,如果一个Todo都用上Redux,我怀疑你是在炫技~

  WASM: 开始开始玩玩,目前 C / C++ / Rust / Go 都已经支持了,注意,只是玩玩就好,总感觉这不是前端的主战场,而是那些系统开发程序员的世界。如果你可以玩得很溜,可能你已经不是前端了。

  GraphQL好像还可以。那么GraphQL的核心是什么?是游说能力。你想实践它,最重要的是你得游说各方完成技术改造,把GraphQL架起来,落地到项目中去。

  中后台的重塑针对中后台业务特点,缺乏详尽的交互设计,缺乏足够的前端资源,页面样式相对统一,业界提出通过少量代码或者无代码方式搭建中后台前端系统。目前有的一些最佳实践:Fusion Design,飞冰,Ant Design Pro。大家都是从几个方向去实现中后台前端系统的无代码化,Ant Design Pro基于Ant Design提供了一整套中后台的网站框架和页面模板,对于快速搭建很有帮助。Fusion Design和飞冰是通过打通设计和编码环节,直接从sketch文档导出相应的页面代码,也是极大的释放了前端同学码页面的工作量。

  AI、数据可视化、交互体验 blabla 之类的领域知识也是技术规划的一个很好的部分,事实上我一直很推崇领域知识的交叉,也大概源于我内心中的那点『古典主义开发者』的情愫吧 。

  首先先说明一下,最好的技术规划是要结合自己的兴趣和工作内容,这两者越贴合,你的收获(技术深度 和 薪资 以及 心理舒适度)就会越高。这里仅给出一些从投票里得到的一些结论。

  当然上面的一些想法非常不成熟,只是一点点直觉判断,因此最近在读《Reactive Design Patterns》,准备恶补一下相关知识,妥妥的 2019 前端技术规划。

  至于团队,还是希望小伙伴们能保持对新技术的好奇心,勇于尝试,参与和推动前端行业向前发展。

  前端对于 Flutter 的热忱度之高一度让我有点惊讶,事实上我在 Flutter 社区内见到的客户端开发者远多于前端开发,不过前端对于跨端解决方案确实有着天然的渴求。

  当然,Deno 距离真正的生产环境还是有些遥远,不过作为前端技术规划,我非常推荐去了解一下 Deno,趁着项目不大,可以好好学习一手大佬们的系统设计与适度抽象的能力。

  工程化提到工程化先拿腾讯直播团队分享过的一张图来镇楼,很多小伙伴会狭隘的认为工程化就是webpack或者gulp打包而已,其实这个应该涵盖从项目创建、开发、编译、打包、测试、发布、监控全流程。

  数据层:Redux 目前用户很多,但是 React 新的 Hooks 等不知道会不会在来年给它带来影响。但是 GraphQL 和 Apollo 这段时间一直被讨论宣传,调查显示有非常多的人想要学习了解,虽然之前在实施落地总有各种困难,不过还可以再关注下吧。

  - 强运营背景下,移动端以前端开发为主,已成定局。Flutter局势暂不好说,观望(主要是不喜欢Dart)。

  你看,2019年的这些前端新领域,最重要的都是其中的“非前端部分”。所以我说,2019年,应该少学点前端,多学点重要的东西。

  从诞生之初,Deno就饱含争议。Ry 在 JSConf EU 上的《炮打 Node.js——我的第二个 JS runtime》(滑稽)分享掀起了国内的 Node.js 拥趸与反对者的舆论斗争,Deno 的 issue 区也一度被沙雕网友攻陷。

  2. RxJS 深入研究,是否可以为复杂的ToB应用带来更简化的解决方案;

  然后这个投票中国开发者比重很少,所以一些数据跟国内感官略有差别,主要集中在 Vue 上面,其他的数据应该问题不大。

  监控当老板给你发一个线上问题的截屏,你本地又无法重现,又没有足够的日志,这时候是不是郁闷,和老板信任的小船说翻就翻了。监控从能力来看分为几个阶段: 第一阶段:硬件运维能力,例如服务器运行情况,CPU、内存、磁盘、网络等等,在拓机情况下能够快速响应。 第二阶段:应用服务的监控,例如服务可用性、异常流量监控、页面接口的响应时间、App crash等等。 第三阶段:核心业务指标监控,例如业务核心链路数据同比环比的对比等等。 第四阶段:全链路的数据监控,从客户端、前端到服务层,到数据层,能够通过唯一id串联起来,可以方便回溯用户操作,重现问题现场。

  还是会深入的去Call Flutter ,用前端和iOS的视角去掌握它,我个人的观点它有可能是很长一段时间内最优雅的跨平台混合方案,值得拥有和实践下去。

  微信小程序: 上线了一个小程序,用 Taro 开发的,感谢京东团队,能让我用 React 开发小程序。

  :可以让前端更加贴近业务,可以让更多能力下沉。前端转到 Node 体系有一个很大的挑战,但是到了 Serverless 我们可以不用关注部署,不用关注运维,不需要关注所有的 DevOps,也不需要关注底层数据库的状态,他会让我们前后端整个的体系像前后端分层一样又往前迈一步。

  技术方向按照大前端技术架构图进行分层,大体分为:状态管理、UI组件、小程序、跨平台、框架层、编程语言、工程化、监控、测试和服务端。

  子曰五溪 厨子/骑行户外/程序员根据自己的目标把美食,程序员,音乐的专栏维护的更好,做下去

  前端想要学习的其他编程语言:Python 绝对第一,大数据处理、数据分析、人工智能加持。PHP 第二,符合预期。PHP 本来就极其适合 Web 的这种业务场景,前段时间为了积累各种技术栈的开发经验,用 WordPress + Node + React 重构我的博客,再次感受到了 WordPress 和 PHP 的强大易用,非常高效舒服的开发体验。据说 PHP 7 还有一些新框架给 PHP 带来了很大很好的改变,所以我真觉得 PHP 是世界上最好的语言(之一)。第三是 Java。

  前文有几位大佬已经提到了 WebGL , 今年大家都知道 5G 要来了,虽然手机到年底都还是零星的上市,还有很多基础的工作要做。但是作为享受 5G 红利的最优先无疑是更加高清的视频内容以及依旧保持增长的 VR 行业。

  不过说真的,如果你现在对分布式和k8s还不熟悉的话,你应该停止关心faas。因为基于node的faas服务体系,会被那些懂的人saas化,你就等着哪天打开网页写个函数点发布就完事儿了。

  3. 从业人员太少,用 node 的多,会 node 的少,这是 node 人才市场的现状,我在各个社区和博客上也能看到这种状态,太多入门级别的博客和讨论了,要么就是一小撮研究 V8这种屠龙之技的,绝大多数 noder 停留在增删改查上,现在是个 java 去面试也知道准备准备高并发的面试题,然后缓存、消息对列、多线程大家可以吹吹牛,要不弄个分布式系统设计的题,又没让人真设计,基本上听个思路,保证面试者至少有探究深度问题的欲望,有一定的学习能力,我 noder 的面试者听到直接傻了,什么高并发场景秒杀系统的?我大 node 天然高并发,无需考虑!wnmlgb!你家 cpu 爆的少了?招一个中等水平的 node 比招一个中等水平的 java 难太多了.

  5G 的另一个红利是 IOT,Web of Things at W3C虽然这也是一些小众的领域,但是依旧看好未来的发展前景, 借助 Web 的便捷性,可以在工业化监测,智能家居平台等都可以发挥一定作用。

  落后者(laggards):技术的落后者,长时间不更新技术栈,存在大量技术债

  三大框架: 自己一直是 React 技术栈,前一阵分别用他们实现同一个界面,顺便学习 Vue 和 Angular 我之前也写过回答 前端三大框架有哪些异同? - 一波不是一波的回答 - 知乎

  以上是我个人觉得这两年自己梳理的一些前端脉络,鉴于自己计划之后会比较少的做前端了,所以视野往别的方向看了看。

  另外一个原因是我老板(也是 java 出身的)提出来的,我觉得很有道理,Java web 开发事实上被spring 体系框架统治了,任何中级以下的问题没有 spring解决不了的,spring 屏蔽了几乎所有下层建筑,绝大部分Java 工程师被 spring 绑架了,甚至很多工作多年的 Java 工程师根本不知道 spring 的 hello world 怎么启动起来的,但是不妨碍他们用 spring 解决工作中一个又一个问题和需求,这不是工程师牛笔,是 spring 太牛鼻了,我们不得不承认,语言虽然是工具,但是工具是能教育人的,就比如拿着锤子看什么都是钉子就是这个道理,选择 java 被 spring 绑架是不可避免的,我们不能指望所有人都能从中跳出来(因为事实是大多数都跳不出来),作为团队的 leader 他更希望大家能有更好的成长.

  一个有趣的现象是在布局方面Flexbox使用率要高于Grid,可能的原因在于在低版本浏览器的支持方面Flexbox要更好,但其实在当前主流浏览器的支持度上已经没有区别。另一个因素可能是React Native也是推荐使用Flexbox来做布局,具有较大的群众基础吧。

  AI也是热门方向,TensorFlowONNX这些机器学习的库,有机会我还是想深入了解一下,寻找一些实用场景做些具体小项目。

  所以,很多前端开发者问 node 用不用学?我的回答是,一定用的,node 相关的开发工具生态已经跟前端绑定了,node 也是一门用于自动化的工具,node 的作用就相当于 Python 之于 java web 开发者的作用,甚至更重要,你也可以用 express 搭建一些简单的服务器,甚至用 egg 做一个正规的 web 项目,但是我不建议再在这方面进行进一步投入了,一方面上面这些 node 技能足够你达到一些大厂对于前端工程师的 node 技能要求了,没有人要求前端有很专业的 node 技能,普通的业务开发和一些自动化脚本开发绰绰有余,另一方面上面提到过了,node 限于人才生态、技术生态、教育生态,进一步的投入产出比太低,如果真的对服务端开发感兴趣或者想转到服务端开发上来,Java 是首选

  CSS Houdini提出了一个前无古人的的设想:开放 CSS 的 API 给开发者,开发者可以通过这套接口自行扩展 CSS,并提供相应的工具允许开发者介入浏览器渲染引擎的样式和布局流程中。简单的说houdini可以让大家去写css 的polyfill从而极大的改善css新特性引入的速度。不过讽刺的是,它本身也需要浏览器支持,w3c标准还处于working draft,大多数浏览器都还没很好支持,大家可以期待一下~

  三年前由于转到前端开发这方面,也顺便学了 node,因此放弃在 Java 方面的学习了,毕竟 node 之于前端开发算是兄弟级别的支持.

  一晃眼2019年已过大半,年初信誓旦旦要学习新技能的小伙伴们立的flag都完成的怎样了?2019年对于大前端技术领域而言变化不算太大,目前三大技术框架日趋成熟,短期内不大可能出现颠覆性的前端框架(内心OS:出了也学不动了)。本文结合个人和团队经历对2019上半年做个技术总结,将各类技术框架/语言/工具分作两个维度:

  Java 后端的体系无限庞大(包括 jvm 生态),优点是你碰到的99.99%的问题都有解决方案,缺点是一入 Java 深似海,包括一大堆配置、ide、插件、设计模式、n 种库,年前我专门做了内部分享介绍 Java 体系,主要面对没有 Java 经验的开发者的指路分享,分享结果是大家表示前端的体系都快学不动了,spring 全家桶能避就避.

  测试这里通常指的是自动化测试而非手工测试,从测试覆盖范围可以分为单元测试、UI测试、接口测试和功能自动化测试。我所经历的公司或团队,几乎没有能把自动化测试能够做好的,时间和需求频繁变更往往是最大的借口,不过程序员内心都不愿意写测试用例的吧(手动捂脸)。从落地难易程度来看,接口测试和单元测试最好落地,接口不说了难度不高收益还不错,主要需要对数据准备有些要求。单元测试首推Jest,同时还能统计出覆盖率,但是单元测试要明确好可以测试的范围,一般业务逻辑和底层通用方法比较适合。所以业务逻辑代码从UI层代码抽离非常重要,这时候redux这类状态管理框架就有了天然优势了,里面reducer、action部分就可以单测覆盖。UI的测试一般对于组件库有点帮助,简单的做法就是通过snapshot进行dom对比,简单粗暴。功能自动化很少能够落地,appium或者selenium都是其中翘楚,需要看业务情况,如果有频繁页面改动,一开始功能自动化写的爽,后续维护成本大的惊人,而且由于功能覆盖时间差,还是需要大量手动测试的。

  TypeScript是作为2019年的编程语言的大黑马受到极大关注,现在有大量框架例如Mobx、Vue3.x都是用TypeScript进行编写,由于TypeScript引入类型能够做到静态检查,因此解决了大量JS运行时类型错误,对于大型项目的代码安全性有很大的帮助。引入TypeScript需要团队对于新的特性有充分的了解,好好利用其中的精华,否则就会变成仅仅把.js后缀改成.ts而已。

  我之前曾在前端工程师学哪一门非脚本语言帮助最大?这个问题的回答中列举了学习复杂编程语言对于前端开发者的几点好处,现在的我仍然坚持当时的观点,并且我还是坚定不移地推荐 Rust。

  恰巧最近@传说中的洞洞在做流式计算相关的工作,和洞叔促膝长聊了一晚上,心里朦朦胧胧有了点感觉,大概是因为同步的 block 带来了异步的需求,而异步是 event based 的。这种事件触发编程模型在代码上呈现的特点是物理排布与逻辑时序性(timing)的分离,而 reactive 则是显式的将这种 timing 给重新暴露给开发者(其实就是将 continuation 用 pipe 的形式表达),并且试图解决一系列的 reactive 带来的需求,如 back pressure,flow control 等等。

  2 .缺乏业界实践,node 已经快10年了,在业界依然难以独当一面,绝大部分大厂用于中间层改造或者一些边缘服务,我现在找不出一个大厂用 node 做主力开发的,暂且不提 Java c# PHP这三大最主流的 web 语言,Ruby Python 在业界实践也远多于 node,当然这些语言比 node 的年龄要大不少,但是几乎同时期诞生的 Go 这几年的发展却有目共睹,靠着 Docker 加持现在在云服务市场呼风唤雨,node 现在依然被大厂安排在一些边边角角的工作中,缺乏业界实践的后果很严重

  我特别反感很多人说“前端娱乐圈”这种用词,诚然,爆发式增长必然会带来焦点,但也不必过度解读,2018年的几件大事儿我都了解,真的不是大家看到的那样的。学会辩证的看问题,用心去体味背后的趋势,我想这比所谓的“正直”更有价值,我更希望大家能够坚持学习,保持思辨和平和。

  所以typescript的核心,就是要研究怎么能写出让人“卧槽”的泛型代码,顺便研究一下ts的ast,看看能不能搞点勾当。当然我是开玩笑的,不过前端基本上只有两种人——了解静态类型的,0成本引入ts,不了解静态类型的,离ts还很远,用了也是瞎用。

  微信小程序: 随着各种方案(mpvue 、Taro等等)出现,我觉得微信小程序对于前端老手来说已经是一两天上手的事情了,2018 年后半年又支持云函数了,更是前端的福音,你要还没上手,可能会有点落后了。

  对了还有flutter,挺火(热更新没消息,好像大家都比较失望)。flutter的核心是什么呢?我做个不负责纯猜测啊——

  1. 开始考虑上微前端,目前一个模块的代码已经超过7万行,需要每个模块支持独立仓储,独立开发,独立部署;

  - serverLess在前端越来越受欢迎,除了能完成api proxy,bff这种功能外,还可以减少前端运维成本,还是可以期望一下的

  经过了这几个月的观察,我觉得吧,2019年前端规划的主脉络,就是“少学点前端”。

  。怎么说呢,我觉得框架只是工具而已,我自信我可以都可以用他们写出漂亮的代码。大家不要再争了,有空多看看书吧

  可能在学习 Rust 的过程中会遇到不少困难,它的学习曲线确实比较大,但是我相信,单从语言角度能获得的受益就是相当不小的。另外,Rust 虽然定位是一门系统语言,但是其实在 Web 领域已经是老熟人了(毕竟是 Mozilla 出的),大热的 WebAssembly、Deno 等等都可以和 Rust 产生联动效应,未来可期。

  怎么用好像不太重要,反正dart那么简单,flutter的模型也跟mvvm差不多。真正重要的,是你得读一下flutter底层的源码。因为flutter是前端runtime多元化的一个重要节点,没准儿以后裁剪和改造的工作会比较流行。rn和weex的封装,相对来说比较表层,所以深度改造的空间其实不大,但是flutter不同,它有可能在iot时代像linux之于嵌入式一样,成为“前端runtime之母”。

  很显然要做到监控这四个阶段需要做大量的基础设施,往往大厂都有一套完备的轮子。对于小团队而言,采用开源方案能够快速补全能力。

  今年事儿特别多,从React v16普及,到jQuery被github下掉完成阶段性历史使命,在唏嘘之外,版本帝ng又发布了6和7二个版本。这些其实都不算啥大新闻,反观三大框架,写法越来越像,越来越贴近WebComponents标准,而周边应用层面的封装已经开始指数级增长。小程序是今年最火的技术,接连出现,快应用也想分一杯羹。pwa进入稳定期,尤其是pwa桌面版,可以让我们更好的看清楚pc桌面版开发的全貌。移动端还是以强运营为主,各大公司都开始不在allin移动,开始重视多端并进,到了开始拼细节的阶段了。TypeScript全面开花,GraphQL蠢蠢欲动,WebAssembly更是打开了浏览器上多语言的大门。所有的这一切都在暗示,浏览器即操作系统,你能想象到未来前端的样子么?

  Java 这个生态不仅是技术上的,更是人才市场上的,也是教育上的,我很明白一些 noder 面对什么并发、性能优化、分布式、消息等问题基本是一窍不通,如果没有其他后端语言的从业经验,node 相关的书、教程、项目根本没有相关的场景,一脸懵逼是很正常的,一个 java 初学者想进阶,起码有海量的进阶书或者视频,十年了,市场上有一本讲 node 处理高并发场景的书吗(高并发可是 node 的卖点啊)?我看到的是一大堆搭建聊天室、搭建博客的书,有一本朴灵的书算是进阶的,但是已经 n 年没出第二版了,说句难听点的,node 市面上的书绝大部分还比不上 egg.js 文档的深度.

  UI组件在前端三大框架还未一统江湖的时候,组件库百花争鸣有Dojo、Bootstrap、Extjs等等。自从React横空出世,组件化变成了前端开发的标准模式,同时也应运而生了两大UI组件库:基于React的Ant Design和基于Vue的ElementUI。作为两大成熟UI组件库,如果你的系统是属于中后台业务,对于UI定制化要求不那么严格,那么这两个一定是不二选择,两者功能上没有太大区别,基础UI控件、多语言、主题配置等等要啥有啥,唯一的风险就是圣诞节给你来个下雪的彩蛋(政府网站高危预警)。UI组件库可以持续关注Web Components,毕竟是Chrome浏览器亲生的,背后有Google这个老爹撑腰,而且现在React/Vue不也变的越来越像Web Components了吗? 另外前端数据可视化、3D化也是一个很好方向,一些酷炫的前端库小伙伴们可以撸起来了~

  JS 后端框架:还是 Express 一家独大,其次 Next.js 想学的人比较多。Koa 在国内的欢迎程度比较高(当然由于样本小,也有可能是误差)。不知道为啥,国内比较知名的 Egg.js 和 Think.js 等都没有踪迹。。。缺乏国外的宣传吧。

  TS 在我眼中已经不应该作为 9102 年的前端技术规划了,就像梅老板今年不应该去拿金童奖一样...需要用,想用的朋友早就上了 TS,不需要用的那其实也没太大必要强行用。当然从客观上,TS 会具有一些 JS 没有的优势,这一点其实很多人在几年前就详细探讨过了,这里就不再赘述。

  总得来说,Flutter & Dart 整体学习成本不会太高,而且与前端生态有一定关联,是跨端的一个方向,但是目前的问题仍然多多,比如老生常谈的性能、包体积、AOT 问题等等。而且中文资源相对匮乏,英文资源也够呛,一些涉及到底层的需求只能老老实实去读源码,或者用邮件套套瓷了。这里就推荐一下@闲鱼技术的专栏,闲鱼算是国内比较早深入使用 Flutter 的团队之一,一系列分享含金量比较高,值得安利。

  :今天阿里的前端我们做了叫工程中台,工程中台做到了前端代码从提交到发布的管控,当然包括中间提交之后整个代码的编译、构建、检测以及发布。但是在前台的部分,每个团队都有一个工具,而这个工具在各团队之间割裂的,无法复用。因为工程不仅仅是提交到发布,前端工程化应该从编码开始到发布,应该是一个完整的链路、完整的格局

  1 . node生态不健全,讲道理 node 生态这几年基本没有什么大发展,npm 包是一天比一天多,现在貌似80多万了?重量级的项目却不见多,轮子很多时候有是真有,用是真不太好用,问题也就是缺少大厂的支持,很多轮子都是个人开发者或者小作坊的产物,Java 的生态就不多说了,只要你缺轮子,一定有大厂或者 xx 基金会的靠谱轮子等着你,质量数量都是独一档的

  上面写的东西主要是对棒棒的答案们的一个总结和个人的感受。不过对于我自己而言,2019 还有一个小小的计划,就是多多学习如何做合适的抽象设计。

  前两天 D2 和 SEE 大会给了我很多灵感,如果你一直想追寻新的规划,我个人强烈推荐去阅读这两个大会的 PPT 或者 观看视频,人工智能离我们真的越来越近了。

  - 5G时代快了,互联网的长期在线情况有可能会被打破。本地设备即客户端,可以大胆的想想。对前端来说,本地web服务,辅助日常开发,类似于je这样的模块会越来越多。

  微信小程序没什么好说的,接口和 DSL 设计确实值得商榷,Taro、wepy 之类的走一个?其实我不是太推荐使用这种适配的框架,因为出了 bug 比较难定位是框架层还是原生层出了问题,而且小程序开发者社区是有开发同事在值班的,对问题的响应会快不少。但是如果确实用不惯 native 语法,或者是有复用的需求,那上适配框架完全 Ok。

  去年我花了一两周时间,对 Flutter 的宿主语言 Dart 进行了一些简单探索,和开发团队在邮件组和gitter简单聊了一下,看了下Dart VM的源码,单从语言的角度来看,很 Google —— 足够现代,足够工程化,就是有点无聊 Orz。另外 Dart VM 的开发团队就是 V8 的传奇 leader Lars Bak 主持的,值得信赖。

  早期大众(early majority):技术早期大众使用者,深思熟虑者,往往采用相对成熟的技术

  - Webassembly让更多语言可以运行在浏览器上,AutoCAD的web版是非常好的例子

  仔细地读了下大佬们的回答,发现有几项技术被提及率很高,恰好我接触过其中的一部分,就大概来聊一下我对这些技术的认知,以及引出来相应的『2019 前端技术规划』。

  在2019 stateofcss也有关于CSS特性使用情况的统计,每个特性的外圈代表听过过的数量,内圈表示真正使用过的数量。

  都2019年了,你再谈什么框架,什么数据流,什么表单,组件库,已经没有什么意义了。一来是技术已经成熟了,不会有大变动;二来是大家都会,已经从知识退化成常识的东西,你再讲,还有谁听呢?

  这个目标有点虚无缥缈,但是每每看到比较优秀的设计(比如 React 的 hooks),我都羡慕地不行,内心总在嘀咕:他们为什么能想到要这么设计的呢?当然想要达到这个目标需要很多的积累,甚至需要来自编程领域之外的帮助,只能走一步看一步啦,希望有经验的大佬可以指点一二鸭!

  我认为我们做前端规划的时候,千万不能只把眼光局限在前端本专业技术上。还应该多考虑一下:

  谢邀,抛砖引玉,也许会有偏差,因为我主要关注点还是在混合跨平台方向和前端方向;

  Vuex作为Vue框架的状态管理的不二选择,核心思想和Flux/Redux一脉相承,弱化了Reducer的概念而改用Mutations,使得整套框架更易于理解了。

  晚期大众(late majority):技术的平民老百姓,跟随趋势采用当前主流的技术

  语言语法层面:ES6 不说了标配各种特性要熟练掌握应用,TypeScript 是越来越火潜力很大,值得了解、学习。

  Rx.js 在前端的应用已经被知乎各位大佬安利过很多次了,但是我一直很疑惑:为什么在前端中使用 reactive 是这么的自然?reactive 到底要解决编程领域里的什么问题?

  我之所以把 WebAssembly 归类到运行时(runtime)里面而不是编程语言里,是因为目前大家可能更关心 WebAssembly 带来的性能提升,而不是具体的语法,因此就把这一条列在了运行时中。WebAssembly 能带来可用的性能提升已经是不争的事实了,在不需要考虑兼容性的情况下,尝试一下这种性能优化是一种不错的选择。

  重读两本书《TCP/IP 协议》和《操作系统原理》,买了一本书安全相关的书,在前端这个领域里面把安全能了解的更全面,把《图解密码技术》阅读完

  来自statesofjs的统计,在类JS编程语言上,ES6遥遥领先,TypeScript也获得接近半数的使用量。其次是Flow、Reason、Elm和ClojureScript。目前主流编程语言已经是ES6/7+Babel的组合,用过ES6/7后基本没法再回到原始的ES5时代了,出现了类和模块的概念方便JS代码模块化加载,再加上各种语法糖用的快乐的飞起。async await的语法也替代promise的写法,使得代码逻辑变得更加简洁。ES的规范依旧在快速迭代,每年都会出一个更新的版本,引入不少语言特性,同时有Babel加持可以将新的语法都转译成ES5版本运行在浏览器中。

  上面是可预见的在 2019 依然是前端热门技术点的名词,但是,并不是每个团队、每个人都需要的。

  项目初始化项目脚手架目前已经非常普遍,例如create-react-app或者vue-cli都是官方标准的脚手架工具。对于一些稍大的公司都建议自己包装一套自己的脚手架,这样可以沉淀很多最佳实践,例如工程目录结构、lint配置、监控配置、打点配置等等,因此脚手架是落地前端架构标准化不可或缺的一环。

  - pwa平稳发展,兼容4/5浏览器,workbox 3进一步简化开发,另外pwa桌面版已经开始兴起,未来会更多

  3. 性能优化,新的模块采用 Angular 的 OnPush 模式,让前端性能更好,当然默认的方式目前一个页面没有同时展示几千个任务时没有性能问题;

  学习成本相对来说不太高,小程序生态最近也在加入更多 AFE(Augmented Front-End)能力,比如内容搜索、Faas 等等,而且微信开放平台一直鼓励优质的独立原创内容(应用),有了 idea 不妨来试一试呢。

  一是我在ppt里展示了一点我为了实现类型推导,写的那种让人“眼花缭乱”的泛型ts代码,大家对这个感兴趣,来问我那是什么鬼,项目里那么写为什么没被打死。

  Chrome Extension: 公司开发了一款 Chrome 插件,自己也开始了解这个生态,写了一本小书写了一本 Chrome Extension 小书 · Issue #39 · riskers/blog

  :可以看到整个搭建服务无论是在中后台还是整个无线端,以及 PC 端都有大量场景,这样大量场景需要把整个框架标准化,希望把里面的元件、组件以及模块标准化,还希望把这样的服务能够服务于今天所有无论是中后台也好,C 端页面也好,希望有这样的体系——服务化标准化的方式服务,打通整个体系,这就是为什么把搭建服务认为是面向未来最重要的方向。

  其实CSS特性的使用覆盖面很大因素取决于浏览器的支持程度,浏览器支持越好越容易获得更高的使用率。可以看到几个高使用率的CSS特性在浏览器支持方面都非常好,除去Opera Mini和少量IE11,其他主流浏览器都能完美支持。

  三年前开始用 node,现在基本上只用于前端工具的开发和一些自动化脚本(基本上代替了 Python 在我开发中的地位)

  Redux=Flux+Reducer,由于Store的唯一性加上Reducer纯函数,使得数据状态具有可预测性,于是配套出现了很多基于TimeMachine机制的调试工具,极大的提升了研发调试效率。不过由于Reducer的纯函数性质,对于一些异步请求的副作用又要引入中间件,导致了一定的复杂度。

  typescript好像也可以,19年有普及的趋势。那ts的核心是什么呢?正好前一阵我做了一个技术分享,话题就是typescript的一些实践心得。结果讲完之后,发现后续跟我来讨论的人,主要就对两件事儿感兴趣:

  框架层面:React 用户最多,满意度也高会继续使用,Vue 潜力大,想了解学习的多。Angular 的“用过但是不想再用“的比重又大了,可以自行决断是否要学习(订正:为什么 Angular 的「弃用率」远高于「继续使用率」?此处统计数据可能存在误差)。

  服务端自从出现Node之后,前端技术正式进入服务端开发,从而让前端的小伙伴们可以进行全栈的开发,技术栈的范畴变的更大,对于业务的把控能力也变强了。Node可以带来几个明显的好处第一,可以作为BFF(Backend for Frontend)层,解决前后端接口频繁变更的问题,通过BFF层可以实现更加灵活的接口,接口字段的过滤,接口的聚合等等 第二,可以用做SSR(Server Side Render),通过Node层同构直出,可以将前端渲染代码放在服务端,实现首屏的服务端渲染,提升首屏渲染时间 第三,基于“只要能用JS实现,最终都会用JS实现”定律,Node让前端同学可以用JS撸后端代码,这个掌控一切的感觉太爽了~Node也存在一些缺点第一,需要额外的服务器,很多场景下Node层仅仅做接口透传的工作,对于服务器是一种浪费,而且作为一个核心节点如果一旦挂掉整个应用都不可用 第二,需要对Node服务有一整套的打包、部署、监控等能力,这个对于前端同学来说提出了较高的运维能力的要求,这些事情往往让前端同学苦不堪言服务端最近可以持续关注GraphQL/Serverless,这两项技术对于前后端的架构设计都会带来深远的影响。

  rxjs: 自2017年『入门』两次之后,2018年又一次入门,这次觉得真的入门了。这次是看@程墨Morgan大佬的书入门的,感谢。现在自己也在慢慢写一个笔记总结riskers/rxjs-note

  还有,前两天 D2 和 SEE 大会,有大量数据可视化和分析相关的分享,以及“人工智能”将设计稿转代码之类的分享。可以简单的得出结论,大数据分析和人工智能运营后台等富数据展示和交互的业务、需求在变多,简单低端的前台切页面之类的任务将减少人的投入。再进一步,低端切图可能失业,前端可能开始重业务逻辑开发,然后对人的数学以及算法啥的要求会有提高,个人愚见。

  或者你换个冷门领域,难道就有人听吗?一样没有。webgl,做图形的人早就滚瓜烂熟了,现在还不会的,那就是用不着的。wasm,除了那些往浏览器里面编译视频解码器的人,还有谁用啊?

  框架层上半年框架层没有太大变化,依旧三大前端框架把持:React,Vue,Angular。从团队使用情况来看,React、Vue依旧是主流,Angular似乎慢慢不那么受待见,也许太难学了吧(手动捂脸)React 16.x上半年发布,推出了不少新特性,例如hooks、lazy、suspense等等,如果是React技术栈的同学鼓励第一时间进行尝试。hooks还需要再多多实践,整体实现理念和原有class方式有很大不同,习惯了原有的生命周期的写法的同学还需要适应。Vue 3.x难产至今,根据路线会有大量的更新,比如virtual dom的重写、框架会更小更快、全面拥抱TypeScript、使用Proxy来实现检测机制等等。呼唤尤大大赶紧更新,vue的同学恨的牙痒痒的,下半年的KPI就指望这个啦~Angular近期没有太多关注,不过Angular是一个真正意义的MVVM框架,不比React或者Vue其实都是View框架,所以这是一个大而全的框架。但是团队方面期望技术栈进行收敛,所以这方面就没有太多的投入了。在框架层,可以持续关注PWA和WebAssembly,PWA对于弱网环境的用户体验提升很有帮助,而且还可以作为桌面应用的技术框架。WebAssembly可以让前端在高密度计算性能上得到很大提升,不过应用场景有限。

  本地开发lint的规范一定要在项目初期就落地,可以直接拿airbnb的规范或者再定制化一下。lint可以极大的提升代码质量,至少从代码风格来看可以保证统一。Sonar的引入可以进一步提升代码质量,帮助分析出潜在的问题,同时分析代码的重复率,过长的高数等等,这些都是所谓的代码bad smell,如果任其发展下去,项目维护成本会直线上升。Mock工具的必要性在前后端联调时就能充分提现,很多时候由于前后端接口定义不清晰导致联调过程就是一个扯皮过程,如果缺乏mock工具,前端也会沦为后端接口调试的触发器,前端页面点一下,后端调试大半天,前端小伙伴们伤不起啊。Mock工具至少要有接口定义和本地mock的能力,能够极大提升大家研发体验。

  继续深入 React ,在业务层面把应用根据最新的 React 优化方案 执行下去。

  就 Flutter 目前的设计来看,和 React 生态有着千丝万缕的联系,比如天然的 Redux like 的状态管理解决方案,与 JSX 语法几乎一致的DSX,还有少不了的 pure functional 的气息等等。对于大多数 Reacter 来说,看到 Flutter 项目的第一反应,大概会是一个『了然于胸』的微笑了。

  小程序2019年小程序百花齐放,各大超级App都推出了自己的小程序应用,前端同学们要支持众多小程序,摸摸头发又稀疏了不少吧(em...离资深研发又迈出了坚实的一步)。小程序的实现有多种方式,需要结合自身的业务场景来做选择。 选择一,小程序原生开发方式,以微信为主开发小程序,再通过少量修改移植到其他平台(工作量多少没有做过不好估计,但既然当初支付宝小程序demo都抄微信的,感觉应该不大吧~) 选择二,H5内嵌开发方式,天然多平台跨端,但会有些许性能损失,也会有些功能限制,例如微信里面的消息通知不能通过H5来推送 选择三,mpvue这类基于某种框架的开发方式,mpvue就是基于vue框架来开发小程序,对于熟悉vue的同学学习曲线很低,同时也可以实现代码逻辑的复用 选择四,Taro跨多端的实现方式,支持用 React 的开发方式编写一次代码,生成能运行在微信/百度/支付宝/字节跳动/ QQ 小程序、快应用、H5、React Native 等的应用。对于功能需要同时满足多个小程序应用的场景比较适合。跨平台在Qcon分享 -美团移动端动态化实践中总结了业界和美团在移动端跨平台&动态化的实践,可以看到公司在跨平台&动态化方面进行了多维度的研究和投入,这样可以适用于不同的业务形态。

  对于开发者而言,唯一不变的就是学习能力。掌握了学习能力就能够应变。无论是在三大框架混战时代,还是后面周边封装时代都能很开心的“折腾”。哪怕有一天AI真的能够替人写代码,能应变的人自然也是不怕的。

  node 的有很多比 Java 更好的优点,例如天生异步,能抗住并发,Java 需要引入新库来达到相同效果,脚本语言猛糙快,在 spring boot 之前 Java 的配置比如今前端的 webpack 还要噩梦,小步快跑这几年一年能上两个大版本,当初的 Java 还是万年不升级,导致的就是各个公司版本完全断档,有些用 java8有些还在 java5.

  Cat是美团开源的业界良心监控方案,对于前后端都有不错的监控能力,数据收集也很完备,能够提供实时的性能指标、健康状况、实时告警等数据,在多家互联网公司也得到实践,实属拯救码农头发的必备工具,你值得拥有~

  前端技术栈标准化前端发展到现在,整个技术栈依旧处于百花齐放的阶段,但是对于公司或者团队而言,需要逐步从草莽时代走向正规军时代,这就需要在技术栈标准化上做一些事情。例如对于一个10人左右的前端团队而言,如果还是三大前端框架并存,那么技术沉淀、代码复用都无从谈起。所以对于一个前端团队而言,标准化的技术栈是非常重要的,需要统一的脚手架、lint配置、mock工具、编程语言、框架、监控等等。

  推荐关注等等,都是 TS 玩得比较 skr 的 young OG 了,专栏来玩TypeScript啊,机都给你开好了!也蛮不错,分享的文章都有一定的深度。

  自从移动端有了iOS、Android两大平台,在加上原有的H5 Web端,跨平台就成了这几年大前端最热闹的地方,毕竟一个功能实现三套换谁都不乐意干,于是在用户体验和研发体验中的一场拉锯战就开始了,各大厂商各显神通。最早出现的是Phonegap这类基于WebView的实现方式,由于WebView天然跨平台能力很好的解决了展示层的问题,然后通过jsBridge打通WebView和Native之间通信,使得浏览器中的H5代码也能有原生能力。这种方式研发体验最好,但是用户体验最差。然后就是React Native、Weex、Picasso,它们基于Virtual Dom或者模板语言,通过js代码编写UI,然后渲染成原生组件,完美了实现了用户体验和研发体验的平衡。但要用好这些框架还是需要对性能优化、差异性抹平、工程化有比较高的要求,小团队小公司慎用,否则入坑容易出坑难。今年大热是Flutter,可以持续关注,技术架构很优秀,野心很庞大,大有一统江湖的气势。跨平台热热闹闹多年,我个人认为当前的解决方案都是折中方案,随着手机性能逐步优化、浏览器原生能力的增强,也许大家都会回归本源,走上H5这条道路。

  Flutter: 继续深入下去是不得不搞 Native 的,所以如果不满足只做 UI 层面的话,是一定要学 iOS 和 Android 的,这样又是平台 API + 一门语言。门槛不低,成本不小。

  跨端框架:Electron 和 React Native 排前面,从 Star 啥的感觉挺火的,但其实用过的人才 20% 不到,这个比较不符合预期。但是想要学习的人是非常非常多的。估计绝大部分前端仍然还是 Web 方面的。当然今年 RN 发展很不顺利,被很多大公司移除掉了。在国内也有点尴尬,大公司不用因为他们自研框架或者原生开发,小公司现在也不做独立客户端了,都先搞个小程序来做业务了。以至于现在安卓、iOS 开发者生存空间都比较小了。。

  早期采用者(Early Adopters):技术早期采用者,具备一定探索精神,某个领域的意见领袖

  现在除了 Dart 只到了初级,Spring Cloud 只到了初、中级以外,其它都算是达到了高级或以上水平。

  CSS in JS的理念应该来自React Native,最开始接触的时候相当颠覆,在JS文件中直接写相应的CSS定义,使得组件内聚化达到极致,解决了css全局污染的问题。在web前端,css in js有很多的实现方式,但目前来看还是比较早期,传统的Less、Sass的这类css预处理框架已经能够比较好的解决一些问题,从编程习惯上也一脉相承,因此css in js理念不错,但要得到推广还需要时间。

  状态管理随着React、Vue这类前端框架的流行,组件化开发成为主流,然而随着页面复杂度越来越高,在一个组件文件中,要做UI渲染、事件处理、状态管理等等事情,于是一个文件变的越来越复杂。同时,页面组件层级变的复杂后,跨组件间的数据通信也变的很繁琐,需要将数据上提到父节点,通过property传输数据、回调方法更新父节点状态等等。Facebook首先提出Flux框架,引入单向数据流的编程模式,把Action和Store从View中解耦出去,极大的优化了原有状态管理的架构。

  不过抛去这些娱乐气息过重的表象,Deno 本身是有一定闪光点的。除了各种文章中老生常谈的优点,更简洁的 native binding 方式,更现代化的底层实现(基于 Rust),广泛参考优秀设计的新 IO 接口等等,都是值得关注这个项目的理由。

  二是我介绍了一点利用类型信息打通编码阶段和runtime阶段的技术,大家也有点感兴趣。

  PWA: 持续关注,不过这玩意其实真的很简单很简单,只要学会 Service Worker + Cache API 就算掌握了 80% 了,需要的时候再学也来得及。

(编辑:admin)
http://argentinet.com/qianduan/81/