还有问问真的开发出来了的话,出去找工作能挑战多少薪资?
1
JmmBite 2019-05-27 19:02:36 +08:00
just show your case.
|
2
loading 2019-05-27 19:09:35 +08:00 via Android
layui 就是这样的,我感觉我被坑得好惨。
|
3
Kilerd 2019-05-27 19:18:03 +08:00
你指的是 vs code remote server ?
|
4
zenxds 2019-05-27 19:19:44 +08:00
LZ 你先说下你开发过什么大型项目吧
|
5
molvqingtai 2019-05-27 19:22:40 +08:00 via Android
可能楼主对大型应用什么误解
|
6
luob 2019-05-27 19:55:09 +08:00
我只有一个问题,怎么解决 import from ?
|
7
GM 2019-05-27 19:58:30 +08:00
问一下,你浏览器里写代码能有各种 IDE 好用?
或者,完全不需要写代码? |
8
secondwtq 2019-05-27 20:08:01 +08:00
实用建议:写个 Todo List,发个 Medium,找个好爹
|
9
Chrisssss 2019-05-27 20:08:39 +08:00
你觉得开发者会抛弃 nodejs 和 webpack 强大的社区生态来使用你这个东西吗?
|
10
fngtz 2019-05-27 20:15:04 +08:00 via iPhone 2
我是一名小学数学教师,我想问,要是我能发明一种全新的数学体系,不用自然数就解题干一百字以上的应用题,会有人用吗?
还有问问真的发明出来的话,小学校长能给我发多少薪水? |
11
hackyuan 2019-05-27 20:28:13 +08:00 via Android
你可能对他们是什么有误解。
|
12
pikay OP |
14
pikay OP @luob 通过模拟模块化方式管理,模块用 Promise 包装,这个 https://github.com/kirakiray/drill.js
|
17
pikay OP @fngtz 是啊,做出来了但是没人用,自己倒是用得很爽,但是没钱了要找工作了,所以问问再重新学了流行框架的基础上,能不能因为我干过的傻事加点工资;
|
19
pikay OP @molvqingtai 😭被限制外链回复了,看看评论里的 PageCreator 算不算大型应用;
|
21
JohnChiu 2019-05-28 00:52:21 +08:00
看了一下感觉挺有意思的,不过我不是前端不太懂
|
24
FEDT 2019-05-28 01:09:04 +08:00 via iPhone
依赖 nodejs 的 webpack 等工具只是为了解决前端模块化等等一系列问题,你做的工具不依赖这些但也能解决同样的问题也厉害。
|
25
pikay OP @FEDT 其实也是要感谢 nodejs 和 babel 推动社区改进,在能支持 es7 的方案下就能完全实现前端模块化和工程数据化了。
|
26
wunonglin 2019-05-28 01:19:47 +08:00
|
27
pikay OP @wunonglin 😭第一次 V2EX 发帖非常感谢这么长和有用的回复;
1.如果你说的是 PageCreator 制作简单多场景页面,让设计师用这个工具做 80%,导出项目后前端开发在补全不能做的元素,例如视频表单或者不能用的单位元素,导出的项目是 MIT 协议的,可以在官网找项目地址,里面有文档教怎样做自定义元素; 2.Xhear 的组件管理可以用 drill.js 的异步包的模式管理,但是我也觉得不太方便;如果以后有人用,会做一个视图工具来清晰管理组件问题;可是目前要恰饭所以没时间做,因为只有我一个人用都很清晰。。。 3. drill.js 就是异步模块化库,使用方法跟模块化方案一样,就是返回的是 Promise,要用 await 来得到; 4.xhear 是元素数据,你可以$.xdata({obj...})生成你的数据,在修正 xdata 对象,通过 sync 双向数据绑定 xhear 的 element,文档没补齐详细还很难说明白给你;大概的意思是传过来的数据本身就带 tag 属性,tag 属性代表了实例类型,可以服务端调整数据传过来,也可以传过来后前端调整; Xhear 是基于 stanz 开发的(可以进我的 github 里面看 stanz 这个项目),你看看 stanz 的 test 说不定能知道怎么做。。。 5.如果是说 PageCreator 导出的 web 页面,直接在 index.html 里面加;如果是说 xhear + drill.js 的模式,看 drill.js 的文档,通过 load 函数载入; 6.我的 xhear 是就是定位他们三个的。。。drilljs 可以和它们三个搭配用; |
28
pikay OP @wunonglin 我好像搞错问题了,还以为你说 drill 和 xhear 的问题。。。
如果是说 PageCreator 导出的项目的话,目前是做多场景页面的,像小米手机展示页那种,主要是可以将工作量丢个设计师,而且它们也更好调到想要的效果。。。 导出的 pageRunner 主要是依赖 .p_main 这个元素,还有它的依赖 js 文件;用 ng vue react 的 spa 页应该不适用场景展示的需求吧。。。如果非得要在里面展示可能要用 iframe 了。 orz |
30
hackyuan 2019-05-28 04:49:59 +08:00 via Android
@pikay
我一直对这种可视化工具不太感冒,一般开发稍微久了点都会不断迭代自己的项目模板,下一次新开项目又熟悉又快。 而学习这个还需要额外的成本,说实话也就是提供给运营人员用用吧。如果你说可以添加模块,那我还不如直接将模块写得更独立一些然后发布到 npm,更加具有通用性。 无论是做复杂的权限管理系统还是 d3, echarts 之类的图表都还差了那么多东西… |
32
Cbdy 2019-05-28 06:49:27 +08:00 via Android
https://github.com/cbdyzj/bkb
requirejs + backbone + jquery |
33
meepo3927 2019-05-28 09:14:35 +08:00
"talk is cheap , show me the code/demo"
|
34
pikay OP @Cbdy requirejs 的前置依赖并不能灵活满足需求,所以我才会开发 drill.js ; backbone 和 jquery 做组件封装和数据绑定很繁琐,我才开发了 xhear
|
36
AlphaTr 2019-05-28 13:03:15 +08:00 via iPhone
虽然 webpack 等并没那么好用;但一定程度上解决了开发和运行时的矛盾;开发的时候怎么爽怎么来,各种新特性,各种开发好的包、模块随便用;但运行时需要解决依赖问题、执行效率问题、兼容性问题;所以有这些脚手架来做这些脏活累活,抛弃这些,只依赖浏览器,必然这些活分担到开发和运行时;除非是开发出另一套工具来解决这些问题。问题矛盾始终是存在的
|
37
Cbdy 2019-05-28 13:44:51 +08:00 via Android
@pikay 我只是给你看一下,说明一下这个东西十年前就有了;而历史选择了 webpack 和 react 这种东西。
|
39
pikay OP @Cbdy 你给的这些东西跟我说的不一样,只是限于当时的发展当时没法做,所以才到 grunt glup 后才 webpack ;现在浏览器已经发展的够好了,有能力抛弃预编译方案;我只是想探讨,假如非预编译方案已经和预编译方案一样了,有没有前途,没有的话我就不补文档了。
|
40
Cbdy 2019-05-28 15:19:59 +08:00
@pikay
其实我也不太喜欢前端预编译(我以前发的一个帖子),不过总的来说现在的趋势是前端工程化:js、css、html 都加上了各类预编译。 你可以尝试一下,我举得是一个有益的尝试——可能适用于一些场景。我的想法其实是在一些场景下,在浏览器里面跑一个 ts 或者 react 的 runtime ( compiler )会更好。 |
41
Cbdy 2019-05-28 15:25:42 +08:00
@pikay 我看了一下你的 drill.js ,js 的 module 已经进标准了,建议你用标准。requirejs 是因为出来的比较早,那时还没有 esm。
``` export const m1 = {} const m2 = await import('./m2.js') ``` |
42
pikay OP @Cbdy 但是有几种需求不能满足,比如 drill.js 的异步模块,如果 'data'模块需要一次 ajax 请求数据,按照 es module 就只能返回一个 Promise 对象,后续逻辑再做一层包裹,才能做这种需求,而且 esm 是同步开发的模式来思考;
drill 的模块还有 task 模块和 init 模块,虽然这两种是非必须但是开发还是很实用的,还有就是 web 前端开发里的 非模块文件(普通 js ), esm 没有把它思考进去; drill.js 就能当成默认文件插入; 还有一种未来一定会出现的一些模块类型,比如 点击按钮音效,按照 drill.js 的扩展开发模式,很容易就能做到如下: let p = await load("xxx.mp3 -defer") btn.on("click",e=>{ p.play() }) 不考虑做 esm 还有开发扩展上的考虑,现在 drill.js 开发扩展支持是很方便的,代码如下: loaders.set("wasm", async (packData) => { let data; try { // 请求数据 data = await fetch(packData.link); } catch (e) { packData.stat = 2; return; } // 转换 arrayBuffer 格式 data = await data.arrayBuffer(); // 转换 wasm 模块 let module = await WebAssembly.compile(data); const instance = new WebAssembly.Instance(module); // 重置 getPack packData.getPack = async () => { return instance.exports; } // 设置完成 packData.stat = 3; }); 使用如下: let xx = await load("xx.wasm") xx(); // 这里直接用 xx 方法 drill.js 目前很容易就能开发扩展,esm 开发扩展会变得很麻烦,可能又要走预编译方案,还有得重写 map 映射,或者我还要在想想 esm 怎样开发扩展会更方便; |
43
pikay OP @Cbdy 当前 drill.js 支持还是很好,而且 drill.js 可以扩展 ts 之类的文件的支持,就是写 runtime 我还得恶补好多编译知识,当前经济状况之类的做考量这方案性价比太低了😭,会优先考虑能填饱肚子的方案;
|
44
runze 2019-05-28 18:43:32 +08:00
感觉做的挺不错的,值得多要工资,但楼主的表达有问题。
不应该是“我开发了一套 web 框架,所以多要 XX 工资”, 而应该是“我业余时间自己开发了一个 XX,在这个过程中学会了 XX、YY 技能,有 XX 开发的经验”。 |
46
molvqingtai 2019-05-28 23:15:23 +08:00
看了一下 pageCreator,大佬啊
|
47
liyuanqiu 2019-06-01 21:44:26 +08:00 via iPhone
你根本没理解 webpack 做了啥,先想想为什么要 webpack 吧。
即使你把 build 的运行环境弄到浏览器里,你还是绕不过 webpack,除非你自己再再造一个功能完全一样的轮子并维护起完善的生态。 把 build 环境弄到浏览器里,这个事情已经有人做了: https://codesandbox.io/ |