- 主题:4个月了,没找到工作,大龄了确实惨,学习C++都难投入
看你这么回我,我很火大啊。不过算了。有容乃大。
我自己琢磨。谢谢你鄙视我。
【 在 eGust 的大作中提到: 】
: 我觉得吧,你还是最好先搞清楚一个概念是怎么回事
: esbuild 跟 webpack 在限定某些条件的前提下,的确是可以比较的。但是我提到的两个技术栈里,两者完全扮演不同的角色。所以你抛出的这个问题,就跟你前面问为啥不把 esm 编译成 wasm 一样蠢。我完全没办法回答,为什么不能把苹果榨成橙汁这种神奇的问题
:
--
FROM 117.136.0.*
前端世界,现在是怎么看blazor的?
【 在 eGust 的大作中提到: 】
: 另外你觉得 wasm 还需要做什么基础工作?给每个语言写一套 blazor 出来?该由 ecma 委员会来做还是由浏览器厂商做?
:
--
FROM 123.116.223.*
大学老师最好,一周上一天班
【 在 saynothing 的大作中提到: 】
: 找到工作不难,难的是不加班、不事儿多的公司。 真心少。。另外,就是钱怎么算
:
: 真心感觉,码农和马戏团耍杂的差不多。
: ....................
- 来自「最水木 for iPhone X」
--
FROM 223.104.38.*
不知道啊,除了 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.*
看,学 javascript 至少要掌握 12个概念, php 不需要那么多就能开干
【 在 eGust (十年) 的大作中提到: 】
: 你是认真的吗?
: 从开发体验来讲,最好的 gui 开发环境,就是 dev server + 跑在浏览器里的主流前端库,没有之一。react/vue 之类都有自己的 debug 插件,浏览器的 debugger + sourcemap 绝对不是 ide 能比的,再加上各种 dev server 支持主流库的 hot module replacement,实在是想不出
: 前面说的基于 esm + esbuild/swc 的 dev server,不论是启动时间,还是从保存更改到反映到页面上的延迟,都是秒杀 webpack-dev-server 的。这也是为什么我说 webpack 快发展到头了。
: ...................
--
FROM 183.23.75.*
我在本版吹过几样关于前端的东西,比如 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.*
为什么选择 vue 而不是最保险的 react 呢?
【 在 eGust (十年) 的大作中提到: 】
: 这东西实际跟前端关系不大,.net 码农喜欢就可以了呗,剩下的就看对它的信心了。我打算等它再发展个一年半载的,找个时间写个小东西稍微体验一下。
: rails 早些年推的前端技术是 turbolinks,这两年新推 stimulus,因为类似的 htmx 技术跟 turbolinks 有冲突。除了 rails 社区能有几个听说过这俩货的?
: 从架构层面来看,设计一个系统应该尽量 decouple 不相关的东西。wasm 看起来的确美好,但如果有一天某个技术不再流行了,想要维护已有的代码都是非常困难的事情。最典型的就是 cobol,一群七老八十的老头老太太拿着超级高的工资维护几十年前的代码。
: ...................
--
FROM 14.145.21.*
我们公司有自己的情况,除了我以外,没人用过 react/vue 之类的,jquery 还是 1.12.4,sementic ui 似乎是某个 beta 版本。当初选 vue 是综合各种因素考虑的结果,今年整出来要用 composition api 替换掉老 api 的幺蛾子的时候,我也是忐忑了好一阵子的。
选 vue 主要是有以下几个因素:
首先,就算是 single file component,html/css/js 也依然是分开的写的。这样就少了一个阻力,不然第一眼没看懂 jsx,就很可能因为认为需要学一套新语法而遭到抵制。
其次,vue 的入门门槛更低,哪怕不会搭 node 的架子,也能用传统方式写代码。而相对来说 react 就必须得先把 webpack 那套东西搭起来。
第三,react 是非常明确的 fp 思维,单向数据流需要彻底改变思维习惯,这是一个非常巨大的思维习惯的转变,不然会觉得它难用的要死。vue 虽然从数量上来看,核心概念更多,但除了 computed 不能有 side effect 以外,并没有太难理解的东西。数据的双向绑定虽然从实现上来看是 magic,但对于用户来说却非常自然。
第四,vue 的文档写的非常非常好,不但组织的有层次,而且连各种常遇见的坑也都连原理带最佳实践都给出了。相比之下 react 的文档组织就显得不咋样了,必须得翻 blog,才能找到常见的坑,以及官方推荐的最佳实践。
另外,vue 自带了 vuex 和 router,这样也避免了选择困难。vuex 只有4个核心概念,但在实际使用中,官方推荐外部用3个就够了,而它们又对应着 data/computed/methods,剩下一个 mutation 只从 action 调用就够了。反观 react,是选 redux、mobx 还是其它?如果 redux 需要再学一堆概念,然后处理异步又要面临选择,自己笨写呢,还是 thunk 或者 saga?redux-thunk 跟 redux-saga 比起来就不算啥了,然而也是一堆的概念。所以虽然 react 自己的核心概念不多,但想用出最佳实践来,需要理解的概念就太多了。vue 用官方的东西搭个架子,按照文档来就基本不太会出错。虽然在后来的实践中,还是有同事掉过官方提醒过的坑里好几遍,不过随着 vue3 的到来,很多坑自然随着 Proxy 消失了。
最后跟我们自己的项目也有关,原本计划是先在一个全新的小项目里试水,如果可以的话再在主项目里应用。老项目由于种种原因,锁在了7年前的 rails 4.2 升不上去,所以用一个不需要 webpack 也能用的新技术也在考虑之内。
前端的市场极其巨大,除了 react 也完全再容得下几个大户。目前来看,vue 也已经达到选它不会有错的影响力,新手也不会有找不到工作的担忧。按照 yyx 的估算方式,刚才瞅了一眼 chrome web store,react devtools 有 2M+ 用户,vue devtools 是 1M+,跟几年前一样,还是 2:1。而且由于 vue 的设计,对于有 angular.js、react 经验的人来说,都是极容易上手的,因此也并不太需要担心招人的问题。除非 vue 再自己作死,要整什么废掉老 api 的幺蛾子,应该是能和 react 长期共存一直到下一代革新的技术
【 在 keygen (失落灵魂之囚) 的大作中提到: 】
: 为什么选择 vue 而不是最保险的 react 呢?
--
修改:eGust FROM 115.188.162.*
FROM 115.188.162.*
赞,感谢打这么多字讨论
【 在 eGust 的大作中提到: 】
: 这东西实际跟前端关系不大,.net 码农喜欢就可以了呗,剩下的就看对它的信心了。我打算等它再发展个一年半载的,找个时间写个小东西稍微体验一下。
: rails 早些年推的前端技术是 turbolinks,这两年新推 stimulus,因为类似的 htmx 技术跟 turbolinks 有冲突。除了 rails 社区能有几个听说过这俩货的?
: 从架构层面来看,设计一个系统应该尽量 decouple 不相关的东西。wasm 看起来的确美好,但如果有一天某个技术不再流行了,想要维护已有的代码都是非常困难的事情。最典型的就是 cobol,一群七老八十的老头老太太拿着超级高的工资维护几十年前的代码。
: ...................
--
FROM 123.116.223.*