今天看了一篇不错的文章,和我之前想的一些疑问不谋而合。记录一下:)

链接: 英文原文 ; 中文翻译

文中提到的三个核心问题是实实在在的。

  • 对插件作者的依赖
  • 令人沮丧的调试
  • 脱节的文档

跟我之前的痛点差不多的是,之前的几个项目在使用gulp时担心gulp的插件更新不够及时,或者一些新的npm工具gulp的实现不够及时会不会产生新坑,到时候是不是还需要自己来填坑?一些 gulp 和 grunt之类的前端工具的问题确确实实是需要时间的维度才能发现问题的存在的。另外感慨前端发展确实日新月异,ES6的模块化标准出台,requirejs和seajs就完成历史任务,现在轮到了grunt和gulp了吗?

实际上现在想来很多问题不能仅仅局限于思考,思考结束还要更深入的寻找解决的方案。

该文章提出了用 npm 自身的方式来解决(npm scripts),不但可以解决出现的各种痛点 还可以统一管理。甚至还可以利用系统内存在的任何脚本来处理任务。

前端虽然发展看似变化快,实际上仔细想想其实只是实现了其他服务端语言早有的工程化思维,把自己只从展示界面,制作交互的层面推到一个工程化的高度。

grunt 实际上是解决了有没有的问题 gulp把文件处理方式优化到了内存级别,而最终沉淀下来的还是系统级别的 npm scripts。

从包的数量来看直接使用npm 一方面可以解决更新问题,另一方面资源也是另外两个不可比拟的。

包数量对比图

看完之后就迫不及待的来尝试一下改变一些思路和工作方式。毕竟寻找更合理的方式.

以下是package.json当中的scripts任务。

"scripts": {
  "start": "npm run build-js && npm run build-css && serve .",
  "watch": "npm run watch-js & npm run watch-css & serve .",

  "build-css": "rework-npm index.css | cleancss -o build/build.css",
  "build-js": "browserify --extension=.jsx --extension=.js index.js | uglifyjs > build/build.js",

  "watch-js": "watchify --extension=.jsx --extension=.js index.js -o build/build.js --debug --verbose",
  "watch-css": "nodemon -e css --ignore build/build.css --exec 'rework-npm index.css -o build/build.css'"
}

那么问题来了 :)

当scripts变的越来越复杂的时候。。。。。。

你就可以利用任何服务端存在的脚本 比如 bash perl node python,只需要脚本上加入 #! 再执行chmod +x

#!/bin/bash
(cd site/main; browserify browser/main.js | uglifyjs -mc > static/bundle.js)
(cd site/xyz; browserify browser.js > static/bundle.js)
"build-js": "bin/build.sh"

Yuan Liang

资深程序渣、秧歌队贝斯手、摄影百拍王、意淫旅行家、正经的令人发指!

http://yuanliang.io
—Read This Next—

ES6设计模式(三)


ES6设计模式 个人学习笔记 没啥说明转折,有时间补充一下 结构型设计模式 外观模式 用户简化底层代码方式,或者兼容性。 ES5 // 获取事件对象 var getEvent = function(event) { return event || window.eve
—You Might Enjoy—

2017我的时间管理


1.要有意识的对时间进行管理 只有当真正意识到自己是如何支配时间的,才能有效的管理时间。记录自己一个星期内的时间日志,观察一下这个星期内的时间的支出情况。看看哪些是可以重新分配的 2.要设定目标 没有目标就像大海漫无目的航行的船,永远到不了想到的地方。要列举出所有自己想要的目标。