说说前端未来几年的发展方向

简介: 说说前端未来几年的发展方向

640 (6).jpg

在知乎上看到这么一个问题,觉得很有意思,以下是原提问者的见解


过去五年前端的发展过程基本上是一个工程化的过程,框架和工程化工具层出不穷。

近两年其实发展已经比较迟滞了。


框架方面:基本就是三大框架鼎立的局面,三大框架都在相互借鉴吸收,而且方向各有侧重,未来短时间内我看格局不可能有什么大变化.


工程化工具:基本上是 webpack 一统江湖的趋势,虽然有 parcel 等来小打小闹,但是生态一旦形成,没有革命性的项目是无法取代 webpack 的,而且 webpack 也在进化.


个人认为前面五年是前端生产力提高的五年,工程化使得前端的生产力得到了极大提升,但是现在也基本上是在已有的格局中修修补补了


我谈谈我对前端未来几年的发展方向的看法。


看未来的发展方向,无非就是看现在的解决方案所存在的痛点。


1. 浏览器的性能问题


做 web 前端的同学都知道,和原生的 App 相比,性能一直一个致命的痛点,如果要追求性能,肯定得用原生 App。那么在性能上,未来几年可能是一个方向。


①前端代码编译为字节码


浏览器这几年在 Chrome 的带动下,性能飞速发展,但毕竟其核心原理没有变化,性能始终难以达到原生 App 的水平,这部分是很有可能出现大的变化的,一个可能的方向就是浏览器变成虚拟机,前端代码编译为字节码,通过这种方式来将性能提升一个等级,虽然还是难以达到原生App的水平,但已经能够满足绝大部分应用的性能需求,类似于Java对比C/C++一样。    --李运华


因为 js 是边解释边执行的,这肯定是要比编译型语言要慢,为了解决解释器的低效问题,大概在 2008 年的时候,提出了 JIT 的概念,它是使 JavaScript 运行更快的一种手段(JIT,内联缓存和隐藏类)之一,通过监视代码的运行状态,把 hot 代码(重复执行多次的代码)进行优化。通过这种方式,可以使 JavaScript 应用的性能提升很多倍。


但是时至今日,还是觉得不够快,所以各大浏览器厂商开始支持 WebAssembly。WebAssembly 是一种新的字节码格式,主流浏览器都已经支持 WebAssembly。


和 JS 需要解释执行不同的是,WebAssembly 字节码和底层机器码很相似可快速装载运行,因此性能相对于 JS 解释执行大大提升。


也就是说 WebAssembly 并不是一门编程语言,而是一份字节码标准,需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行.


他的优点就是:


  • 体积小:由于浏览器运行时只加载编译成的字节码,一样的逻辑比用字符串描述的 JS 文件体积要小很多;


  • 加载快:由于文件体积小,再加上无需解释执行,WebAssembly 能更快的加载并实例化,减少运行前的等待时间;


目前可以编译成为 WebAssembly 字节码有 :AssemblyScript(语法跟 TS 差不多,)、c\c++、Rust、Kotlin。


②统一的DOM树限制了单线程的渲染


理论上来说,一个页面某个时间变化的部分只是集中在一小块区域,没有必要将整个DOM树锁住。因此,一个可能的方向是分区渲染,即将页面划分为几个不同的区域,每个区域有独立的DOM树,独立渲染,那么性能会高很多,类似于 App 开发中的组件,组件类的运行不影响其它组件,如果需要依赖其它组件,通过组件间消息进行通信。


原生 App 不同平台重新开发的痛点


现在的 web 有两大优势,一个是浏览完毕直接走人,另外一个是跨平台,只要有浏览器,一切都好说。


所以现在有很多 hybrid 解决方案,某些页面通过 h5 的方式来展现。


想解决的无非就是少花点成本,写一份代码,可以在 ios 和 Android 上都可以用,进而也出来了想 RN、weex、NativeScript 这类 Learn Once, Write Anywhere(RN提出来的) ,但是他们最终都会翻译成原生代码。


但是用过这些的人都知道,还有很多坑,经常调侃 rn 的就是 write once ,debug anywhere。


Learn Once, Write Anywhere 的理念,背后就是跨端的思想,所以也诞生出来 electron、PWA 为代表的案例。


而且现在出现了 Taro 、mpvue 这些 h5 与小程序的统一的方案,所以未来在突破写一份代码在 h5 ,原生 app、小程序,甚至桌面应用都有可能。


另外提醒


  1. 我很早就跟星球里的朋友们说过,TS 一定会在火的,现在用 TS 的感觉,让我感觉跟 vim 很像,刚开始用的时候很难受,一旦习惯了就离不开了。未来项目会越来越复杂,用了 TS 项目的风险会可控很多。


  1. 多注重框架原理,现在对于前端工程化,个人认为差不多到了瓶颈期,很难有新的突破,注重原理才能很好的应对未来的发展。


  1. 眼界放宽、拓宽自己知识的广度。


欢迎大家把自己对未来几年前端的看法在留言区讨论,以上仅为个人观点。

目录
相关文章
|
JSON 前端开发 数据可视化
AMIS【部署 01】amis前端低代码框架可视化编辑器amis-editor本地部署流程
AMIS【部署 01】amis前端低代码框架可视化编辑器amis-editor本地部署流程
3784 0
|
人工智能
LangGraph:构建多代理动态工作流的开源框架,支持人工干预、循环、持久性等复杂工作流自动化
LangGraph 是一个基于图结构的开源框架,专为构建状态化、多代理系统设计,支持循环、持久性和人工干预,适用于复杂的工作流自动化。
2871 12
LangGraph:构建多代理动态工作流的开源框架,支持人工干预、循环、持久性等复杂工作流自动化
|
机器学习/深度学习 人工智能 自然语言处理
【人工智能】常用的人工智能框架、模型、使用方法、应用场景以及代码实例的概述
人工智能(AI)领域涉及众多框架和模型,这些框架和模型为开发人员提供了强大的工具,以构建和训练各种AI应用。以下是一些常用的人工智能框架、模型、使用方法、应用场景以及代码实例的概述。
1806 1
|
编解码 缓存 算法
Three.js如何降低3D模型的大小以便更快加载
为加快600MB的3D模型在Three.js中的加载速度,可采用多种压缩方法:1) 减少顶点数,使用简化工具或LOD技术;2) 压缩纹理,降低分辨率或转为KTX2等格式;3) 采用高效文件格式如glTF 2.0及draco压缩;4) 合并材质减少数量;5) 利用Three.js内置优化如BufferGeometry;6) 按需分批加载模型;7) Web Workers后台处理;8) 多模型合并减少绘制;9) 使用Texture Atlas及专业优化工具。示例代码展示了使用GLTFLoader加载优化后的模型。
2691 12
|
Web App开发 人工智能 前端开发
Vercel 的 AI 工具 V0.dev 是什么?如何使用它?
# 网络开发者 # 人工智能 # javascript # 反应
9642 1
|
安全 JavaScript Java
失物招领|基于Springboot的校园失物招领系统设计与实现(源码+数据库+文档)
失物招领|基于Springboot的校园失物招领系统设计与实现(源码+数据库+文档)
1084 0
|
监控 安全 Java
《SpringBoot启动流程三》:两万+字图文带你debug源码分析SpringApplication准备阶段(含配置文件加载时机、日志系统初始化时机)
《SpringBoot启动流程三》:两万+字图文带你debug源码分析SpringApplication准备阶段(含配置文件加载时机、日志系统初始化时机)
1009 0
《SpringBoot启动流程三》:两万+字图文带你debug源码分析SpringApplication准备阶段(含配置文件加载时机、日志系统初始化时机)
|
存储 网络协议 芯片
清晰讲解LSB、MSB和大小端模式及网络字节序
清晰讲解LSB、MSB和大小端模式及网络字节序
3740 0
光学字符识别引擎 Tesseract-ocr 安装过程
上篇我们对 Tesseract-ocr 做了一个简要的介绍,下面我们来看一下  的安装过程。 注意:这里只是当你不想去下载源代码进行编译或优化、修改、定制的情况,使用现有的安装包去安装使用。 安装包下载地址: 稳定版:https://digi.
1781 0
|
5天前
|
人工智能 运维 BI
阿里云千问办公QwenWork深度解析:基于Qwen3.8,六大核心能力重构企业全自动化工作流与计费选型指南
传统AI办公工具大多停留在对话问答、文档摘要、简单文案生成层面,只能完成单点碎片化任务,无法自主拆解复杂业务流程,很难串联多工具、多文档、外部业务系统完成端到端完整工作交付。很多企业在落地AI办公的时候,需要组合多款不同工具,来回切换界面,手动复制粘贴中间结果,智能化改造落地门槛居高不下。千问办公QwenWork是整合多款智能体产品能力打造的一体化企业办公智能体平台,底层基座依托Qwen3.8大模型,打通桌面端Agent、云端Agent、企业协同Agent三种运行形态,不再局限简单问答,接收业务目标之后自主拆解任务步骤,调用各类工具,处理文档、表格、浏览器自动化、数据查询,直接输出可交付的办公
1462 0