browserify与webpack

html和小程序的区别

第一条、运行环境的不同

传统的HTML5的运行环境是浏览器，包括webview，而微信小程序的运行环境并非完整的浏览器。

第二条、开发成本的不同

抛去开发工具（vscode、sublimtext、Atom等）不谈，大到前端框架（Angular、react、vue、backbone等）、模块管理工具（Webpack 、Browserify 等）、任务管理工具（Grunt、Gulp等），小到UI库选择、接口调用工具（ajax、Fetch Api等）、浏览器兼容性等都要我们一一考略，再不济用jqery插件写H5，也要在开发过程中去寻找合适的jquery插件来配合项目。

第三条、获取系统级权限的不同

微信小程序相对于HTML5 web应用能获得更多的系统权限，比如网络通信状态、数据缓存能力等，这些系统级权限都可以和微信小程序无缝衔接，也就是官方宣称的拥有Native App的流畅性能，而这一点恰巧是HTML5 web应用经常被诟病的地方，这也是HTML5的大多应用场景被定位在业务逻辑简单、功能单一的原因。

第四条、应用在生产环境的运行流畅度

最容易区分小程序与H5的一点， 打开H5，实际上是打开一个网页，而网页需要在浏览器中渲染，面对复杂的业务逻辑或者丰富的页面交互时页面会卡顿。

而微信小程序，直接在微信上运行，省去了通过浏览器渲染的步骤，因此，在微信中使用小程序，才会比H5流畅很多。除了首次打开需要几秒的加载时间外，小程序各个页面的切换、跳转等体验已经媲美原生App，非常顺畅。

什么是NPM，为什么要用NPM来管理包

会产生冗余问题

前端与后端使用同一套包管理软件可以减少公共部分的耦合，但是会导致不必要的冗余。

比如一个bootstrap包，是不可能被后端使用的。但是如果统一使用npm管理，每次npm install都会安装bootstrap包，而后端一辈子都用不倒，完全是浪费带宽、存储空间、时间。并且你在运行后端前，每次都安装个bootstrap，你不觉得恶心吗？

运行环境完全不同

前端与后端的运行环境是完全不同的，前端运行于浏览器内（即主要是DOM与BOM环境，相对受限），后端则运行于OS内（有无限的API与可能性）。所以这两种开发环境是完全不同的。不同的开发环境使用同一个包管理文件显然是不合时宜的，也不符合模块化的理念。

开发人员也可能不同

前端与后端通常是不同的开发团队，因些前端关注的是HTML，CSS，DOM，BOM， js的UI库与动作库。而后端关注的是性能，安全，效率，数据，缓存，用户管理。他们可能都会用到gulp/grunt，而后端通常不会用到webpack，wiredep，bootstrap, jQuery这类纯前端的包。所以强行将他们捆绑在一起是没有必要的。

同构包可以分开打包

由于isomorphic js的流行，同构包也会越来越多。但是其实你会发现，不管如何同构，前后端的运行环境还是不同的。所以同构包的调用环境还是不一样的。前端的包通常需要通过browserify，webpack或者gulp等工具发布成前端可用的包。跟npm包直接通过package.json决定从什么地方接入是不同的。即使npm可以为前端包提供字段供前端接入，也会显得非常混乱。