这是一个创建于 233 天前的主题，其中的信息可能已经有所发展或是发生改变。
失业状况（请跳过）
失业在家快一年了，刚过 40 岁，有点不知所措。刚拿到赔偿金那天还很高兴，当天就去自驾游了，但玩得很内疚，总感觉在浪费时间，想是不是该沉下心来学习？于是玩了一周就回家了。
回来后，几个月都在打兼职，写 AI 工具，总共就赚了五千块，还借了六七千块钱给个在创业的朋友（估计是要不回来了）。
后面感觉做兼职是浪费时间，转头研究 AI Agent ，自已写了个本地对话工具，基于 Ollama ，但是本地电脑算力不够，而且 ollama 不支持 mcp ，bridge 写得头大，放弃了。(遗产： https://gitee.com/james-yin01/viviwawa ）
又转头研究腾讯的 KuiklyUI ，自研个“贷款计算 App”，但发现 Kuikly 非常不成熟，文档不全，bug 多，功能不完善，社区没人，果断放弃。（遗产： https://gitee.com/james-yin01/lc-loan-calculator ）
最后，心想还是做自已最擅长的东西吧（我十多年 web 前端开发），于是就花一个月写了个 web 框架。当然，目前只是原型阶段，只是跑通了基本的几个小场景，问题肯定还有很多，所以想在这儿问问大佬们这玩意有没有搞头，有的话就继续写写看，没有的话就放弃搞别的去了。
框架简述
框架名为 LazyCoffee ，是一款设计为面向对象开发的 web 框架。框架地址： https://gitee.com/james-yin01/lc_ood_framework
为什么要开发这个框架？
实话实说，我也是个讨厌重复造轮子的人，没事找事，感觉像刷 KPI 。但我写前端这么多年了，用了巨多框架，各种优点缺点我都心中有数，所以想能不能造个能解决某些痛点，又简单好用的框架，于是就萌生了写框架的想法，绝不是简单的造轮子。
失控的状态变量
我是从 ie6 那年代过来的，我特别喜欢原生开发，有一种掌控全局的感觉，到后面 angular, react, vue ，我发现项目变大后，有种失控的感觉，例如一个 dom 元素会被 state, props, redux 等各种变量控制，产生这样的问题是因为不同的变量有不同的作用域，你必须从上到下传递变量或者利用 redux 这样的框架全局把控。随着代码贡献的人变多，思路不一致，会发现项目的组件像口袋里的有线耳机一样混乱，例如明明可以组件内控制的变量非要用 props 传过来。
举个经典例子：弹窗。我们要做很多个弹窗，所以会有一个叫 Modal 的组件统一显示弹窗，弹窗内容通过props.children传过来，开关通过props.isOpen控制。因为你有很多不同的弹窗，所以你要一个数组来控制所有的弹窗变量，这就需要 redux 之类的状态管理工具来全局把控了。如果要关闭某个弹窗，你要遍历，变更状态，触发更新，麻烦的很。
解决单向流的痛点
其实造成上面的问题的根本原因就是 react, vue 都一直尊循的原则：状态变量单向流，你的状态变量只能从上层往下层传递，如果你的下层组件想变更上层状态变量，是不允许的，如果想实现，只能把状态变量统一提取到全局作用域，下层组件通过变更全局变量才能实现。
为了解决这个问题 LazyCoffee 框架利用了两个古老但实用的设计：元素查找和属性代理。
元素查找和属性代理
如果有两个平行的组件，例如两个弹窗，你不能在一个组件里变更另一个组件的变量，只能改为上下级或者通过共同父组件来控制。但 LazyCoffee 框架就可以，你只要找到另一个组件的实例，然后调用实例方法即可，看下面伪代码：
import { queryOne } from 'lc_ood_framework';
function submit() {
const anotherModal = queryOne('#confirm');
anotherModal.open('Are you sure?', function () {
// do something
});
}
是不是很熟悉的感觉？这不就是 jquery 老一辈的设计嘛？是的，朋友，是的。queryOne就是元素查找的方法，anotherModal就是元素的实例，open就是元素的方法，这个方法就是通过属性代理实现的。
通过这种设计，不管你的组件是平行的，还是上下级，都可以直接操控别的组件，从单向流的桎梏中解脱出来。
是不是有别的办法？
我在想，是不是有别的办法解决上面说的痛点，有必要另外写个框架？有的，朋友，当然有。利用 redux 或 pinia 之类的状态管理库，统一管控起来，然后让团队成员遵守代码规范，做好代码检视，一般是能实现的。我之所有写框架，是想更优雅解决这个痛点，提供一个与众不同的思路。
没了，就这样
框架的其他设计几乎都是照抄 react ，就是代码实现上自已另外造了个轮子，没找到复用的方法（有想到的告诉我，维护一个 jsx 实现是很难的）。
请大佬们指点迷津，谢谢！
另外，有需要前端老中医的欢迎联系我，我失业中，谢谢！
126 条回复 • 2025-06-03 15:00:07 +08:00
 |
1
yinxs2003 2025 年 5 月 28 日  2
这年头别借钱给别人，搞不好，钱和朋友都没了。
|
 |
2
aino 2025 年 5 月 28 日
未婚吗
|
 |
5
mumbler 2025 年 5 月 28 日
还手写代码吗，这年头谁还要框架啊，AI 愿意用什么就用什么
|
 |
6
elantion OP 1
@mumbler 是的，我也想过 AI 的问题，我发现 AI 对上下文的理解相当差，所以这个框架的另一个目的就是减少上下文，尽量组件内自闭。
|
 |
7
cat 2025 年 5 月 28 日 4
40 岁，造这样的轮子，个人觉得真的不值…… 当然，开心最重要
|
|
8
elantion OP 不是自闭，是闭环，说错了
|
 |
10
Wxh16144 2025 年 5 月 28 日
ie6 走过来的前端，老前辈了，不过还是别卷前端了吧，卷不过刚毕业的年轻人了，硬要搞代码的话走全栈路线吧
 |
|
11
elantion OP |
 |
12
horizon 2025 年 5 月 28 日
没意义了，没人会用。
|
 |
14
shunia 2025 年 5 月 28 日
单向流算是痛点吗？如果要解决，最好也是一个系统一点的方案吧？直接引用，感觉是头疼医头，脚疼医脚，这代码真要上生产，引用关系上不得乱套吗？
直接在被引用的组件中定义方法，供外部使用，这个限制就太大了。要想让方法支持重构困难重重，通过数据流进行重构则简单的多，因为你可以非常轻松的 derive 出一个新的数据字段、结构，也可以在两个不同的组件之间建立一个合并后的数据流来进行中转，看似引入了更多的复杂度，其实大大简化了心智负担。在我看来，这也是在前端，MVVM 能够轻松战胜 OOP 的最核心优势。 既然都 OOP 了，那么封装一个 React Component 的结构，甚至包括了写法，的意义在啥地方啊。我直接调用方法里面自己把逻辑写了不就好了吗？ open => this.container.classList.add('open')，我还写一个额外的 state 来解决什么问题呢？在 OOP 的结构里，针对组件强行用 VM 驱动，是不是有点画蛇添足了。。。 我觉得现在这个，离“框架”是不是有点太远了？我甚至没法定义它。。。 |
 |
15
penzi 2025 年 5 月 28 日 via iPhone
你的这些问题，引入 event bus 就行了。虽然 event bus 增加了复杂度，但至少比你这个高耦合的方案好太多了
|
 |
17
peter1988 2025 年 5 月 28 日 1
建议搞搞产品，或者其他变现的东西，同样 ie6 过来的程序员，我们痴迷于解决技术的问题，但是慢慢变得解决不了自己生计的问题。
|
 |
18
NathanInMac 2025 年 5 月 28 日
你看下 solidjs 把，优雅的解决了你说的那些痛点
|
 |
19
zixianlaiye 2025 年 5 月 28 日
冒昧的问下，老哥现在资产如何
目前来说，这些框架看起来不能带来比较可观的收益 |
 |
20
molvqingtai 2025 年 5 月 28 日
楼主了解过 lit 框架吗，感觉类似，只不过 lit 是基于 web component
|
 |
21
dyexlzc 2025 年 5 月 28 日
刚工作几年，但也有了一些自己的想法：
以前我也觉得技术至上，工作几年后发现实际上还是服务于业务，业务能赚钱，你就算全篇 jq 撸都行。 早餐店的技术含量难道比计算机科学更难吗？不难，但由于满足了部分人的刚需，因此就能赚钱 |
 |
22
tonytonychopper 2025 年 5 月 28 日
如果按照你的方案，一个组件能够变更另外一个组件的变量感觉有挺多问题。比如：
1. 怎么规范这种写法，避免组件之间改来改去（还是说其实这在框架设计的预期内，组件之间就让它们大乱斗 2. 组件在这种设计下不太纯粹了，如果一个组件能够直接影响其他组件了，可能就会导致：性能问题、组件职责边界问题。 3. 如果重构组件 A ，怎么确定组件 A 的影响范围？按照传统方法，这种情况需要梳理组件 A 使用的页面。但是按照目前这种设计，看起来会有一些潜在的问题难以发现，因为 query 这种方式，没办法直接发现组件 A 被某个组件 / 页面引用了，对于重构场景下工作量会是巨大。 |
 |
23
YICHUJIFA 2025 年 5 月 28 日
想问问你有没有时间、兴趣 教别人学前端开发。
具体的话可以留个联系方式。 |
 |
24
nzbin 2025 年 5 月 28 日
Angular 就是为大项目而生，只用 service 就可以处理状态，没有 redux 那种烦恼呀，楼主说的不会是 AngularJS 吧
|
 |
25
kuan0025 2025 年 5 月 28 日
如何是为了学习，更深入的理解前端的话，很支持。但如果真的是想个人搞个被广泛接受的前端框架出来的话，真吃力不讨好。
|
 |
26
ronen 2025 年 5 月 28 日
"感觉做兼职是浪费时间". 看看有沒有辦法扭轉這種想法。 能產生現金流的事情，都不算浪費時間。 反而你寫框架的這些時間，感覺在浪費時間。
如果實在是碼力充沛，建議看看你用的比較多的開源框架，是否需要做貢獻，在裏面留下名字，這樣將來找工作的時候，能有東西佐證深度。 而且是和人交流，不是閉門造車。 |
 |
27
Lockroach 2025 年 5 月 28 日
之前做过 ie6 的前端兼容，看到老前辈就亲切🫡
|
 |
28
wakarimasen 2025 年 5 月 28 日
捏着鼻子用 Redux 一定程度上是为了可维护性和易于调试。反之如果是做个 toy 连构建工具都不想用，会考虑 HTMX 或者 Alpine.js
但是你这个好像保留了工程化的缺点然后把优点剔除了…… |
 |
29
importmeta 2025 年 5 月 28 日
我一直感觉 angular 依赖注入那一套 加上 jsx 语法 就是最好的面向对象框架.
|
|
30
importmeta 2025 年 5 月 28 日
@importmeta 只要注入 service, 根本用不着什么全局变量,父传子乱七八糟概念.
|
 |
31
hefish 2025 年 5 月 28 日
这个实话实说啊。。。 别打我。
我觉着没搞头。 |
 |
32
eluotao 2025 年 5 月 28 日
前端有审美的，年纪越大越吃香，不会设计纯技术流，市场有需求，但都是昙花一现，利用完就抛弃了。
|
 |
33
gouflv 2025 年 5 月 28 日 via iPhone
忘掉 jq 和 class component 吧，雕不出花来的
|
 |
34
wildman9527 2025 年 5 月 29 日
@Wxh16144 #10 还有刚失业的年轻人。
|
 |
35
promiser3d 2025 年 5 月 29 日
@elantion 既然是学东西，当然是学新领域了。时间成本也是成本啊。
|
 |
36
kelvansun 2025 年 5 月 29 日
我在想，你既然已经失业了，可以试着拓宽一下搞开发以外的行业。
|
 |
37
Avedge 2025 年 5 月 29 日
“玩得很内疚，总感觉在浪费时间，想是不是该沉下心来学习”
哎，玩就是罪恶 |
 |
38
hongns 2025 年 5 月 29 日
我觉得 36 楼说的有道理， 搞开发可能暂时不太适合了。
|
|
39
elantion OP @shunia 谢谢大佬的点评
1. 我个人觉得单向流就是痛点，因为限制了组件摆放位置，所以想从框架层面去改进。引用关系想不到为什么会乱套？ 2. 直接供外部使用不觉得有什么限制，状态变量放到外部就会影响组件的独立性。 3. 当然也可以在组件内把调用方法写好，当前就可以这么实现。额外的 state |
|
40
elantion OP 不小心按错了，接上
3.....额外的 state 是用来控制组件内的 dom 元素，毕竟写 jsx 还是方便一点。 4. 如果可以不用框架解决当然最好，但我还没想到好的办法 |
|
43
elantion OP @NathanInMac 初略看了下，感觉跟 react 差不多，跟我的设计理念不太一样，不过他的性能看上去真牛 b
|
|
44
elantion OP @zixianlaiye 目前资产很多，暂时不用考虑钱的问题
|
|
45
elantion OP @molvqingtai 不知道我理解对不对，我看 Lit 依然需要 @property 去控制组件内状态，在跨组件调用上依然需要全局变量帮忙控制，我可以理解为简化版的 react+redux ？
|
 |
46
acthtml 2025 年 5 月 29 日
hi ，请问下楼主，后续有面试过吗，薪资变化大吗？
|
|
48
elantion OP @acthtml 朋友帮忙内推过腾讯，技术没问题，所有关卡都过了，就是薪资定得太高，没成，实际上定的跟以前一样。你是要跑路吗？建议还是忍忍，目前大环境极差
|
 |
49
seekafter 2025 年 5 月 29 日
老哥, 建议先做产品 ppt, 有人问, 有人关注, 有人愿意付费后再去开发软件.
不要上来就写什么框架/程序, 先找产品后开发 先学会画饼, 保证有入账最重要 |
|
50
elantion OP @nzbin 好久没关注 Angular 了，我还停留在零点几的版本概念，国内用得很少。我刚看了下 service ，貌似是为了解决 api 调用的问题？而我要解决的是组件间调用的问题，好像不太一样
|
 |
54
patrickpu 2025 年 5 月 29 日
用不完的框架
|
 |
55
iorilu 2025 年 5 月 29 日
现在前端早 ai 化了, 没人研究技术
实在有空, 建议搞点实际的 ai 桌面产品, 找一个小的需求, 把他自动化 任何实际需求能 ai 自动化, 肯定就有市场需求, 就能赚钱 |
 |
56
felbryiozzzz 2025 年 5 月 29 日
|
|
57
felbryiozzzz 2025 年 5 月 29 日
今年 31 ，同为前端，还在职中。目前我是两个思路
一是持续搞组件库，用 lit 做 web component 组件库。统一各个组件的 api ，适配移动端和 PC 端。持续迭代积累，后期组件成熟针对 form 、table 类常见的业务场景做更多复合组件，降低开发成本。 （思路一同时服务我的工作和副业） 二是给身边的自由职业朋友做系统。其实我觉得很多个体，小商户也都是需要系统的，只是一遇不到资源、二服务器和域名、开发成本。现阶段有 AI 加持，Nodejs 方面有 strapi 这类框架，开发这种少量人使用的系统还是方便不少的。阿里的 99 机型，或者家用 NAS/主机，开 ipv6 ，也能跑起来自己的小系统，这方面成本是能降下来的；我给朋友开发不收钱，但是一旦产品成熟，卖给他们圈子里的人，再扩展出去，一个就卖千元内，还是有的赚的 |
|
59
elantion OP @iorilu 话也不能说得那么绝对，我不还在研究吗？ AI 有 AI 的好，但他们训练还不是一样要人提供语料？是吧。
AI 产品化的东西也做过，也有成品，只是离赚钱还差得远 |
 |
60
cocong 2025 年 5 月 29 日
小项目用 React.createRef 就够了，大项目你这个确实不错，但可能意味着混乱，你某天删了某个组件的接口，你都不知道有其它地方在用，当然编译工具足够强大可以做到提前判断。
至于你说的状态失控，例如明明可以组件内控制的变量非要用 props 传过来，这个其实正是没有用全局状态导致，你的项目也是在思想上了全局状态管理一样，像 event bus 、redux 、mobx 、contenxt 包括你的，都是全局状态管理，无非是用法不同，我觉得区别不大。 |
|
62
elantion OP @felbryiozzzz 我觉得你想法真的很好！
1. 组件库思路很棒，又能刷 KPI ，又能提高自已的技术水平 2. 我之前也想过做系统，但碍于脸皮薄，不好意思跟别人说。这个确实很有搞头，期待你的成功！ |
 |
64
linkopeneyes 2025 年 5 月 29 日
@elantion #50 不是哦，service 能依赖注入就可以解决组件之间的调用问题了
|
 |
65
xuanbg 2025 年 5 月 29 日
前端的痛点哪里是 OP 你说的这些……包括后端也是。写代码难的不是把代码写出来，而是难在如何正确的把代码组织起来。
可悲的是，这玩意会的人根本不需要学，不会的人也很难学得会。 |
|
66
elantion OP @tonytonychopper
1. 这个确实是个问题，但其他框架也会有这个问题，这个也是在我的预期之内，只能靠架构层面去解决。 2. 我想法是：组件内部的状态变量就应该由组件内部去控制，而不像现在那样需要在外部传入 props 去控制。 3. 这个项目架构设计问题了，例如弹窗 isOpen 变量，你没办法限制他是在组件内去变更还是组件外去变更，无论你用的是 react ，vue ，还是我这个框架都会有这问题。至于限制调用边界问题，可以试试代理模式，所有组件都必须通过代理去调用，然后在代理层面去限制那些地方可以使用（这个跟任何框架都没关系）。 |
|
68
elantion OP @sjhhjx0122 看了下确实可以，不过 service 是单例吧？我这个可以实现多例
|
 |
69
hello158 2025 年 5 月 29 日
老哥还有热情还想研究，挺难得的。
|
|
70
elantion OP |
|
72
shunia 2025 年 5 月 29 日
直接调用组件的方法，和通过一个“管道”传递组件所依赖的属性，很明显后者更优。
直接调用就会遇到一个是重构问题，一个是 22 楼说的大乱斗的问题，也就是我说的引用乱套的问题。另外你这里如果要支持 TS ，需要把组件确定成一种类型，把组件确定成一种类型比把属性确定成一种类型，心智负担要大的多。 通过某种“管道”传递属性，第一个降低心智负担，第二个管道可以实现 transform/pipe ，这也是多种状态管理库的灵活性所在。 你这个其实是给 react 套了一个外壳，增加了两个功能，一个是直接引用组件，一个是强制 class+内部 state （也就是早期 react ）的写法。说的苛刻点，不知道框架是框在哪里。 |
 |
73
youyouzi 2025 年 5 月 29 日
老登精力还挺旺盛
 |
|
74
linkopeneyes 2025 年 5 月 29 日
@elantion #68 在当前组件重新注入服务就可以实现多例了
|
|
75
elantion OP @shunia 谢谢你的建议
1. 重构问题那是项目架构的问题，我觉得用那种框架都一样，用 react 也一样。 2. 用 ts 确定组件类型为什么会比确定属性类型心智负担更大？不太理解你的意思。我的框架也一样可以走管道更新，而且更简单。 3. 设计上确实套用了 React 很多概念，文中也说了。我这种设计需要推倒重写，所以就整了这么个框架。 苟刻点没关系，我内心强大 |
|
76
elantion OP @sjhhjx0122 我后面试试看，如果是一样设计，我就删库跑路了，哈哈
|
 |
78
94 2025 年 5 月 29 日
可以先把各个前端框架都用一边，去看一下他们是如何解决你认为的那些痛点的，是框架自己提出解决方案，还是依靠社区。
如果全都尝试过了并且你觉得解决的不够优雅，再开始设计你自己的框架，而不是先闷头做出来。 ---- 另外就是得想明白这个项目目的是什么，单纯有一个写框架的想法，其实就和造轮子是一样的。 得想清楚这个框架你自己会不会去用于后续自己的产品，能不能长期坚持下去，以及正反馈来源是什么。 但现在前端圈的风向明显已经转向到了工具链这种基础设施上面去了。其实就是说明了现在前端框架基本上已经卷到头了。很难再有什么关注，就代表了很难会有积极的正反馈。 |
 |
79
opentrade 2025 年 5 月 29 日
六千块，创业？咋感觉匪夷所思
|
 |
80
jiaorong 2025 年 5 月 29 日
直接当 up 主，直播开发过程，比开发结果赚钱
|
|
81
elantion OP |
|
84
iorilu 2025 年 5 月 29 日
@horizon 具体干啥当然要自己研究
但我说的绝对没错 你只要找到一个实际存在的需求, 用 ai 把它完全自动化, 做一个桌面软件实现 基本就有收益 难点当然在找到一个准确的需求, 只要怎么做, 现在又 ai 确实没那么难 |
 |
85
gangstar902 2025 年 5 月 29 日
怎么样才能不用考虑钱的问题
|
|
88
elantion OP @gangstar902 我没有参考性，我是房东
|
 |
90
jettzhang 2025 年 5 月 29 日
非必要，我现在选技术栈都是优先选 AI 熟悉的
|
|
91
nzbin 2025 年 5 月 29 日
> 好久没关注 Angular 了，我还停留在零点几的版本概念，国内用得很少。我刚看了下 service ，貌似是为了解决 api 调用的问题？而我要解决的是组件间调用的问题，好像不太一样
@elantion 组件间通信最简单的方式就是 service ，复杂的状态管理方案也有很多，非常建议深入了解 Angular |
 |
92
fulvaz 2025 年 5 月 29 日
对你没搞头啊老哥, 应届生还可以跟他聊下怎么设计的框架, 顺便问下他对状态管理的理解, 再让他想想为什么要禁止通过当前组件随便修改其他组件的状态, 再跟他聊下软件设计, 就用这个案例讨论下依赖会有什么问题, 比书上聊的有意思多了.
但对你的要求是拥有解决大规模未知问题的能力, 意味着深厚业务背景+强劲的沟通能力+扎实的技术基础 |
 |
93
moluyouwo 2025 年 5 月 29 日
怎么跟无头苍蝇一样瞎搞，不如去自驾游。
|
 |
94
steptodream 2025 年 5 月 29 日
楼主 根据 ps 设计稿设计前端页面 多钱一页
|
 |
95
shakaraka PRO 2
像是弹窗的实现，我真心建议你看看 https://material.angular.dev/components/dialog/overview 是如何设计的。
|
 |
96
maxwell29 2025 年 5 月 29 日
前端这么惨吗？祝福
|
 |
97
seansong 2025 年 5 月 29 日
偶尔写一下前端，不专业，个人感受，op 这种写法，我感觉反倒更混乱了，更不好管控状态
|
 |
98
huashuinengshou 2025 年 5 月 29 日
这年头还能潜心钻研技术，我只有瑞思拜了。。。。。
|
 |
99
zw2019 2025 年 5 月 29 日
这。。。 我觉得要不研究下鸿蒙 OS 的 app 开发，抄几个 android 、ios 的 来个首发，说不定还能搞点钱。我是真不希望还有前端的框架出现了，学不完、根本学不完呀
|
 |
100
suni PRO 跑外卖吧。。。
|
Select Language