搜下 webpack 的 resolve 配置

xp 还 ie678

dart 好在哪？ js 烂在哪？ js 圈都往 functional programming 上走了，是不是在浏览器上能直接跑 haskell 会更酷？

有个毛关系，问这种问题简直莫名其妙。 high chart 很流行， jquery 是不是因为它走向边缘了？ react 很流行， high chart 是不是走向边缘了？

晚饭？加班？

分开下是平行下载的，也容易处理缓存，但是每个请求都要耗时间与服务器建连接。单独下只有一个请求，消耗在建连接的时间上就少。
具体怎样你得测试才行。

vue.js 71k, jquery.js 83k, materialize.js 135k, semantic.js 269k
materilize.css 112k, semantic.css 537k

用上了吗？没有。

貌似就是个 maybe monad 。真羡慕自带这种东西的语言。

活差多了好吧。除了个正则一样，其他都不一样。

浏览器的后退就是单纯的回到历史纪录的前一个。 app 的后退通常都相当于很多网站上头的面包屑导航，跳转到的是当前页面的上一级。这两种导航模式都是必要的，不是孰优孰劣的关系。
回到楼主问题。浏览器不可能知道某个网站的结构是怎样的，怎么跳转到上一级，只有开发者知道。除非开发者开发了面包屑导航（回到上一级）的功能，否则这东西不可能实现。
总而言之，浏览器的后退肯定是到前一页的，页面里头的按钮有可能是回到上一级的。如果页面里头有导航按钮，楼主优先点那个。

几个技术概念：

一. 前端模板：前端 js 取过来的数据，通过模板语言生成 html 。不用自己在那拼字符串了。

二. mvvm 数据绑定：同一个页面里头的不同 view 显示的是同一 model ，而且这些 view 都能操作这个 model ，如何保证 view 的一致性，如何简化编程难度？ mvvm 的框架都会提供绑定的概念。不同的 view 可以都绑定在某个 model 上，当这个 model 更新时，所有绑定的 view 都会更新。作为开发者，你关注的就只是用户操作时如何更新这个 model ，而不是具体如何更新 view 了。

三. virtual DOM ：上面说的 mvvm 架构里头，如果 model 是一个数组， view 是一个列表。数组中的某一项变化时，整个列表都会变化，显然这里头有性能问题。 virtual DOM 通过提供一层 html 的代理，尝试帮你解决这个问题。作为开发者，你做的仍然是绑定 model 到 view 里，当 model 更新时， view 自动更新，只是此时你绑定的是 virtual DOM ，而不是真正的 html 。 virtual DOM 会计算出真正需要更新的 html ，再去更新它们。

四. 组件化：组件化追求的是自定义标签，往 html 上头加个 class 就能实现某个功能，这种 declarative 的 api 。有很多种方式能实现这样的 api 。

五. first class 组件: 把组件当作 first class ，能用函数返回，能传给函数当参数，能通过各种方式组合，这是更高一个层面的组件化了。

前三项是扩展的关系。支持 virtual DOM 肯定支持数据绑定，肯定能把 js 取来的数据渲染成 html 。每扩展一次，肯定会加一层新的抽象，复杂程度很可能会提高。

后两项之间也是扩展关系。跟前三个一样，扩展意味着多一层抽象。

楼主还是仔细考虑考虑你们到底要干啥再选择框架吧。别只是渲染个数据，结果却搞成了各种全家桶了。

后端习惯写接口给你 ajax 调，还是喜欢自己套页面？前者的话，光用个 jquery 肯定不行了。
前端是操作复杂还是一般就显示个数据？操作复杂的就得用个 mvc 的框架。
别跟风 react ， angular 什么的。哪个能满足需要，不用花时间先学上个一个月，就用哪个。

你所说的简单网站里有 ajax 吗？ ajax 取到的数据，塞到模板里头，这是后端的事还是前端的事？前端负责 ajax 的话，这是不是就前后端分离了？把调接口，塞模板这一块放 node 那层，跟页面里头 ajax 取数据区别大吗，你觉得这就能算后端了吗？

拆参数，拆对象，默认值处理，这几个新特性，实在是人见人喜欢，其他的就无所谓了。 node 基本 es6 都支持了吧，又不要编译，不用干嘛呢。

楼主你讲的是现在后端开发避免不了，而且暂时解决不了的问题。
前端（ web, 手机客户端）的 view 长成某个样子，要你造个 api 提供满足这个 view 的数据。 view 改了，你是改之前的 api ，还是造个新的 api ？之前的 api 是留着，还是删掉不要呢？ web 和手机客户端上的界面差不多，但是需求稍微有点不一样，你是造俩 api ，还是造一个同时满足它们的需求呢？
最后的结果就是一团乱。

https://www.infoq.com/articles/no-more-mvc-frameworks
这文章的前几段就描述了这种情况。

“返回 12 个月的统计信息”，这么个名字的 api 就应该返回 12 个月的统计信息。
“返回有数据月份的统计信息”，这么个名字的 api 就应该只返回有数据的。
不是职责问题，是人家要什么样的 api ，你又能给什么 api 的问题。

jQuery -> 前端模板 -> MVC -> react
你直接从头跳到尾，步子迈大了，当然不知道怎么回事。

http://jsbin.com/vasolucame/edit?html,css,js,output

其实是挺有意思的问题。

各种云服务的文档，毕竟是拿来卖钱的，不会含糊。 jquery 的文档，多年积累，简单易学。