#为什么用webpack 如果我们 前端 javascript 能像 node.js 一样 require 去引用一个依赖包,那么前端的世界就不会像现在这么乱 现在为什么乱? 假设: a.js 依赖 b.js b.js 依赖 c.js c.js 依赖 d.js 如果在我们前端去引用这些依赖的时候,往往是这样的: <script src='a.js'></script> <script src='b.js'></script> <script src='c.js'></script> <scri

现在的二维码相当火,借着移动互联网的风口也快飞起来了.现在各种语言的各种开源包,基本都有对应的生成二维码的源码.但是今天我们分享的不是服务器生成二维码,而是前端页面如果用 javascript 来生成一个二维码.这种动态生成二维码的需求越来越多.如果都要依靠服务器端赖生成,第一:面临资源紧缺的状况,如果在大的并发环境,这种cpu密集型计算必定导致一个问题,就是请求排队,那就不用谈了.用户不会一直在傻傻的等你.第二:就算你顺利生成了二维码,还面临一个网络传输带宽的压力,虽然它很小很小,但是当在一个并发压力大的环境下,依然面临带宽被占的问题.这样说来,如果能在客户端生成二维码,貌似是最好的解决方案

随着前端项目越来越复杂,随便引入几个第三方javascript脚本库貌似已经习以为常,但是随着越来越多的包被引入,开发人员维护起来也是一件相当头疼的事,比如第三方库的版本更新,安装,卸载等.twitter推出了一个前端包管理器 bower 帮我们解决了这些头疼的事情.bower 完全借鉴了npm构思和实现原理,所以后面你会看到它的使用几乎和npm是一模一样.当然,bower 是运行在node.js 基础上,所以你的当前环境确保已经安装 node.js .bower 的基础功能是什么?1.注册模块每个包需要确定一个唯一的 ID 使得搜索和下载的时候能够正确匹配2.文件存储把文件存储在一个有效的网