- 主题:4个月了,没找到工作,大龄了确实惨,学习C++都难投入
感谢分享
【 在 eGust (十年) 的大作中提到: 】
: 我们公司有自己的情况,除了我以外,没人用过 react/vue 之类的,jquery 还是 1.12.4,sementic ui 似乎是某个 beta 版本。当初选 vue 是综合各种因素考虑的结果,今年整出来要用 composition api 替换掉老 api 的幺蛾子的时候,我也是忐忑了好一阵子的。
: 选 vue 主要是有以下几个因素:
: 首先,就算是 single file component,html/css/js 也依然是分开的写的。这样就少了一个阻力,不然第一眼没看懂 jsx,就很可能因为认为需要学一套新语法而遭到抵制。
: ...................
--
FROM 14.145.21.*
Vue在国内用户多自然有他的道理。
从n年前不少前端会jQuery而不能写纯js来看,前端er的前端基础的还是比较低的。
Vue组织结构简单,相对入门也更是简单。html template + 比较简单的js模块划分,
就可以工作了,n多Vueer更是官方例子的基础上那么一直继续着。
React相对来说各种概念、思想以及周边确实特别多,并且用法极其灵活,新手一般很
难驾驭。就连最近面试还不少问我effect怎么代替class中的生命周期...
目前国内是大长React比例稍多一些,小作坊基本都Vue,总体来说Vue用户多。
【 在 keygen (失落灵魂之囚) 的大作中提到: 】
: 感谢分享
--
FROM 123.127.43.*
太窄了吧,就一门超高层语言
【 在 chaobill 的大作中提到: 】
: 佩服,我只会用 PHP
: 人到中年,对技术失去兴趣确实是很难受的事。
: 所以啊,带小弟要趁早,这样就可以技术管理双线选择
--
FROM 223.104.42.*
驱动的话,c语言实现功能接口就行了,难是因为不懂原理,编程环境没那么友好
【 在 hgoldfish 的大作中提到: 】
: 厉害!!
: 会 windows 驱动开发的人现在不多了吧。
:
--
修改:god4 FROM 223.104.42.*
FROM 223.104.42.*
纠正一点,vue的composition api一点都不fp呀,还是基于mutable变量的。我觉得react的不可变fp套路简直就是,唉唉,头疼
【 在 eGust (十年) 的大作中提到: 】
: 标 题: Re: 4个月了,没找到工作,大龄了确实惨,学习C++都难投入
: 发信站: 水木社区 (Wed Dec 16 05:49:11 2020), 站内 [累计积分奖励: 0/100]
:
: 为啥没变化就是走进死胡同了?
:
: 另外这几年变化也很明显,首先是 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 于 Dec 16 06:12:52 2020 修改本文·[FROM: 101.98.83.*]
: ※ 来源:·水木社区 newsmth.net·[FROM: 101.98.83.*]
--
修改:eGust FROM 101.98.83.*
FROM 223.72.57.*
推荐你看看 blitz.js 这个新生框架,基于 next.js 但是搞了点魔法,实现了无 http api 调用,直接用函数一样样的调用来沟通前后端,后端用了具有强 typescript 类型支持的 prisma 作为数据库统一接口。
我觉得这个思路是革命性的,如果有人 port 一个 blitz 到 vue 下,我现在自己能做主的开发就义无反顾 all in blitz。听听你的意见?
如果你扫介绍的过程中对任何地方不熟悉(比如我估计 prisma 没流行到人尽皆知的地步),随时私信我交流。我是认真的想听听你对此的看法 //bow
【 在 eGust (十年) 的大作中提到: 】
: 我在本版吹过几样关于前端的东西,比如 react,比如 typescript
: 实际也跟我预言的一样,react 革了 gui 开发的命,现在 flutter、swift ui、blazor 都是在用不同的语言实现 react,几家大公司都用实际行动认证了 react 好
: 当年 ts 连 github 前10都没进的时候,我也说过,js 发展的速度是别的语言赶不上的,用不了几年 go 就连小弟 ts 都打不过了,这不今年都排第4了
: ...................
--
FROM 223.72.57.*
嗯,说的很对。比如说,最近接触了一些小孩,在b站上看视频学vue,写得有模有样,但是压根不会js。。。。vue 可以看成一门简单的新语言,而react就是js,而且还是js里面比较高级的部分。很难想象市面上会出现大量不懂js而靠看视频学react的程序员
【 在 shaolin (我的大小宝贝儿...) 的大作中提到: 】
: Vue在国内用户多自然有他的道理。
: 从n年前不少前端会jQuery而不能写纯js来看,前端er的前端基础的还是比较低的。
: Vue组织结构简单,相对入门也更是简单。html template + 比较简单的js模块划分,
: ...................
--
FROM 223.72.57.*
我来说说为啥革命性:
全栈开发我觉得目前最麻烦的痛点是前后端的typing怎么连起来。前端用ts,后端也用ts(node)或者任何有类型标注的语言(python现在都有类型标注了,也不难用),各自的类型安全是可以很容易地保证的。
但是前端后端之间传递数据,要通过一个本质上无类型信息的http协议,到这里就把信息全丢了。接收端只能自己从头为这个api的返回值再写一遍类型,还要通过类似jsonschema之类的东西耗费性能来检查一遍类型合法性,然后api如果变了,还得手动修改类型。。麻烦的要死
类似的问题也发生在后端和数据库之间,就是后端怎么自动根据发出的sql、mongo等命令,来自动推断返回值的类型,尤其复杂嵌套join查询(甚至想象一个 faura 这样的graphql数据库),其返回值类型也是非常复杂的,自己逐一构建的话麻烦的要死。
后端和数据库之间这个问题,目前已经有较为成熟的方案,比如各种orm,把数据表映射成class,或者更极端地, prisma 这样的工具,把数据库包装成一个自动支持typescript的通用数据接口。
前后端的问题呢,之前只有借助graphql来做类型沟通。后端构造graphql api,前端根据自己发出的 graphql query/mutation 的结构,利用一些工具链比如apollo等,自动生成对应每一个query/mutation的tyescript类型。
过去一年多我一直在实践graphql的这一套解决方案。但是说实话太重了,graphql这个东西很难在团队项目中轻松推广,因为要动的东西太多了,概念太重了。
blitzjs用另一个思路解决了这个问题,相当于把http api调用,直接先写成一个“合法”的前端函数调用,“欺骗”了ide,ide认为这都是前端代码,所以参数和返回值的类型都是自然而然对接好了的。然后在构建期或者dev server环节,做一点hack,把这些函数改写为http api调用,把函数体里的东西放到后端node里面去。
这样就特别轻量级了。甚至对于一些初级前端,甚至都不需要了解http了,直接告诉他,写在这个目录下的函数就是“服务端运行的函数”,就完了。全栈开发就非常类似本机 gui 开发的那种简单的概念了。
bitzjs.com 有不错的文档。他继承了prisma和nextjs的几乎所有功能,然后用这个http api hack给连起来。我觉得太顺滑了。
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 推荐你看看 blitz.js 这个新生框架,基于 next.js 但是搞了点魔法,实现了无 http api 调用,直接用函数一样样的调用来沟通前后端,后端用了具有强 typescript 类型支持的 prisma 作为数据库统一接口。
: 我觉得这个思路是革命性的,如果有人 port 一个 blitz 到 vue 下,我现在自己能做主的开发就义无反顾 all in blitz。听听你的意见?
: 如果你扫介绍的过程中对任何地方不熟悉(比如我估计 prisma 没流行到人尽皆知的地步),随时私信我交流。我是认真的想听听你对此的看法 //bow
: ...................
--
FROM 223.72.57.*
关于这个问题我也写了一个知乎回答,yyx还点赞了,你也可以看看 @eGust
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我来说说为啥革命性:
: 全栈开发我觉得目前最麻烦的痛点是前后端的typing怎么连起来。前端用ts,后端也用ts(node)或者任何有类型标注的语言(python现在都有类型标注了,也不难用),各自的类型安全是可以很容易地保证的。
: 但是前端后端之间传递数据,要通过一个本质上无类型信息的http协议,到这里就把信息全丢了。接收端只能自己从头为这个api的返回值再写一遍类型,还要通过类似jsonschema之类的东西耗费性能来检查一遍类型合法性,然后api如果变了,还得手动修改类型。。麻烦的要死
: ...................
--
FROM 223.72.57.*
你说的不就是 RPC 吗?我十几年前搞 DOJO 的时候就用 JSON-RPC
我当时自己写了一下 RPC 框架,把 JAVA 端的 interface 暴露给 js. 服务端出错了,前端还能抛出异常。
当时因为缺少 Proxy,前端需要先读方法列表。现在有 Proxy 完美。
// java part
interface UserService { void create(name); }
rpc.register<UserService>("users", userServiceImpl);
// js part
rpc = new Rpc("/rpc/");
rpc.users.create("fish").done(...).fail();
现在有了协程,不需要写 done/fail 就更方便了。
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我来说说为啥革命性:
: 全栈开发我觉得目前最麻烦的痛点是前后端的typing怎么连起来。前端用ts,后端也用ts(node)或者任何有类型标注的语言(python现在都有类型标注了,也不难用),各自的类型安全是可以很容易地保证的。
: 但是前端后端之间传递数据,要通过一个本质上无类型信息的http协议,到这里就把信息全丢了。接收端只能自己从头为这个api的返回值再写一遍类型,还要通过类似jsonschema之类的东西耗费性能来检查一遍类型合法性,然后api如果变了,还得手动修改类型。。麻烦的要死
: ...................
--
修改:hgoldfish FROM 60.188.58.*
FROM 60.188.58.*