这是一个创建于 237 天前的主题，其中的信息可能已经有所发展或是发生改变。
前端大部分主流框架的设计理念，一开始就和浏览器这个运行环境牢牢绑定。可惜好时代已经过去了。现在并不是一个炫酷网页或者几个 APP 页面，就能吃饱穿暖的年代。
面对客户繁琐定制化需求，代码高度复杂化，已经远超前端的承受能力。
隔壁传统语言，在对应巨大代码库的时候，都会有严格的单元测试，比如 google test ，有细粒度的筛选，能一定程度保证代码量膨胀同时，质量没那么糟糕。
但是前端一部分逻辑在后端，另外一部分逻辑在界面的动态交互上。写自动化测试难度就上去了，要背上浏览器这个沉重的壳。
理想状态下，前端代码要完美做到功能随写随测随改，还是有一定门槛难度的。
可能传统前端的诞生初衷，就不是为了承接那么多的需求。
117 条回复 • 2024-04-19 09:39:10 +08:00
 |
1
hazardous 237 天前  30
没有浏览器就没有前端，只有客户端。
|
 |
2
duanxianze 237 天前
没有浏览器，还有小程序
|
|
3
duanxianze 237 天前 4
正经说一句，你这是典型的只考虑技术的程序员思维，现实中渠道重要性远大于技术，换句话说就是让用户用的上比用的好重要一万倍，没有浏览器大多数业务就没了，再好用也没用了
|
 |
4
tool2dx OP @hazardous 客户让你在前端绣花，浏览器的存在就变得很碍事。反而觉得写客户端还省事一点。
你也不太可能把客户所有的功能逻辑，都丢给后端。 还有一种开发理念，就是用别的语言开发，最后再翻译成前端。类似 unreal/u3d 那种游戏开发，就能 hold 住比较大的代码量。 |
|
5
tool2dx OP @duanxianze "没有浏览器大多数业务就没了，再好用也没用了"
我的意思是浏览器不适合开发超级大项目。在浏览器里运行和调试，和传统语言对比，也没那么方便。 说白了，我就想把浏览器 API 给抽象出来。和大量核心业务代码无关。 现在所有的前端界面/逻辑都杂合在一起，维护起来头大。 |
 |
6
wanguorui123 237 天前 1
没有浏览器，又回到军阀割据的客户端技术时代
|
|
7
tool2dx OP |
 |
8
h1104350235 237 天前 1
Electron 和 Flutter 跳出前端的概念，才是拯救前端的方法。
|
 |
9
QlanQ 237 天前 2
@tool2dx #7 没有浏览器，在你让我下载 应用体验的那一刻，我就放弃了
感觉你这完全是 弄错了 辈分了。 浏览器出来，才有了前端 现在反过来，前端觉得 浏览器 功能不够，是个盲盒，太复杂？我可以这样理解吗？ |
 |
10
NickHopps 237 天前
浏览器正在朝着操作系统的方向演进
|
 |
11
Agdhfdjh 237 天前
你说的是 ssr 吧，大量业务逻辑可以放到 node 服务器上下发，前端专注视图层，国外已经是主流了
|
 |
12
clue 237 天前
说句实话, web 前端能发展成现在这样, 离不开海量需求、浏览器、标准化, 脱离浏览器(以及它背后的一整套标准), 它啥也不是
nodejs 真是是因为 js 特别好才发展起来的吗? 它只是因为受众多被动发展起来的 你想找个例子也比较简单, 看看 flutter 现在发展怎么样 |
 |
14
sentinelK 237 天前
楼主通篇的句式都是“前端的诞生初衷”，“远超前端承受能力”
所以这跟浏览器有什么关系？ 换句话说，什么模式的 UI 呈现，和浏览器呈现有本质区别？ |
 |
16
somebody1 237 天前
越看越迷糊，尤其是 op 回复的那几个，根本不知道 op 究竟想要什么。
什么东西发展到现在都不是凭空出现的，都是有其历史必然性的，抛开这些东西谈合理不合理，没什么意义。 |
|
17
tool2dx OP @sentinelK 我也觉得 UI 本不应该和浏览器呈现做强绑定。
但是现在前端框架设计的大前提，就是假设你在浏览器里运行的。 UI 抽象程度不够的后果，就是无法细粒度做单元测试。没单元测试就无法承载超大代码量，很容易写成屎山。 |
 |
18
AllenTsui 237 天前
客户端写单测，没有 UI 交互的、不严重依赖系统功能的、不依赖硬件功能的，单元测试好写好测。只要依赖了就是集成测试，跑的特别慢啊。从个人体验上来说，集成测试慢的我想骂娘。
|
 |
19
xz410236056 237 天前
客户端已经死的不能再死了，FE 才是未来。
|
 |
21
shui14 237 天前 1
展示型的页面交互设计是重点很看设计天赋，业务功能型的开发做不了主，毕竟大部分是垃圾伪需求，工具软件型的专业程度很高基本上跟前端没什么关系，只不过是在用 js 写程序而已
一般而言，ios 也算前端，桌面也算前端，跟用户相关的都可以算前端，你自己把自己放进笼子里了 如果是软件工程师，那又有什么区别。回想一下，程序设计（ c 语言版），写程序而不是写 c 现在绝大部分公司架构都是混，都在写组件脱离框架根本写不了程序，在浏览器里数大项目，sdk 算吧，可有几个能设计好。这段时间流行的车机医疗软件，连以前 FLASH openFL 都不如，连 qt 抄都不会抄，而且去年 webgpu 已经正式版了，配合 wasm ，完全可以脱离浏览器编译到不同的环境，你的界面何必是 html 呢还可以是 IMGUI 。这么重大的利好，一群前端还是卷编译器 |
 |
22
8355 237 天前 1
既然要开倒车
那聊一聊 b/s 架构和 c/s 架构各自的优缺点吧 |
|
23
sentinelK 237 天前
@tool2dx 所以问题的核心在于代码结构设计，和呈现媒介没有任何关系。
出于安全性以及程序复杂度上考虑，一个良好的程序架构，前端应该只负责数据可视化以及数据交互。 实际生产环节中前端承载过多的业务内容，从整个软件工程角度讲，都是出于成本、偷懒等原因做的过度妥协。 换句话说，代码腐败速度过快，在系统架构设计的时候，就已经命中注定了。 也就是说，前端“乱、杂、不好修”，是一个基于事实原因的既定结果，而不是原因。 |
 |
24
liuhuihao 237 天前
有没有可能浏览器就不是用来让你实现你说的”大项目“的。每个载体有他合理的使用场景，你说的所谓的”大项目“可能本身就不适合在浏览器运行。
就好比公路上跑着很多的小汽车，你客户让你造一辆货车，你要愣是在公路上铺铁轨也能跑，但公路设计的时候就是为了跑小汽车的，总不能说你这个项目是个大货车就否定公路吧，毕竟还有很多小汽车要跑呢 |
 |
27
libasten 237 天前
这是要开倒车？
回到安装本地客户端的时代？哪怕是 eletron 这种，要在本地双击安装等一会才能用系统的话，很多人不喜欢吧？ |
 |
28
cxzweb 237 天前
全世界这么多系统都依赖于浏览器，所有技术都是为了于服务人们，用户只会考虑怎么方便怎么来，而不会考虑你用的什么技术。我是用户的话我会选择浏览器，看剧、看直播、包括耍抖音我都用浏览器。
|
|
30
clue 237 天前
另外提一句, 目前 UI 方面, web 标准是毫无异议的最全面最完善的, 未来基本也不可能有谁非要脱离它自己做另一套了, 并且它也不是排它性的, 比如 AR/VR 技术, 在 web 已经有 WebXR 标准了, 它是一个标准集, 旧的标准慢慢废弃, 新的标准一代代改进, 你可以理解为它是一个开放的平台
就像现在不会有人自己再开发另外一套 ip 协议来颠覆现有的互联网, 只会有 ipv6, web 也是类似的 |
 |
31
zihuyishi 237 天前
我看最近国内的大厂都很想干掉浏览器把用户往手机 app 上逼，要不干脆去转手机 app 开发吧，就没前端那么多的事情了
|
 |
32
june4 237 天前
这说得就离谱，难道客户端原生 UI 就好测试了，比前端麻烦得多。前端是最透明最容易检测的技术没有之一。
|
 |
33
snarkprayer 237 天前
你是不是在找“整洁架构”
|
|
34
tool2dx OP |
 |
35
opengps 237 天前
想想以前前后端不分离的时候，哪有前端岗位，都是后端捎带着做的界面
|
 |
37
leaves615 237 天前
不能改变，就适应。
|
 |
38
Chrisssss 237 天前 1
@tool2dx 按照你的说法因为浏览器的问题所以无法承载超大代码量，容易写成屎山。以我的经验（前司的网页 SaaS 应用全加起来有几十万行的代码）来看是不存在这个问题的，因为 99% 的网页应用无法触及到浏览器的承载力上限，大部分的屎山都是人为造成。
另外由于浏览器单个页面展示的内容不是无限的，所以一个大型应用大概率是多页面的，可以很清晰的根据页面维度来做页面级别的单元化测试和端到端自动化测试 |
 |
39
5I4v7N4CPSlF03tx 237 天前 via Android
js 没有内存管理，浏览器给标签自动分配内存，cpu gpu 地调用也是随缘，突出一个后妈生的，至今小程序这种套壳浏览器的爆内存强退问题腾讯也没解决，但是时代在发展，js.ts 的开发社区生态是安卓、winform 们比不了的，干过客户端再回到前端，三方插件真爽，调试真爽，直呼真香，只有一句未来可期吧
|
 |
40
sighforever 237 天前
作为个人肯定怎么搞都行，但作为一个工作，现在这么分工本来就是发展的必然结果，是需求，成本，协作，发布等综合下来的结果。除非人机交互出现其他革命性的变化，比如 AR 那种，不然现在这种依托浏览器的前端工作改变的可能性不大了
|
|
41
tool2dx OP @Chrisssss "你能说出几个因为浏览器承载力不足导致要转平台的例子吗？"
浏览器是个平台，承载力不单指技术上，由于前端产品过剩，早晚和 APP 一样，会有一大批劣质前端产品被市场淘汰。 能留下来的产品，只能把功能卷到极致。不断叠加新需求后，就很容易触及技术上限。 |
 |
43
oliveira 237 天前
我不是很理解为什么你的认知还停留在前端=浏览器端？
现阶段基于夸端技术和 Nodejs 的逐步完善，JS 代码运行在包括但不限于浏览器端、IOS/Android 端（ React Native/Flutter ）、Windows/MacOS 端（ Electron/Tarui ）和服务器端（ Nodejs ）等等，不仅如此还衍生出小程序和 Hybrid 这种夸端架构。 理论上前端包含所有跟人进行交互的界面和程序。 |
 |
44
pinecone1 237 天前
浏览器是前端的亲爹，就是因为浏览器在几乎所有端设备上的广泛覆盖，才让前端产品易于触达和分发。
脱离浏览器就是没了命，不可能的。 确实浏览器里很多内容都是黑盒的，不暴露给 JS Context ，但是你只能受着。你可以选择加入 Chrome 团队，定 w3c 标准规范，要求浏览器标准化更多能力并对 JS 开放。 |
|
45
QlanQ 237 天前
|
 |
46
ZGame 237 天前
我觉得反而是浏览器相关的前端成就客户端。正因为浏览器里的 html+css+js 这些是公开的，各大厂商互相牵制,定制标准,才成就前端世界的百花齐放,复杂度这种东西是客观存在的,只能是分解或者转变思路。像前端 mvc,mvp,mvvm ui=fn(state) 思路的变化和组合。
我觉得真的劣化的反而是被单一大厂生态所控制的。flutter,swift,这些。。。。 |
|
47
tool2dx OP @QlanQ "所以 vscode 算 OP 说的前端项目吗？"
vscode 只是大厂在推，代码也没想象中那么美好。每个模块都有 browse 目录，里面代码也是随手就写 div 。div 离开浏览器环境后，完全无法复用代码。 ts 可以复用，div 不行。 |
 |
48
wolfan 237 天前
OP 同志，当你看到一个个的网站变成一个一个的应用程序的时候，你会发现你 TMD 的怀念浏览器的存在。
|
 |
49
crysislinux 237 天前 via Android
扯什么犊子呢，前端你要想处处都单测也完全可以，之所以测试少是因为界面变的快。
跑集成测试加个浏览器有啥沉重的，后端还得初始化数据呢 |
|
50
tool2dx OP @wolfan 浏览器只是对用户友好。
当开发者想把前端应用，做到和本地应用完全相同的复杂级别，可能需要付出双倍努力。 你看 adobe 推出的在线 photoshop ，都是残缺版本。和本地应用比还是有很大差距的。 |
 |
51
aikilan 237 天前 2
当一个产品的需求越来越复杂，需要依赖的第三方库越来越多，你最后不过是重新发明了浏览器。客户还会质疑你这为什么还不如谁谁谁家的网页版好用，你试图用技术说服他，他觉得你话真多，我只是想要一个好用的产品，你跟我谈技术实现有什么用？
|
|
52
aikilan 237 天前
还是那句话，技术是手段，而不是目的。
|
 |
54
x86 237 天前
前端圈整活手段还挺多，线上都满足不了他们了
|
 |
55
dayeye2006199 237 天前
那是因为你不会写 wasm ，webGL 之类的东西。人家也是做前端的
|
|
56
clue 237 天前
Java 想要进化, 就必须要摆脱 jdk 这个枷锁
浏览器(web 标准) 之于 前端, 就像 jdk 之于 java 我感觉这个话题没什么讨论的意义了 |
 |
57
LandCruiser 237 天前
说白了，你想要银弹，但是不管是职业生涯，还是技术方案，都没有银弹。此贴终结~
|
 |
58
43n5Z6GyW39943pj 237 天前
你所谓的大项目,载体是什么?
|
 |
59
Guidoo 237 天前
op 15 天内注册
|
 |
60
Rever4433 237 天前
我倒是觉得前端只有浏览器还是太小，应该扩大浏览器的能力，可以集成个虚幻引擎什么的，在浏览器就能玩 3A 。其次手机浏览器也应该进化一下，把所有的 App 全部杀死，只用浏览器解决全部问题。
|
 |
62
NerbraskaGuy 237 天前
浏览器和客户端为啥非得二选一，感觉你的逻辑是浏览器太弱了跑不动大型业务，浏览器就会被淘汰。flutter 出来这么久了还不是原生的更多，是业务决定了使用什么平台，不是平台跟不上业务所以就得死。
|
|
63
tool2dx OP |
|
65
tool2dx OP |
 |
66
zzNucker 237 天前
哥们 前端现在早就囊括终端了，不限于浏览器
|
 |
67
murmur 237 天前
@dayeye2006199 那为啥不用 unity ？
|
 |
68
IvanLi127 237 天前
op 说的前端是啥？ Web 前端摆脱了浏览器那就不是 Web 前端了。浏览器承载不了的话就承载不了，方案那么多，没必要吊死在一棵树上。硬要吊的话可以自己增强浏览器，比如 Electron 。Web APP 也有离线可运行的，逻辑可以完全在一起，即使分开，自动化测试的难度也没有什么变化。
浏览器只是一个用户代理，你摆脱这个但是没说要用什么代替，那剩下的不就是用户自己看 text/plain 么？ |
 |
70
pkoukk 237 天前 8
作为真的做过传统桌面 client (.NET FORM)的开发表示
你想多了，客户端更难搞测试，不是代码难测试，而是环境 你要面的是海量的黑盒组件，有些是 C 或者 C++封装的组件 有些是 Win32API ，system dll ，COM 组件 更别提有的画图组件还要用 DIRCTX 这中间的兼容性和运行环境能把人搞死，再加上那时候流行什么精简版 xp ，国产管家提供系统瘦身 在你眼里，浏览器是桎梏，在我眼里，浏览器前端就是像 Docker 一样的划时代伟大产物 |
|
72
tool2dx OP @pkoukk 浏览器前端门槛还是太低了，以至于没多少人会把软件工程学当一回事情，只求写代码高效，加入语法糖，提前完成业务逻辑。
项目小，你好我好大家好。等项目慢慢变大，就开始慢慢爆地雷了。 都说传统桌面早晚会过时，但是真正把所有桌面端用网页重写，就知道有多困难了。 |
 |
73
blur1119 237 天前
@h1104350235 electron 不也是套了壳的浏览器？
|
 |
74
mxT52CRuqR6o5 237 天前
要不要摆脱浏览器这个枷锁我不好说，但不要随便给自己设枷锁我觉得没问题，不要这也做不了那也做不了，只能做自己知道的那点东西
|
|
75
pkoukk 237 天前
|
 |
76
Mikawa 237 天前
你要找的是不是单机部署的 Electron 项目
|
 |
77
belin520 237 天前
你说的前端是 web 前端吗
|
 |
78
HelloApex 237 天前
IOS 和 Android 不是前端吗
|
 |
79
ns09005264 237 天前
Webassembly+WebGPU ，能当多平台客户端用，也能在浏览器中运行。
像这样: https://mvlabat.github.io/bevy_egui_web_showcase/index.html |
 |
80
weixind 237 天前 10
高大上的 B 话一大堆。跟谁学到的臭毛病。
|
 |
81
skydcnmana 237 天前
@tool2dx #4 那不就是 Blazor 那种么，直接用 C#开发。
|
 |
82
gentrydeng 237 天前 via Android
@tool2dx #72 “都说传统桌面早晚会过时，但是真正把所有桌面端用网页重写，就知道有多困难了。”
楼主有没有兴趣了解一下 Chromium OS ？ https://www.chromium.org/chromium-os/ |
 |
83
qeqv 237 天前 2
。。。客户繁琐定制化需求，是基于浏览器全设备支持+随时随地打开使用的前提，你现在是想要把地基砸了？
|
|
84
tool2dx OP @qeqv 第一，我指的去浏览器，是开发阶段，不是运行阶段。在我的理念里，只要代码架构足够完善，移植到任何平台都是可以顺利运行的，其中包括浏览器。
第二，客户端和浏览器并没有优劣之分。如果客户需求在浏览器上实现，开发成本要明显高于客户端，那么劝说客户安装一个 EXE/APK ，我觉得也不是天大的事情。 |
 |
85
jiangwei2222 237 天前 via Android
其实现在已经脱离浏览器枷锁了，现在都叫“大前端”了，所有显示都算大前端。但是安卓，ios ，pc ，各种小程序，渠道太多，技术栈各不相同，于是又在各个端里面都引入了浏览器，变成 h5 开发
|
 |
86
zogwosh 237 天前
你说的对,那么 flutter 为什么要放弃 htmlrender,是因为浏览器的用户不够多吗
|
 |
87
gesse 237 天前
科技以人为本。
牺牲码农点加班时间， 加速推动线下业务网络化、同时产生很多新的行业，带来几十亿人的便利，有什么不可以？ |
 |
88
FrankAdler 237 天前
如果我是一个独裁暴君，我会立法要求所有的公司都不得开发独立 App ，全部是浏览器，以快应用或者类似小程序这样的载体存在，这样全国人民使用起来就很舒服，至于性能问题在浏览器引擎这个层面解决。
|
 |
89
herozzm 237 天前
没了浏览器，前端不完整了 T_T
|
 |
90
tkHello 237 天前
吃饭砸锅？
|
 |
92
fredsunme 237 天前
你的主语很模糊, 以为是前端技术的进化.
结果点进来是前端开发的个人成长方向 |
 |
93
dawnvivid 237 天前 5
|
 |
94
cwliang 237 天前
返祖言论，你别用各种 GUI 图形界面了，直接终端输命令呗，计算机倒退五十年
|
 |
95
lee88688 236 天前 1
@tool2dx #13 我觉得 op 这个想法不对，浏览器的接口设计是没问题的。超级大项目更多在于架构设计和管理，前端也是完全没问题的。
我们这边曾经给一个国外银行做的外部，他们最重要的交易终端就是用前端开发的，持续迭代了 10 几年，包括客户端（ electron ）、桌面 web 、移动端 Web 等。其中涉及包含内部业务模块几百个，整个前端一个 repo 十几个前端团队几十号人。 我觉得前端现在确实不应该局限在浏览器环境，但是就在浏览器环境做出大项目完全没问题，向之前传统的客户端或者后端学习项目架构设计项目管理或许能发展的更好吧。 |
 |
97
Terminl 236 天前
有没有一种可能，客户端也要依赖浏览器的内核展示
|
 |
99
darkengine 236 天前
有没有一种可能，你说的这些问题客户端也有
|
 |
100
shunia 236 天前
哥们这么会说废话，应该多少也是个官吧😅
咱们搞技术的能不能整点实诚的，举个具体的例子，浏览器怎么就没能承载你写过的超大的项目？ 能不能先定义一下超大，再说明一下无法承载是因为出现了什么问题？ |
Select Language