假如我开发了套 web 前端框架，只需浏览器，不需要 nodejs webpack 就能构建大型应用，有没有什么办法把它推广出去？

just show your case.

layui 就是这样的，我感觉我被坑得好惨。

你指的是 vs code remote server ？

LZ 你先说下你开发过什么大型项目吧

可能楼主对大型应用什么误解

我只有一个问题，怎么解决 import from ?

问一下，你浏览器里写代码能有各种 IDE 好用？
或者，完全不需要写代码？

实用建议：写个 Todo List，发个 Medium，找个好爹

你觉得开发者会抛弃 nodejs 和 webpack 强大的社区生态来使用你这个东西吗？

我是一名小学数学教师，我想问，要是我能发明一种全新的数学体系，不用自然数就解题干一百字以上的应用题，会有人用吗？

还有问问真的发明出来的话，小学校长能给我发多少薪水？

你可能对他们是什么有误解。

@zenxds 用自己开发的底层开发了一个制作网页的工具。 https://kirakiray.com/pageCreator/
最近面临着没钱要找工作的问题。。。

@secondwtq 求找爹方法，有爹我就能好好维护了。

@luob 通过模拟模块化方式管理，模块用 Promise 包装，这个 https://github.com/kirakiray/drill.js

@hackyuan 我只是看不爽 webpack，就一个模块管理工具这么复杂；

@Chrisssss 是啊，所以我有点后悔是不是选错了写前端底层的路，是不是几年前就应该跟随大众不要挑战权威。

@fngtz 是啊，做出来了但是没人用，自己倒是用得很爽，但是没钱了要找工作了，所以问问再重新学了流行框架的基础上，能不能因为我干过的傻事加点工资；

@JmmBite 被限制外链回复了，从评论里的 PageCreator 主页里，Q&A 有写两个底层的链接；

@molvqingtai 被限制外链回复了，看看评论里的 PageCreator 算不算大型应用；

@loading 我也被坑过，那对写后台的问我怎么加东西，都没前端模块化管理，人都调崩溃了。

看了一下感觉挺有意思的，不过我不是前端不太懂

@Kilerd 没懂

@JohnChiu 你可以看看我开发出来的 PageCreator，是个应用软件来的。

依赖 nodejs 的 webpack 等工具只是为了解决前端模块化等等一系列问题，你做的工具不依赖这些但也能解决同样的问题也厉害。

@FEDT 其实也是要感谢 nodejs 和 babel 推动社区改进，在能支持 es7 的方案下就能完全实现前端模块化和工程数据化了。

@pikay 用了一下有几个疑问，

1、如何制作自适应？就是全局 vwvh 啊、 @media 啊，字体好像不能自适应，宽高也不能宽%高 px
2、组件管理问题
3、假设我需要一个目录树等之类的组件，我如何引用别人的或者怎么才能自己写？
4、页面怎么和后台数据对接，我好像找不到
5、好像没看到你这里有能写 script 的地方，逻辑处理怎么办？
6、如何能随心所欲使用 angular、vue、react 等这些框架？


说实话 dw 比你这好用 emmmmm

@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 可以和它们三个搭配用；

@wunonglin 我好像搞错问题了，还以为你说 drill 和 xhear 的问题。。。
如果是说 PageCreator 导出的项目的话，目前是做多场景页面的，像小米手机展示页那种，主要是可以将工作量丢个设计师，而且它们也更好调到想要的效果。。。
导出的 pageRunner 主要是依赖 .p_main 这个元素，还有它的依赖 js 文件；用 ng vue react 的 spa 页应该不适用场景展示的需求吧。。。如果非得要在里面展示可能要用 iframe 了。 orz

@pikay
我一直对这种可视化工具不太感冒，一般开发稍微久了点都会不断迭代自己的项目模板，下一次新开项目又熟悉又快。
而学习这个还需要额外的成本，说实话也就是提供给运营人员用用吧。如果你说可以添加模块，那我还不如直接将模块写得更独立一些然后发布到 npm，更加具有通用性。
无论是做复杂的权限管理系统还是 d3, echarts 之类的图表都还差了那么多东西…

@pikay 只是吐个槽，还是很厉害的

https://github.com/cbdyzj/bkb
requirejs + backbone + jquery

"talk is cheap , show me the code/demo"

@Cbdy requirejs 的前置依赖并不能灵活满足需求，所以我才会开发 drill.js ； backbone 和 jquery 做组件封装和数据绑定很繁琐，我才开发了 xhear

@meepo3927 看楼上贴了外链，我回复不能贴外链了；

虽然 webpack 等并没那么好用；但一定程度上解决了开发和运行时的矛盾；开发的时候怎么爽怎么来，各种新特性，各种开发好的包、模块随便用；但运行时需要解决依赖问题、执行效率问题、兼容性问题；所以有这些脚手架来做这些脏活累活，抛弃这些，只依赖浏览器，必然这些活分担到开发和运行时；除非是开发出另一套工具来解决这些问题。问题矛盾始终是存在的

@pikay 我只是给你看一下，说明一下这个东西十年前就有了；而历史选择了 webpack 和 react 这种东西。

@AlphaTr 非常感谢，了解需求了，后续添加工具配套。

@Cbdy 你给的这些东西跟我说的不一样，只是限于当时的发展当时没法做，所以才到 grunt glup 后才 webpack ；现在浏览器已经发展的够好了，有能力抛弃预编译方案；我只是想探讨，假如非预编译方案已经和预编译方案一样了，有没有前途，没有的话我就不补文档了。

@pikay
其实我也不太喜欢前端预编译（我以前发的一个帖子），不过总的来说现在的趋势是前端工程化：js、css、html 都加上了各类预编译。
你可以尝试一下，我举得是一个有益的尝试可能适用于一些场景。我的想法其实是在一些场景下，在浏览器里面跑一个 ts 或者 react 的 runtime （ compiler ）会更好。

@pikay 我看了一下你的 drill.js ，js 的 module 已经进标准了，建议你用标准。requirejs 是因为出来的比较早，那时还没有 esm。
```
export const m1 = {}
const m2 = await import('./m2.js')
```

@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 怎样开发扩展会更方便；

@Cbdy 当前 drill.js 支持还是很好，而且 drill.js 可以扩展 ts 之类的文件的支持，就是写 runtime 我还得恶补好多编译知识，当前经济状况之类的做考量这方案性价比太低了，会优先考虑能填饱肚子的方案；

感觉做的挺不错的，值得多要工资，但楼主的表达有问题。
不应该是“我开发了一套 web 框架，所以多要 XX 工资”，
而应该是“我业余时间自己开发了一个 XX，在这个过程中学会了 XX、YY 技能，有 XX 开发的经验”。

@runze 我简历补上

看了一下 pageCreator，大佬啊

你根本没理解 webpack 做了啥，先想想为什么要 webpack 吧。

即使你把 build 的运行环境弄到浏览器里，你还是绕不过 webpack，除非你自己再再造一个功能完全一样的轮子并维护起完善的生态。

把 build 环境弄到浏览器里，这个事情已经有人做了：
https://codesandbox.io/