@sechi 有啥释怀的。以前写代码我也是拿着前端框架直接写，没啥是一个 div 搞不定的，如果不行就两个 div 。

楼上说套个 webview 到处能跑，但问题那是浏览器平台的能力，这和你的设计代码竞争力基本没啥关系。你可以，别人也可以。

分析，架构，抽象。只有这些才是真正属于你自己的东西。

@shunia UI 编程本来是一个很宽泛的概念，我就不想自己写的前端代码，被浏览器给局限住。

用以前的老说，就是 write once, run everywhere.

知道你会觉得我在异想天开，但前端连编译器轮子都能自己造，又有什么是做不到的。

并不反对有效加班。
但是无效加班都是自己骗自己，没意思。

@tkHello 换口锅吃饭，一口锅又不能吃一辈子。

所有人都指望浏览器给饭吃，最后大家都吃不饱。

@qeqv 第一，我指的去浏览器，是开发阶段，不是运行阶段。在我的理念里，只要代码架构足够完善，移植到任何平台都是可以顺利运行的，其中包括浏览器。

第二，客户端和浏览器并没有优劣之分。如果客户需求在浏览器上实现，开发成本要明显高于客户端，那么劝说客户安装一个 EXE/APK ，我觉得也不是天大的事情。

@pkoukk 浏览器前端门槛还是太低了，以至于没多少人会把软件工程学当一回事情，只求写代码高效，加入语法糖，提前完成业务逻辑。

项目小，你好我好大家好。等项目慢慢变大，就开始慢慢爆地雷了。

都说传统桌面早晚会过时，但是真正把所有桌面端用网页重写，就知道有多困难了。

@shyangs 说的没错，这就是我理想中的前端状态。

能不能实现我不知道，但是我希望尽可能向这个方向努力。

高度的代码可维护性，本来就是需要牺牲一部分灵活性为前提，作为代价的。

@clue java 管理大项目没问题啊，UI 是 UI ，逻辑是逻辑，可以分开的。

前端框架的花活，都是逻辑和交互掺杂在一起的。

浏览器(web 标准)是开发复杂代码的体验不好，不是用户体验不好。

@Guidoo 我这头像是老用户了。大号前几天和小仙女互怼了几句，讨论产品经理好还是程序员好，结果就 404 了。

都是老套路了，以前是杠杆期货，随便你加多少杠杆，最后血本无归。

@wolfan 浏览器只是对用户友好。

当开发者想把前端应用，做到和本地应用完全相同的复杂级别，可能需要付出双倍努力。

你看 adobe 推出的在线 photoshop ，都是残缺版本。和本地应用比还是有很大差距的。

@QlanQ "所以 vscode 算 OP 说的前端项目吗？"

vscode 只是大厂在推，代码也没想象中那么美好。每个模块都有 browse 目录，里面代码也是随手就写 div 。div 离开浏览器环境后，完全无法复用代码。

ts 可以复用，div 不行。

我记得 AI 可以全自动智能提取日期。先把表格做成 excel ，然后上传给 AI 批量处理。

@Chrisssss "你能说出几个因为浏览器承载力不足导致要转平台的例子吗？"

浏览器是个平台，承载力不单指技术上，由于前端产品过剩，早晚和 APP 一样，会有一大批劣质前端产品被市场淘汰。

能留下来的产品，只能把功能卷到极致。不断叠加新需求后，就很容易触及技术上限。

@clue 你的能力和技术，不应该和某一个平台强绑定。

浏览器的承载力是有上限的，万一有一天浏览器推不动新项目，这时候要转平台，那你的经验和积累，应该是可以无缝切换的。

别一年经验重复十年，没前途的。

@QlanQ " 有没有可能浏览器本来就不是为了干大项目的？"

客户提新需求，又不管你是不是用浏览器。前端代码只会越来越复杂。

@sentinelK 我也觉得 UI 本不应该和浏览器呈现做强绑定。

但是现在前端框架设计的大前提，就是假设你在浏览器里运行的。

UI 抽象程度不够的后果，就是无法细粒度做单元测试。没单元测试就无法承载超大代码量，很容易写成屎山。

@QlanQ 浏览器作为前端主要运行环境之一，我对此没什么异议。发帖吐槽，就只是浏览器接口不够抽象，不适合超级大项目开发。

写个小项目，是完全没问题的。