跳至主要內容
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?

4563博客

全新的繁體中文 WordPress 網站
  • 首頁
  • 2021 前端会有什么新变化?
未分類
2021 年 2 月 4 日

2021 前端会有什么新变化?

2021 前端会有什么新变化?

資深大佬 : zzzzzzggggggg 13

2021 前端会有什么新变化,首先需要搞清楚我们关注这些新技术的目的是什么?

相信对于关注这个问题的人包括我来说,除了了解技术发展风向作为饭后谈资以外,最重要的是看能不能在公司内部落地、做出一番成绩来,当然升职加薪那都是后话了。

回望过去

首先定义一下我说的“过去”是 2019 年及以前。

以史为镜,可以知兴替。回望一下过去,有利于我们对未来做出更好的判断。我们先细数一下过去的几年间大厂的前端都在做什么。

前端工程化

这个应该是前几年社区讨论的最多、面试问到最多的一个名词,那么什么是前端工程化呢?我觉得需要从以下几个概念开始讲起。

模块化

先说 JavaScript 的模块化。

从 ES6 开始,JavaScript 语言有了自己原生支持的模块化方案——ES6 Module,这样有个好处,前端们不用去使用社区定制的模块加载方案,直接使用统一的就好。统一模块方案之后,既可以不用额外引入模块化解决方案的代码,又可以为后面的自动化统一处理做好准备。

再说 CSS 的模块化。

CSS 模块化主要是解决的 CSS 类名冲突的问题,比如常见的 BEM 约定以及社区丰富的 CSS module 解决方案,有了这些东西,前端工程多人开发就可以优雅的解决类名冲突的问题。

组件化

随着 React 生态和 Vue 生态在国内各大前端团队的落地,组件化开发已经是标配了,并且开源社区也沉淀出了以 Element 、Ant Design 为代表的优秀组件库。

大厂的程序员们在组件的概念上又做了一层抽象和封装,比如以业务组件和业务区块为抽象的中后台前端解决方案 Ant Design Pro,并且它还在前端工具库、前端 UI 设计语言等等方案做了统一。

自动化

首先是开发的自动化。

webpack 和 nodejs 在开发的自动化上起了很大的作用。前端项目本地化开发的 server 由 nodejs (常用,也不一定非得是 nodejs )提供,开发过程中的各种辅助性 plugin 和 loader 都由 webpack 生态提供,上线前的代码打包、代码分割、资源处理也由 webpack 操作,可以说过去几年间很多前端在职业晋升上都吃了引入 webpack 和 nodejs 的红利。

再说 babel,有了 babel 的配合,前端可以写高版本的 JavaScript 方法,配合 webpack loader,自动编译成低版本 JavaScript,前端能力再次得到提升。

其次是部署发布的自动化。

这个应该是很多大厂前端基建团队做的事情,比如持续发布、版本控制、内部 cdn 建设等等。

大前端

这也是个在过去几年炒的很热的词,不过这个词不仅仅是炒作,它也实实在在的扩展了前端的能力以及现有的公司组织架构,比如据我所知有的公司移动端和前端就会划分到同一个团队管理,统称大前端团队。

nodejs

这个在前端工程化部分已经说过一些,这里再次提起是因为在工程化中 nodejs 扮演的角色是提供 nodejs 环境以及部分后端能力,而在大前端团队里是实实在在的存在 nodejs 工程师角色和 nodejs 项目的。比如说在前后端分离的过程中,部分公司(比如阿里淘宝)会发展出一个中间层的东西,这可以理解为是一个大前端团队维护的业务接口聚合层,前端写接口肯定是使用 nodejs 最顺手,而且 nodejs 生态也在蓬勃发展,比如早些年的 TJ 大神一人之力扛起半个 nodejs 生态圈,涌现了 koa 、express 这样的基于中间件的开发库,再到后来阿里巴巴的 egg,再到 Nest.js ,现在基本已经没有裸写 nodejs api 的了。

跨端

先说说手机端

首先,最直接的跨端就是在 APP 壳子里面套 HTML 页面来开发,这种方案也催生了很多 hybrid 解决方案,前端也需要去了解客户端的知识以及 JavaScript Bridge 的设计,同时也减少了 APP 客户端工程师的岗位

大佬有話說 (88)

  • 資深大佬 : April5

    目前很心动 esbuild

  • 主 資深大佬 : zzzzzzggggggg

    @April5 JavaScript builder,比 rollup 还快,值得一试

  • 資深大佬 : jtsai

    Serverless 目前能做什么

  • 資深大佬 : Jirajine

    snowpack 、pnpm 、volta 、orogene

  • 資深大佬 : anguiao

    大佬的不了解是真的不了解吗

  • 資深大佬 : liuxey

    @April5 #1 这难道是 “‘Node’是有极限的,我不做’Node’了” 2021 前端会有什么新变化?

  • 資深大佬 : avastms

    前端先老老实实学会面向对象吧

  • 資深大佬 : azh7138m

    飞书的原生版本已经有了,不知道什么时候 GA

  • 主 資深大佬 : zzzzzzggggggg

    @azh7138m 貌似我当时在的时候还是 Electron

  • 主 資深大佬 : zzzzzzggggggg

    @avastms 那得先找个对象

  • 資深大佬 : tiglapiles

    denojs

  • 資深大佬 : lihongming

    作为 serverless 深度用户,我想说 serverless 其实干不掉运维,因为对于稳定持续大访问量的应用来说 serverless 太贵了,还是养个运维便宜。而访问量不大的小公司往往也没有运维岗,都是程序员兼任。

    serverless 的最佳场景是访问量不稳定的应用,比如很多 saas 每天就那么一两个小时忙碌,大部分时间闲着,此时用 serverless 就很划算。

  • 資深大佬 : betmargt

    前端太太太复杂了。。

  • 資深大佬 : nerocc

    2021 年可以关注一下,围绕着 Web Component 做出来的高性能框架。使用 houdini 的高性能动画效果。wasm 的框架比如 Blazor 。

  • 資深大佬 : murmur

    serverless 落地不是技术问题,是个博弈问题,大厂内部的 serverless 叫高度复用,小公司 serverless 那是把身家都交出去了

    不过 serverless 写作业不错,比如毕设要开发一个啥 app

  • 資深大佬 : MakHoCheung

    @azh7138m 真的假的,不跨平台工作量很大的喔

  • 資深大佬 : beginor

    期待三大框架能解决各自的模块化增量发布就好了, 现在每次 build 都要好久

  • 資深大佬 : rodrick

    低代码和无代码的普及还是很难的,现在能普遍应用的场景过于局限了,感觉很多都是一些后台管理系统之类且定制化不是很高的场合

  • 資深大佬 : basstk

    大佬的不了解可能是他不想去了解,而我的不了解,是真的不了解. -_-!

  • 資深大佬 : superBearL

    理想化:组件样式与位置完全拖拽,弱化 CSS,开发人员更专注于 JS 逻辑处理

  • 資深大佬 : corgiyun

    大佬们谦虚的话不要当真,他的不了解可能是相对的。所以…

  • 主 資深大佬 : zzzzzzggggggg

    @tiglapiles deno 这个没太关注过,能讲讲场景不?

  • 主 資深大佬 : zzzzzzggggggg

    @superBearL 你说的这个其实我在公司内部正在做,把产品分层考虑,原型+逻辑=产品,如果有好的逻辑描述 DSL,这部分工作完全可以交给外包。。

  • 主 資深大佬 : zzzzzzggggggg

    @corgiyun 反正面试顶多阿里 p6[狗头][狗头][狗头][狗头]

  • 主 資深大佬 : zzzzzzggggggg

    @rodrick 解决中后台增删改查场景以及部分流程化的场景还是可以的

  • 主 資深大佬 : zzzzzzggggggg

    @beginor vue3 貌似拆开了?

  • 主 資深大佬 : zzzzzzggggggg

    @murmur 所以现在各大厂的前端团队都在削尖脑袋想怎么落地

  • 主 資深大佬 : zzzzzzggggggg

    @nerocc 好的,我看看

  • 資深大佬 : myCupOfTea

    @superBearL 早就有了 https://www.framer.com/

  • 主 資深大佬 : zzzzzzggggggg

    @betmargt 还好还好。。这里面的会一部分就是大佬了

  • 主 資深大佬 : zzzzzzggggggg

    @lihongming 干不掉运维但是减少运维岗位,也算成功了哈哈

  • 主 資深大佬 : zzzzzzggggggg

    @anguiao 可能是,也可能是谦虚,不过我相信人的精力都是有重点的,要去学的话肯定是能学好

  • 資深大佬 : CQYJ

    现在前端都是向后端靠拢,以后是不是要吃掉后端 全栈?
    话说前端难道不应该是关注一下页面呈现和交互吗 以后干脆改个名字直接叫 web 工程师完事了 分什么前后端(手动狗头)

  • 主 資深大佬 : zzzzzzggggggg

    @CQYJ 其实我觉得最终的形态应该是产品开发工程师。。。。

  • 資深大佬 : chengxiao

    说的好 ,但是每次敲 npm install 都是心惊胆颤~

  • 資深大佬 : geektony

    Rust x WebAssembly

  • 資深大佬 : avastms

    @chengxiao 输入法每次给我补全 npm,你怕吗

  • 資深大佬 : robinlovemaggie

    Dan 哥强在融汇贯通而不是嘴强王者~

  • 主 資深大佬 : zzzzzzggggggg

    @chengxiao 哈哈,module 太多了吗?

  • 主 資深大佬 : zzzzzzggggggg

    @geektony Rust 有朋友在做,目前还没看到落地的

  • 主 資深大佬 : zzzzzzggggggg

    @robinlovemaggie Dan 哥是在某个领域钻的特别深的那种,其他的会不会其实无所谓

  • 資深大佬 : robinlovemaggie

    @zzzzzzggggggg #41 没错,蛋哥去年那个 Just Javascript 就真的很走心~

  • 資深大佬 : bleepbloop

    js 的问题是,很多库用着用着就不维护了,然后又有人重新造轮子

  • 主 資深大佬 : zzzzzzggggggg

    @bleepbloop 确实,能满足需求的轮子太多了

  • 主 資深大佬 : zzzzzzggggggg

    @robinlovemaggie Just JavaScript 有地址么?我看看

  • 主 資深大佬 : zzzzzzggggggg

    @robinlovemaggie 找到了

  • 資深大佬 : yaphets666

    @CQYJ 前端分几个方向 搞 js 的 关注性能 框架等等 搞特效的 关注 canvas webGL 等等

  • 主 資深大佬 : zzzzzzggggggg

    @yaphets666 是的,说的很正确

  • 資深大佬 : MorningStar0

    @avastms 如果是纯前端场景(不包含 node 接口部分),其实函数式的程序比面向对象,更适合描述 UI 和状态变化。

    比如一些低代码平台上,要实现可视化配置的交互事件链

  • 資深大佬 : connection

    期待变化与更多想法

  • 資深大佬 : nanxiaobei

    抵制 TS !有没有道友!!

  • 資深大佬 : robinlovemaggie

    @zzzzzzggggggg #46 当时是一个 mail list 形式的课程,已经结束了,现在订阅应该收不到邮件了。

  • 資深大佬 : robinlovemaggie

    @nanxiaobei #51 +1,不硬整天就想着把大家往邪路引~

  • 主 資深大佬 : zzzzzzggggggg

    @nanxiaobei 道友何出此言?

  • 主 資深大佬 : zzzzzzggggggg

    @robinlovemaggie 收到了,没具体的内容

  • 主 資深大佬 : zzzzzzggggggg

    @connection 一起加油

  • 主 資深大佬 : zzzzzzggggggg

    @MorningStar0 这个我做过,先把事件抽象成好几类,然后是组合、逻辑编排

  • 資深大佬 : KuroNekoFan

    @CQYJ 说是这么说,但是纯前端的能力是受限的(至少在浏览器这个上下文里),受限就表示,有些在页面呈现和交互有改善的点,纯前端做不了。

  • 資深大佬 : KuroNekoFan

    我个人是很希望 bff 能够广泛落地的,但是似乎需要很强的后端和运维基础设施作为前提
    比如我 bff 了,页面渲染卡了,算谁的问题?个人认为,什么时候前端开发者在引入 bff 的时候可以不考虑,少考虑这些问题,什么时候 bff 才能广泛落地

  • 主 資深大佬 : zzzzzzggggggg

    @KuroNekoFan +1

  • 資深大佬 : yngby

    主用心了

  • 主 資深大佬 : zzzzzzggggggg

    @yngby 没事,我后面还会继续写文章的,欢迎一起交流

  • 資深大佬 : gz65555

    bff 其实比较无聊。图形在前端的领域比较有意思,设计师对网页上的效果要求越来越高,WebGL 的使用需求也会越来越多。

  • 主 資深大佬 : zzzzzzggggggg

    @gz65555 WebGL 确实可以,就是一直没咋研究过

  • 資深大佬 : PlanZ

    React Server Component,仿佛绕了地球一圈,又回到了葡萄牙。
    但概念多了不止几倍,东西也越搞越复杂,从这个角度看,其实违背了前后端分离的初衷?

  • 資深大佬 : HALOZ

    要么深,要么广。

  • 資深大佬 : mostkia

    前端无非就是不断造轮子,一层又一层封装。。玩来玩去,解释器还是 JavaScript 。。我就 jquery 一把梭[doge]

  • 資深大佬 : CodeCodeStudy

    前端太多新概念,新花样了

  • 主 資深大佬 : zzzzzzggggggg

    @PlanZ 概念确实很多很绕。。。但是从前端的角度来看,确实把前端的能力拓展了

  • 主 資深大佬 : zzzzzzggggggg

    @HALOZ 个人觉得,深比较重要

  • 主 資深大佬 : zzzzzzggggggg

    @mostkia 换个角度来说,其他语言最后也都是个二进制。。。

  • 主 資深大佬 : zzzzzzggggggg

    @CodeCodeStudy 唉,找自己感兴趣的做吧,不一定都会,做好一个方向就是大神了

  • 資深大佬 : RickyC

    这些前端技术都适应不了搜索引擎吧?
    要想搜索引擎很好地收录, 就得老老实实用后端写吧?

  • 資深大佬 : RickyC

    我不喜欢这么解释”前端工程化”
    我希望解释为: 用 Vue, React 等, 并编译执行.
    自古以来就有故弄玄虚的人.

  • 主 資深大佬 : zzzzzzggggggg

    @RickyC 适应搜索引擎的重点不在于是前端写还是后端写,而是能否给搜索引擎抓取到内容和关键词,之前的解决方案是直接服务端渲染为完整的 HTML 来供搜索引擎抓取,以后如果搜索引擎可以对单页应用做比较好的解析,SEO 问题就解决了。

  • 主 資深大佬 : zzzzzzggggggg

    @RickyC 如果没有 Vue 、React,前端工程化依然是前端工程化,nodejs 在这里面的价值更大一些

  • 資深大佬 : RickyC

    @zzzzzzggggggg 我如果服务端渲染, 为什么不直接用 PHP 来写?
    前端工程化的优势不就是分散运算力, 减轻服务器的压力吗?

  • 主 資深大佬 : zzzzzzggggggg

    @RickyC 直接用 PHP 写那不就成了之前前后端未分离的那一套了么?现在服务端渲染是前端生态的一部分了,框架相关的 vue 生态有 nuxt.js ,react 生态有 next.js ;前端工程化的优势是解决前端从本地开发、前端资源管理、打包、持续集成等等一系列的自动化问题,跟分散运算力关系不大

  • 資深大佬 : RickyC

    @zzzzzzggggggg

    要么前后端分离; 要么抛弃现有搜索引擎; 二选一;
    对服务端渲染尚不理解.

  • 資深大佬 : RickyC

    @zzzzzzggggggg 如果您说的”解决前端从本地开发、前端资源管理、打包、持续集成等等一系列的自动化问题”指的是前端程序员不会后端语言, 所以用服务端渲染, 我并没有看出其中的价值所在.

  • 主 資深大佬 : zzzzzzggggggg

    @RickyC 你没太理解我的意思。”解决前端从本地开发、前端资源管理、打包、持续集成等等一系列的自动化问题”解决的是前端工程化开发的问题,前端常常使用 vue 、react 开发的单页应用会存在搜索引擎 SEO 的问题,为了解决这个问题,vue 和 react 分别推出了 nuxt.js 和 next.js 来做服务端渲染,解决 SEO 问题。
    不晓得说清楚了吗?

  • 資深大佬 : RickyC

    @zzzzzzggggggg 您很耐心. 但是为什么不能用 PHP 直接写呢?

  • 資深大佬 : RickyC

    @zzzzzzggggggg 那请问 nuxt.js 和 next.js 对用户和搜索引擎是区分的吗? 对搜索引擎使用 SSR, 对用户也使用 SSR 吗?

  • 主 資深大佬 : zzzzzzggggggg

    @RickyC “为什么不能使用 PHP 直接写呢?”这个问题我一时不知如何回答。。。这个问题很像我们在讨论如何开车从北京去上海最近,然后忽然有人问“为什么不直接坐飞机呢?”
    好了正经一点,我想了一下,毕竟这是个前端问题,如果使用 PHP 去写,相当于回到了最早的开发模式,PHP 套模板的开发方式一个是前后端开发界限不清晰,一个是一些前端富应用用后端套模板实现起来很难。
    所以总结一下,jsp 、asp 、php 后端套页面——> 前后端分离——> 前端工程化,壮大——> 发现单页应用 SEO 困难——> 前端生态诞生 vue 、react 各自的服务端渲染框架
    nuxt.js 和 next.js 渲染对用户和搜索引擎都是 SSR

  • 資深大佬 : thtznet

    假设你前端水平和 Dan Abramov 一样,人家年薪百万美元,你面试被拒,这就是卷。

  • 主 資深大佬 : zzzzzzggggggg

    @thtznet 哈哈,最高 p7

  • 資深大佬 : RickyC

    @zzzzzzggggggg 有的是前进, 有的是倒退. 我本人非常看好前端工程化; 但是觉得 SSR 是一种倒退.

  • 主 資深大佬 : zzzzzzggggggg

    @RickyC 算是一种权衡吧,历史总是呈螺旋形前进嘛

文章導覽

上一篇文章
下一篇文章

AD

其他操作

  • 登入
  • 訂閱網站內容的資訊提供
  • 訂閱留言的資訊提供
  • WordPress.org 台灣繁體中文

51la

4563博客

全新的繁體中文 WordPress 網站
返回頂端
本站採用 WordPress 建置 | 佈景主題採用 GretaThemes 所設計的 Memory
4563博客
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?
在這裡新增小工具