- 主题:4个月了,没找到工作,大龄了确实惨,学习C++都难投入
纠正一点,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不稀奇,自动推断类型的rpc我觉得比较稀奇。
你想啊,前端本来只有js,js本身没类型,所以根本不存在这个需求。近年来ts崛起,前端也有类型了,后端很多人用node做胶水层了,前后端一个语言,中间隔了一个http,rpc两头的类型连不起来。这就是我说的问题
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你说的不就是 RPC 吗?我十几年前搞 DOJO 的时候就用 JSON-RPC
: 我当时自己写了一下 RPC 框架,把 JAVA 端的 interface 暴露给 js. 服务端出错了,前端还能抛出异常。
: 当时因为缺少 Proxy,前端需要先读方法列表。现在有 Proxy 就完美了。
: ...................
--
修改:beep FROM 223.72.57.*
FROM 223.72.57.*
我开头就说痛点是前后端typing怎么连起来。。。
你说的这种不支持自动typing的rpc,js里也有一大把,什么feathers之类的,我也用过两三年,而且很深度地参与了feathers项目的维护。后来ts兴起以后,就义无反顾走ts+graphql路线了。我是无类型不舒服斯基,最近写python都全加typing,求个心里安稳
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这倒是。。我一般用 es6,没注意到你说的是 ts.
--
FROM 223.72.57.*
这里面有个大背景,就是我感觉前后端分离的分工越来越不流行了。我参与的几个公司项目,都感觉是同一个小组负责同一个业务的前后端开发,也就是常说的全栈,效率是最高的。同一个业务逻辑的前后端代码经常应该是同一个人写的,从数据表设计,到node,到vue/react,一个人搞定。
事实上培训这样的全栈小孩不难,现在小孩也都非常积极主动想要学全栈,一个vue程序员不懂点mysql、mongo、nodejs,都不好意思出来混。
当然,如果后端业务复杂了,比如要上集群、复杂的消息队列、和已有的非nodejs的业务模块对接,等等,肯定还需要其他语言的人。但即便如此,nodejs胶水层也可以做很多的工作,这就是这两三年很火的“bff(backend for frontend?)概念。
因为这样的js前后端全栈越来越普遍,所以前后端ts类型一致性的问题就越来越急迫
【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: 我开头就说痛点是前后端typing怎么连起来。。。
: 你说的这种不支持自动typing的rpc,js里也有一大把,什么feathers之类的,我也用过两三年,而且很深度地参与了feathers项目的维护。后来ts兴起以后,就义无反顾走ts+graphql路线了。我是无类型不舒服斯基,最近写python都全加typing,求个心里安稳
--
FROM 223.72.57.*
【 在 eGust (十年) 的大作中提到: 】
: 标 题: Re: 4个月了,没找到工作,大龄了确实惨,学习C++都难投入
: 发信站: 水木社区 (Thu Dec 31 10:14:00 2020), 站内
:
: 大概看了一下,就是比 next.js 走的更远了一些,把数据层也加到 react 控件里了呗?
:
: 只不过传统 mvc 框架是用后端渲染 html/css/js,这个是把后端逻辑揉在前端代码里。我觉得两者本质上是没有差别的,不管前端后端哪个胖哪个瘦,都是尽量在一端来实现全部逻辑,只不过多了 ts 的类型自动推导而已。
~~~~~~~~~~~~~~~~~~~~~~对,就是在nextjs的基础上加上了后端的prisma数据层,并且实现了ts前后端自动类型推导。prisma的schema就是你所谓的single source of truth,所有和数据相关的类型都是自动从这里面推出来的
:
: 这其实又回到老的问题上,为什么传统的 mvc 框架被 web/API 分离的方式取代。主要一个原因就是 mobile app 的兴起,实现一套 api 就可以接不同的前端。不同的前端可能对数据有不同的需求,graphql 可以减少后端的开发工作量,避免没必要的数据库请求。
:
: 我觉得你的需求本质上还是代码重用的问题,只不过刚好前后端都是 ts,所以事情简单了许多。除了能重用类型以外,传统 mvc 框架存在的问题,其实一个都避免不了。
:
: 类型这个东西也挺没办法的,不同的数据库有自己的类型系统,每个语言也有自己的类型系统,gql 又有自己的 dsl 类型系统。所以如果是一个 ts 前端,gql 做 api,另外一个语言做后端,还有个数据库的系统,后端框架可能还有一套 dsl 做 db migration,所以加在一起大概得有5种以上的类型描述,基本上是在做同一件事情。我个人的倾向是数据和逻辑分离,而类型也是作为数据的一种,用 json/xml/yaml 或者 dsl 表示都没太大问题,然后作为 single source of truth 去生成其它的东西。然而这件事情如果做不好的话,那就又加入了一套类型描述的系统,于是又多了一个问题。
:
: 【 在 beep (菜M.喵星耗子) 的大作中提到: 】
: : 我来说说为啥革命性:
: : 全栈开发我觉得目前最麻烦的痛点是前后端的typing怎么连起来。前端用ts,后端也用ts(node)或者任何有类型标注的语言(python现在都有类型标注了,也不难用),各自的类型安全是可以很容易地保证的。
: : 但是前端后端之间传递数据,要通过一个本质上无类型信息的http协议,到这里就把信息全丢了。接收端只能自己从头为这个api的返回值再写一遍类型,还要通过类似jsonschema之类的东西耗费性能来检查一遍类型合法性,然后api如果变了,还得手动修改类型。。麻烦的要死
: : ...................
:
: --
:
: ※ 修改:·eGust 于 Dec 31 10:26:42 2020 修改本文·[FROM: 115.188.162.*]
: ※ 来源:·水木社区 newsmth.net·[FROM: 115.188.162.*]
--
修改:eGust FROM 115.188.162.*
FROM 223.72.57.*