- 主题:4个月了,没找到工作,大龄了确实惨,学习C++都难投入
为啥没变化就是走进死胡同了?
另外这几年变化也很明显,首先是 typescript,现在已经是 github 上第4大语言了,仅次于 py 和 java
其次是 es module,主流浏览器都已经支持,绝大多数流行库除了 cjs 外也都在提供了
还有正在用 native 语言重写 js/ts 工具,比如基于 go 的 esbuild,rust 的 swc,这俩都可以替代 babel/typescript
主流前端库 react 和 vue 都开始使用更 fp 的 hooks api,再过个三五年基于类的控件就变成没人写的 legacy 语法了
建立在 esm 之上,现在正在革 webpack 的命,开发直接 esm,打包用 rollup,再发展两三年 webpack 估计也就走到尽头了
真心劝你不要再评价前端了
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 已经好几年没变化了吧。。前端走进死胡同了。
--
修改:eGust FROM 101.98.83.*
FROM 101.98.83.*
主流浏览器早就支持了
你觉得还需要搞啥?
【 在 littleSram (littleSram) 的大作中提到: 】
: wasm还搞不搞了
--
FROM 101.98.83.*
你真的明白你在说什么吗?
【 在 littleSram (littleSram) 的大作中提到: 】
: 我意思是还编译成esm干啥
: 为啥不直接wasm
--
FROM 101.98.83.*
所以是世界错了?
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这话说的。。龙芯已经支持执行 mips 指令集,,还需要啥?
: 需要指令集上面一堆的基础设施啊。
: wasm + webgl + coroutine 才是前端最后的归宿。但目前前端社区的选择都是相反的。所以我说前端社区进了死胡同。
: ...................
--
FROM 101.98.83.*
另外你觉得 wasm 还需要做什么基础工作?给每个语言写一套 blazor 出来?该由 ecma 委员会来做还是由浏览器厂商做?
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这话说的。。龙芯已经支持执行 mips 指令集,,还需要啥?
: 需要指令集上面一堆的基础设施啊。
: wasm + webgl + coroutine 才是前端最后的归宿。但目前前端社区的选择都是相反的。所以我说前端社区进了死胡同。
: ...................
--
FROM 101.98.83.*
你是认真的吗?
从开发体验来讲,最好的 gui 开发环境,就是 dev server + 跑在浏览器里的主流前端库,没有之一。react/vue 之类都有自己的 debug 插件,浏览器的 debugger + sourcemap 绝对不是 ide 能比的,再加上各种 dev server 支持主流库的 hot module replacement,实在是想不出更方便快捷的开发体验了。
前面说的基于 esm + esbuild/swc 的 dev server,不论是启动时间,还是从保存更改到反映到页面上的延迟,都是秒杀 webpack-dev-server 的。这也是为什么我说 webpack 快发展到头了。
至于 bundle,就算没有 ci/cd,最多也就是建 pr 之前打包一次而已。比起干点儿啥都得手动刷新页面的开发体验,这能算啥?
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 我跟你讲 javascript 需要等编译
: (所以学习不需要等编译的 php 吧
--
FROM 122.59.179.*
我觉得吧,你还是最好先搞清楚一个概念是怎么回事
esbuild 跟 webpack 在限定某些条件的前提下,的确是可以比较的。但是我提到的两个技术栈里,两者完全扮演不同的角色。所以你抛出的这个问题,就跟你前面问为啥不把 esm 编译成 wasm 一样蠢。我完全没办法回答,为什么不能把苹果榨成橙汁这种神奇的问题
【 在 littleSram (littleSram) 的大作中提到: 】
: esbuild为啥比webpack快,除了用go写的。
--
FROM 101.98.83.*
不知道啊,除了 vite 的以外,从来没读过其它 dev server 的代码
如果文档里没提的话,估计就没设计吧
【 在 tgfbeta (右旋肉碱) 的大作中提到: 】
: 打断一下请教一个问题
: devserver那个websocket的地址能手动指定么?
--
FROM 115.188.162.*
这东西实际跟前端关系不大,.net 码农喜欢就可以了呗,剩下的就看对它的信心了。我打算等它再发展个一年半载的,找个时间写个小东西稍微体验一下。
rails 早些年推的前端技术是 turbolinks,这两年新推 stimulus,因为类似的 htmx 技术跟 turbolinks 有冲突。除了 rails 社区能有几个听说过这俩货的?
从架构层面来看,设计一个系统应该尽量 decouple 不相关的东西。wasm 看起来的确美好,但如果有一天某个技术不再流行了,想要维护已有的代码都是非常困难的事情。最典型的就是 cobol,一群七老八十的老头老太太拿着超级高的工资维护几十年前的代码。
但是如果选 react,作为现在第一流行的技术,如果项目出了任何问题,也没有任何人会认为 react 会成为任何理由。前一阵刚好有篇文章比较火:
No One Ever Got Fired for Choosing React
https://jake.nyc/words/no-one-ever-got-fired-for-choosing-react/
这个标题是有来头的:nobody ever got fired for buying IBM equipment
现在 typescript 也正处于高速发展时期,可预见的未来也是越来越多的库支持,越来越容易招人,所以选起来也是没错的。
我们公司用 rails,但我是对 turbolinks 和 stimulus 嗤之以鼻的,而且在我的努力下,现在也基本确定前端走 vue 路线了。ruby 跟 py 在定位上是高度相似的语言,这种同一生态位上的竞争基本就是胜者全赢,我们最近半年都一直在招人,非常难招到。所以以后哪天突然决定换技术栈了,我也一点儿都不奇怪。
blazor 有微软在撑腰,从这些年的表现上来看,微软在开源社区里还是相当有信用的。不知道天朝环境如何,但在海外 .net 还是非常有市场的,把自己绑在 .net 技术栈上也不一定会吃亏。剩下的就看自己怎么考量了,有信心两三年之后市场上能招到人,那就用呗
【 在 leadu (leadu) 的大作中提到: 】
: 前端世界,现在是怎么看blazor的?
--
FROM 115.188.162.*
我在本版吹过几样关于前端的东西,比如 react,比如 typescript
实际也跟我预言的一样,react 革了 gui 开发的命,现在 flutter、swift ui、blazor 都是在用不同的语言实现 react,几家大公司都用实际行动认证了 react 好
当年 ts 连 github 前10都没进的时候,我也说过,js 发展的速度是别的语言赶不上的,用不了几年 go 就连小弟 ts 都打不过了,这不今年都排第4了
我现在预言 webpack 再发展个两三年就到头了,大家也可以等着看。前段时间 svelte 的作者 rich harris 专门谈了这件事,提到了 snowpack,没隔多久 yyx 也专门谈了这件事,推的当然是自家的 vite。目前来看这俩取代 webpack 的可能性最大,但再杀出个更有优势的也不是没可能,比如 react 家的 rome(我没去了解过它怎么实现的 dev server 所以别当真)。
其它技术我还吹过 graphql 和 rust,但我也说过,gql 的流行会非常缓慢,而 rust 注定不会成为大众化的语言。
对于没亲自动过手的东西,如果别人说我不懂,我是不会再多嘴的。但如果是我花时间认真研究过的东西,信我的话基本不会吃亏的
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: 这种话术和传销很相似:
: 某个xxx特别厉害,什么你不知道?算了,我也不屑和你这种俗人解释。你自己慢慢修炼吧。等你哪天顿悟了你就会懂我说的。
--
修改:eGust FROM 115.188.162.*
FROM 115.188.162.*