[前端]年轻人第一次计划辞职，虽然工作了两年感觉自己毫无竞争力怎么办

This topic created in 1764 days ago, the information mentioned may be changed or developed.

垃圾三本毕业，培训班出身，19 年培训完在北京用三年假简历得到了现在的工作。

第一年公司算上我只有两个前端，疯狂加班，基本是坐着地铁末班车回家，通宵了几次。第二年又招了两个前端，我也终于闲了下来。刚入职时到手 11k，第一年结束被评了个优秀员工，现在到手 12k 。

公司有两套技术栈，一套是 react，一套是 jq+bootstrap+echarts （老项目）。我前半年还在写 react，后面一年半就被安排负责老项目了。每天写的东西都是毫无营养，稍微有点难度的东西，也都是上网找了找插件框架之类的解决的，对比两年前的自己甚至可以说退步了。

前阵子上海的几个同学来北京玩了几天，交流了一下，都在劝我辞职换个工作。我也想换工作，但是我觉得自己毫无竞争力，本来就是底层纯搬砖的，每天做的都是页面元素的 curd，到时候面试问起来我说写了一年半的 jq，感觉会被笑死。

每天晚上睡前都有点焦虑，想接下来两个月赶紧学些东西，又不知道从何学起。所以想来问问大佬，我该怎么提升一下自己，如果要辞职该怎么准备。

React

辞职

毫无

到手

63 replies • 2021-07-25 13:14:57 +08:00

WasteNya

Jul 20, 2021

所以
你现在是想在简历上写 3 年还是 5 年还是 2 年？
你觉得出去后还能找到 12 k 的工作吗？
抱歉，我有点暴躁，这水平只顶我的半年

hisa

Jul 20, 2021

@WasteNya 没什么暴躁的，我自己什么水平自己也知道，比起好大学里认真出去做几个月实习的人都不如。
我是想如实按两年找的，也预测到大概率找不到比现在更高待遇的工作。但是如果一直这么干下去，可能会越来越难。当局者迷，我自己的想法很局限，所以想来听听大神们能不能给一些建议。

3dwelcome

Jul 20, 2021

@WasteNya 问题是楼主公司技术栈就是 JQ，换任何人来工作半年，也都是这个水平。

除非他上班摸鱼，写其他框架代码或者刷 leetcode，水平才会提高。

WasteNya

Jul 20, 2021

@3dwelcome 能提升的多的是，换个 react 不思进取还不是写业务每提升？不要局限什么框架，要思考如何让这个项目开发更加有效率，增加点工程化，模板化的工具规范起来，减少工作量，老项目也可以嵌入 react，就看你怎么个来法，虽然我这边也是 react，但我每天反而写的 json 和 nodejs

izhaoo

Jul 20, 2021 via Android

多背背面经，增长一下短期水平

hisa

Jul 20, 2021

@WasteNya 我这两年确实是不思进取了，就算是 jq，如果能写出来优秀的组件也是自己能力的提升。我接手的老项目都是大同小异，能够写成组件去优化提升效率的地方很多。还是我想的太少太片面了，非常感谢大佬指导🙏。

hisa

Jul 20, 2021

@3dwelcome 最近有时间摸鱼了，跟个无头苍蝇一样，自己搭了一个 react 的项目想做个人网站，也在看掘金的面试题，也想用 hugo 写博客记录下来，但是自己能记录的也是从别人博客上那里抄来的，我自己产出不了什么内容。

3dwelcome

Jul 20, 2021

@WasteNya 每个公司工作流都不一样，在业务为导向的公司，就好好写业务，好好搬砖。

想什么开发其他的模板化工具，在老板眼里，就只是不务正业。

hisa

Jul 20, 2021

@izhaoo 有在看掘金的面试题了，大佬们整理的很详细，突击两个月试一试。

brucep

Jul 20, 2021 via Android

工作忙不忙，不忙的话可以一边工作一边准备跳槽。
可以先面向面试学习，之后可以一边面试一边系统学习，先跳个中厂

statement

Jul 20, 2021

jQuery 应该比 React 占有率更高但一般用 jQuery 的公司，后端就帮着一起干了

bytenoob

Jul 20, 2021

这次用 8 年假简历就可以了

WasteNya

Jul 20, 2021 via Android

@3dwelcome screw u guy

hisa

Jul 20, 2021

@brucep 非常感谢。我目前是这么打算的。
@statement 确实，有时候我不在公司着急要改一些简单的事后端就自己顺手做了。
@Yc1992 不好意思，我也知道在计算机行业用假简历是比较令人唾弃的事，但当时确实是没什么办法，自己身上背着培训班的贷款，在北京找个三四千的实习开始干怕是要饿死了。

3dwelcome

Jul 20, 2021

我始终觉得跳个好的公司平台，比个人努力要更重要。

在小公司只依赖个人学习，来提升水平是很有限的。一是大部分人都不自觉，有工作压力后，学习缺乏动力。二是个人技术想要落地，没合适平台还是很难的。

比如把老项目 JQ 改造成 React，不是技术上可不可以。而是费了那么大功夫后，时间花的值不值的问题。

A388

Jul 20, 2021

@WasteNya 就像你说的前端自动化，或者其他的。但也不是每天都在写吧。大多数的时间和人都是在写无聊的，没有营养的业务代码吧。特别是大公司，更是业务代码。底层的有专门的人写

3dwelcome

Jul 20, 2021

@WasteNya 你觉得自己技术很强，也许只是自以为的强。

真正的强，1 大项目落地，2leetcode 国际排名。

lsiufD

Jul 20, 2021

我是 18 年毕业->培训->工作的，水了 1 年简历。刚入职的时候 8K，离职时 10K，重新找工作的时候我是选择重新写简历，写一年工作经验，就不水以前培训写的经历了，换工作后 11k 至今

A388

Jul 20, 2021

@3dwelcome 大项目这个问题，其实一直都比较困惑。
什么叫做大项目呢？比如淘宝？阿里云什么的？
不知道你是不是前端。
我经常看见有人说 react 比 vue 适合大项目。但是这句话就看不太懂。什么叫大项目？能解释一下吗？没有别的意思，就是想了解下。大项目到底指的什么。

3dwelcome

Jul 20, 2021

@A388 “我经常看见有人说 react 比 vue 适合大项目。”

我对这句话的理解是，前者是库，后者是框架。一般来说，库的适用范围，是会比框架稍微广泛那么一点。

至于是不是大项目，还是要看有多少人一起开发，相互怎么合作了。如果团队里所有人技术栈都是 VUE，那用 VUE 也挺合适的。

MorningStar0

Jul 20, 2021

@A388 对于大项目，我理解的话一般来说就是业务逻辑基本全部在前端交互上，比如 ps online 和其他的一些低代码平台

bytenoob

Jul 20, 2021

@hisa 总的来说就是不要沉溺于舒适区，不论是刷题，学习新技术，还是旧代码重构之类的。如果自身驱动力不足，就依赖外部压力，换一份压力更大的工作，当然不能是重复的无意义加班，最好是技术上的挑战，团队必须有大牛并且愿意带自己，自己体会吧

q673115816

Jul 20, 2021 via Android

跟我情况差不多，我更是写了三年 JQ

3dwelcome

Jul 20, 2021

@MorningStar0 "业务逻辑基本全部在前端交互上"

前端代码写太多逻辑，并不是好事。自从 5 年前有了 WASM 后，现在除了前端和后端，还有中间端粘合层的 WASM 。

特点就是能集合所有语言的大成，JS 没有完善的单元测试，有些代码 BUG 只有运行期才蹦出来，不好查错。而 WASM 可以化身任何成熟的语言，比如用 Java 写前端。粘合层是很强大的，同一套代码，前端后端都能用。

Desiree

Jul 20, 2021

多去面试才能知道自己的不足，既然对编程没有天生的爱好，那就面向工资编程嘛。这也比忙头苍蝇学习好

A388

Jul 20, 2021

@MorningStar0 好像懂了那么一点点。

A388

Jul 20, 2021

@3dwelcome 谢啦

NotreDame

Jul 20, 2021

@WasteNya 老哥，你说的挺在理的，不知道为啥这还有人杠。

baojie223

Jul 20, 2021

@3dwelcome 好奇问一下，你们公司现在有项目在用 wasm 了吗

3dwelcome

Jul 20, 2021

@baojie223 有啊，当成 side 库，可以用为啥不用。

别的语言有不少代码积累，转译一下就可以了，特别适合零依赖少的小型算法。

现在的浏览器，包括 webview 都支持 WASM 的。小程序不支持，可以把 WASM 退化为 asm.js ，那样也支持了。

ccsulzf0627

Jul 20, 2021

我工作 5 年也是

MorningStar0

Jul 20, 2021

@3dwelcome
2021 年的今天,wasm 依旧没办法直接操作 dom （请不要说通过调用某个 js 提供的库进行操作），且 wasm 基本是用于解决 CPU 密集的并行任务的（比如音视频解码），我所说的交互逻辑指的是：对 UI 界面有大量的交互操作，产生的状态需要实时展示，状态的数量级在 4 位数左右，上述产生的状态不需要关系存储，频繁的读写操作发生在客户端的内存或缓存中。

综上所述，wasm 目前（ 2021 年）并没有提供对前端强交互场景的强力支持，只是对一些垂直领域，例如：音视频的简单编码，加密文档生成提供了一些支持。你提出 wasm 并不能很好的支持你的论点

且上述 wasm 提供的特性，对转译成 wasm 的程序的原始代码有一定要求：
1 、并发计算。wasm 目前没有提供 webwork 的调用
2 、系统 API 支持，例如 linux 的 fork

再讨论 wasm+三方库可操作 dom 的方案。这一方案中，由于 wasm 的运行，目前仍然依赖 JS 胶水脚本，对 wasm 暴露的 event 进行调用。所以，如果在非 CPU 密集场景下，使用 wasm 甚至会带来系统性能的降低。

nutcloud

Jul 20, 2021

可以投递坚果云前端岗位试试哦，[email protected] ，我们刚好在 V2EX 上发了招聘贴 https://www.v2ex.com/t/790648#reply7

3dwelcome

Jul 20, 2021

@MorningStar0 我总觉得你对 wasm 有误解，wasm 又不是为了浏览器而生，而是为了让浏览器成为它众多运行平台之一。

本质上目标是用 IR，把所有语言通过堆栈虚拟机的方式，彻底打通，能相互调用。

你说 wasm 不能操作 DOM, 我贴一段 wasm 编译器的 example 代码，你如果觉得这都不算是操作 DOM，那我也无话可说。

MorningStar0

Jul 20, 2021

@3dwelcome 如果你说的操作 dom 是编译之后，通过 js 操作 webapi，也算是直接操作 dom 的话那就是吧。。。。

一段 mdn 原文：
Emscripten first feeds the C/C++ into clang+LLVM — a mature open-source C/C++ compiler toolchain, shipped as part of XCode on OSX for example.
Emscripten transforms the compiled result of clang+LLVM into a .wasm binary.
By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this.

其链接： https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts

MorningStar0

Jul 20, 2021

@3dwelcome 并且，我举出例子，尝试定义了下什么是大型前端项目。目前还是没看懂 wasm 对这个“大型前端项目”的定义有任何的补充

Lemeng

Jul 20, 2021

有经验，不太弱，一般也能找到的，别有太多心理负担

3dwelcome

Jul 20, 2021

第一，我贴的代码并不是 Emscripten 的，所以这段 mozilla 引用没太大价值。（虽然 Emscripten 也有提供类似 DOM 胶水库）

第二，WASM 传值都是浏览器兼容的 Raw 指针，一大堆状态可以批量传递，对运行速度不会有太大损失。举个例子，C++ COM 的每一次调用，都是通过 vtable 中转的，也没人说慢。那么 WASM 操作 DOM 中转一次也是很正常的。设计成 DLL/SO 一样，用之前导入 /导出函数，都和主程序进行动态地址绑定，这才是最合理的模块分离技术。

如果有人觉得 WASM 运行太慢，那只能说代码接口设计有问题。

MorningStar0

Jul 20, 2021

@3dwelcome
1 、所以，我始终说的都是 wasm 无法 "直接"(引号表强调) 操作 dom 有什么问题么？
2 、说慢是和直接用 js 操作都没进行比较的。或者说 wasm 解析 arraybuffer 的过程甚至会比 webapi 操作 dom 快？
3 、“导入 /导出函数，都和主程序进行动态地址绑定”，一个客观事实是，就目前生态而言，对 wasm 相关的 debug 工具链仍不完整。另一个主观疑问是，“最合理的模块分离技术”是指的，换个操作系统平台运行的时候，各种 DLL lost 么？
4 、 “如果有人觉得 WASM 运行太慢，那只能说代码接口设计有问题”，从来没有人觉得在 CPU 密集的场景下，wasm 运行慢，只是说在强调交互，并更新交互状态时，wasm 没有直接用 JS 操作快。

最后能否说明：wasm 对这个“大型前端项目”的定义有任何的补充

3dwelcome

Jul 20, 2021

@MorningStar0 所谓主流“大型前端项目"，大多都是基于自己的 DIFF DOM TREE 框架的。正常来说任何程序，不管是不是 WEB，算法才是最核心，最耗时间的部分。

就算你 UI 刷新率是 30fps，把 VUE 框架代码换成 wasm 来写，就会拖慢系统运行速度？我觉得不会吧。

你老是说有胶水层很慢，但又没拿出合理的数据来支撑这个说法，很难让人信服。

3dwelcome

Jul 20, 2021

@3dwelcome 写 Svelte 的大佬，在前端会议上出过一段视频，叫 Rethinking Reactivity 。

里面详细测评了 DOM 多了后，JS 的虚拟 DOM DIFF 算法有多慢! ( https://svelte.dev/blog/virtual-dom-is-pure-overhead)

包括 React 和 VUE 都慢，人家可以有正经数据支撑的。

所以卡这个锅 WASM 不会背的，因为根本就是虚拟 DOM 框架设计上的问题。

p1gd0g

Jul 20, 2021

得了，等楼上两位大佬吵完我再来看。
作为后端我看不懂但是看的津津有味。

charlie21

Jul 20, 2021

怎么办

MorningStar0

Jul 20, 2021

@3dwelcome
1 、“把 VUE 框架代码换成 wasm 来写，就会拖慢系统运行速度”，虽然但是，你要用一个框架和语言比运行速度么？至少也要用 YEW （使用 rust 构建 web 应用的框架）来对比 vue 吧？或者正面回答一下 “或者说 wasm 解析 arraybuffer 的过程甚至会比 webapi 操作 dom 快？”
2 、我说的任何一个场景有涉及到三大框架的任意之一么？我只是单纯的比较 JS 和 wasm 在 web 开发不同场景的适用性罢了。
3 、对于虚拟 dom 的 diff 算法的性能分析。是否应该权衡下，在我上文提到的上千个状态的管理问题，和与之带来的协同开发问题？当然了，如果要是这样比较的话，我们又回到了问题 1，wasm 真的比 js 在操作 dom 时快么？

3dwelcome

Jul 20, 2021

@MorningStar0 多说无益，你已经先入为主，思维被各种前端框架概念所束缚住了。

用框架写代码，的确带来便利性，但同时也带来一些局限性，DOM 数量是有上限的。我敢说，以同屏千个组件完全不卡著称的 figma，如果没有 wasm，绝对不会有今天设计老大哥的地位。

是 wasm 把这个可能变成了现实。没有 DOM = 无限 DOM，可能你不能理解吧。

MorningStar0

Jul 20, 2021 via iPhone

@3dwelcome
1 、我先入为主了什么？是我先提出的框架问题么？我始终在说 wasm 对于非 cpu 密集场景的一些性能和使用问题吧？
2 、你甚至不了解为什么客户端开发要引入 dom 的概念。对于这一点建议了解下“保留模式”和“即时模式”的区别。
3 、figma 大画布的解决方案确实很惊艳，但就如我最早的例子中 ps online，这个早期版本只是使用了 js 的产品，在高斯模糊计算，图片像素取色依旧表现不输原生啊。

3dwelcome

Jul 20, 2021 via Android

@MorningStar0 说先入为主，是你老是把 wasm 看成 react 之类的附属库，不断的强调 dom 胶水层调用性能。
然而对我来说，wasm 自己就是开发框架，是和 react 同等级别的破局者。
你不可能舍弃 react 历史包袱，所以你永远达不到 figma 的高度。总会遇到 DOM 数量上限问题，并且无法解决。

MorningStar0

Jul 20, 2021

@3dwelcome
？？？
我不知道你是怎么从强调 dom 调用性能这一点，看出我把 wasm 作为 vdom 框架的附属库这一点的。

其次，我强调 dom 操作性能的同时不也一直在强调 wasm 在 cpu 密集计算的性能？

舍弃 react 的历史包袱？我们早就舍弃了不止一个历史包袱：JAVA SwingGUI 由于标准库带来的不稳定问题；新的 Android 开发框架 Jacket compose ； Jquery 大量交互状态难以维护的问题。所以，舍弃 react 从来都不是问题，问题想是让我们用报告新的解决方案，一定是新的方案能提供更优的性能 /更好的维护性覆盖老方案至少 95%以上的场景，剩下 5%也可以用一些 geeky 的方式解决。

至于你说的 DOM 数量上限的问题，可以见得你对 DOM 到底要解决什么问题毫无了解

3dwelcome

Jul 20, 2021 via Android

@MorningStar0 别自己骗自己了，你是不可能抛弃 react 的，也不可能抛弃一大堆历史代码。
你也根本就不知道，类似 figma 的大画布 wasm 解决方案应该怎么写。
同一个 wasm 技术，你眼里就只有密集型计算，我眼里就是一整个迷你世界，一切皆有可能，性能反而没那么重要。
我们两个人说的东西，就不在同一个点上。

MorningStar0

Jul 20, 2021

@3dwelcome
确实，我一直在说某个技术现在能解决的问题及其优势的场景。而你更像一个“布道者”，就像当年推广 angular 的大漠穷秋