虽然我本来是很排斥这种试用了某个技术然后就写一篇博客的行为，但无奈这次试用weex的过程中确实遇到了挺多问题，所以在此记录下来，或许可以帮到一些人。weex的文档其实已经做的挺不错了，所以很多内容都可以参考文档（可能是文档频繁的完善更新，地址都换了几次了）。

1.什么是Weex

很多人都应该知道了weex是个什么东西，但语文老师教导我们写好一篇作文最基本的要有一个好的结构，所以还是废话几句介绍一下，而且还可以凑一下作文字数。

从官网我们可以知道：

weex是一套构建高性能、可扩展的原生应用跨平台开发方案。与 Web App、HTML5 App 或 hybrid App 不同，您可以使用 Weex 构建一个真正的原生应用。更贴心的是你的代码只需使用 HTML、CSS、JavaScript 可以构建原生应用，上手非常简单。但实际上，应用的底层是 Objective-C 或 Java， 同时，Weex 提供很多 native 组件或模块供开发人员使用。

它的原理文档也有介绍，简单来说就是WeexSDK使用一个javascript引擎执行你的前端代码（JSBundle），然后再通过JSBridge与native端进行交互，进行native的渲染等操作。

| 原文：Python for JavaScript Developers

特别感谢Brett Langdon的认真检查

最近我开始在纽约一家创业公司工作，公司叫Underdog.io，在那我发现他们后端主要是用Python写的，而这是我之前很少接触到的语言。

我是被雇来写JavaScript喝React的，这些在我的团队中只占了很少一部分，这意味着我经常得为了找到一些特性而钻进各个代码库中。所以我必须很快地了解Python。

不幸的是，我之前想找一些给写过代码的人看的Python教程找的好艰难。我已经知道怎么写代码了而且也熟悉其他语言，我只是需要学习Python这一特定语言的语法和规范。

这是我写这篇blog的原因。给Javascript开发者一个指南，可以快速地上手Python，而不用去学习声明一个变量的意思和方法是什么。

这篇log假设你在用Python 3.0.1，所以其中一些例子可能不能在旧版本的Python上跑。

前端发展至今，开发中基本上都是和后端分离的，与后端无关的功能我们可以自己开发，但涉及到与后端数据交互相关的功能，没有了后端的配合，我们就需要自己动手了。这里就主要介绍几种我工作中使用到的方法，用来模拟后端返回的数据。

1.代理工具

使用一些代理工具，我们可以将浏览器的请求拦截并返回其他内容。通常的做法是将请求映射到本地文件，返回请求时返回文件内容，例如配置 test.com/ 映射到本地目录 /test/ ，实现接口 test.com/req 返回文件 /test/req 的内容。各系统都有相应的工具：

• fiddler＋willow，for windows
• charles/wireshark，for mac/linux

变懒了，发现原来已经半年没写过一篇东西了，这半年，又换了一个工作的地方，现在觉得，人不能太浮躁。当然，也还是要有跳出舒适区的决心。

为什么使用vue

虽然换了工作，但是工作内容还是没有变化多少，目前为止接触的还是一些to B的管理系统项目，作为一个前端，没能负责一个to C的产品，还是有点小伤感的。好的是没有旧项目要维护，一切从零开始，而且不用兼容低版本浏览器。所以项目在技术选型上是很自由的。现在基本上是使用了webpack＋vue的技术方案。之所以选择vue有以下几个原因：

• vue结合了Angular和React的优点，可以方便的使用数据双向绑定，又可以方便的实现组件化
• 很重要的一点，公司有使用vue的项目经验
• vue上手比较快，基本上看一天教程就可以上手干活了（这点对我们来说非常重要。。）
• 社区现在也很活跃，作者尤大貌似要全职做vue开发了

因为ES6是后面的趋势，所以就直接上了vue推荐的方案：使用webpack+ES6+vue-loader。

| 原文：Why I Left Gulp and Grunt for npm Scripts

我知道你们在想什么?什么鬼?!Gulp不是刚刚干掉了Grunt吗?为什么我们不能就这样维持一会呢?我知道,但是…

我发现Gulp和Grunt是没有必要的抽象,npm script更强大,并且通常更好用

我们先从一个例子开始…

好久没有写点东西了,最近天冷也懒了点.但不能就这么荒废了,安利一下前阵子写的一个chrome小插件

介绍

使用evernote剪藏的时候发现并不是很好用,每次保存都会新建一个文章进行保存,而我的使用场景是,看到一段想保存的文字,选择保存,然后保存到同一个地方.因为剪藏不能满足,所以写了一个小插件.插件可对文本进行高亮,并且高亮的文本会保存到插件的弹出窗口中,使用者可进行编辑.效果可以看我github介绍:点击跳转

很久很久以前，就总是听人们在讨论着angular2（以下简称ng2，angualr1.x简称ng1），而今其beta版本已发布了好几个月，最近刚好有时间于是拿来试玩一下。

一.初代和二代的简单对比

据说ng2是不兼容ng1的，有这么几点很大的不同：

• 使用TypeScript编写
• 没有Controllers
• 没有双向数据绑定，不过ng2提供了强大的forms module提供类似功能
• 组件化
• 新的Router
• 模块化
• 没有$scope
• 使用Tempate的错误提示

所以剩下没变的，好像也就filters了。那为什么做这么大改变呢，ng2团队给出了解释，下面简单列一下：

• 性能限制：双向绑定和模板等性能问题
• 前端的快速发展：ES6标准的确定，组件化模块化的发展
• 移动端的需求：移动端要求的高性能ng1满足不了
• 易用性：ng1太复杂学习曲线太陡峭

我对性能方面的考虑倒没那么多，而如果用在手机端可能也会先考虑reactjs。但是使用过ng2后，它的模块化组件化着实让我眼前一亮！和ng1那种糟糕的写法比起来简直就是：完美～！

在html5流行泛滥的今天,作为一个web前端,你应该已经写过了无数的动画效果,你或许也在你的css3动画中加上了translate3d,使得动画流畅,但究竟这个为什么能使动画流畅呢,还有其他的东西能影响到动画的性能,或者说网页渲染的性能呢?

下面的内容将介绍页面渲染过程对性能是如何影响性能的:
内容基于 WebKit，更准确的说，是 WebKit 的 Chromium 分支,不过其他浏览器大体一致

一.一个html文档,从解析到屏幕

一个html文档从解析到渲染到屏幕,大致上有以下几步:

1. html文档生成DOM树
2. CSS代码转化成CSSOM
3. DOM+CSSOM生成渲染树
4. 根据渲染树上节点的位置大小等信息进行布局(layout)
5. 将布局绘制到bitmap上
6. bitmap传输至GPU然后绘制到屏幕

      终于找到时间（不偷懒）来填三个星期前挖的坑了，虽然不是什么干货，但是通过写写文章，也可以增强自己的语言组织能力，这点对程序员后面的发展也是至关重要的。切入正题，这次记录以下我用cors跨域时失败的问题（不涉及cookie跨域）。

      前两周和一个后端在集成接口，因为前端代码在我本地，后端接口在他机子上，所以让他设置cors让我可以跨域访问。然而，结果却老是得到一个404请求，查看请求信息发现是发了一个options请求，而本来的请求都没有发出去。我当时就纳闷了，自己之前用nodejs试过后端Access-Control-Allow-Origin就行啦，为何这次就不行。然后试着用原生的ajax请求和jquery请求都可以哇。

      google了些许时间后才发现问题，我前端使用angualr写的，其他人的认证模块在请求里插入了自定义的头域，而这是cors请求出现options预请求的其中一种情况，当出现以下一种情况就会发出预请求（其他情况和正常请求一样）：

• 请求以 GET, HEAD 或者 POST 以外的方法发起请求。或者，使用 POST，但请求数据为 application/x-www-form-urlencoded, multipart/form-data 或者 text/plain 以外的数据类型。比如说，用 POST 发送数据类型为 application/xml 或者 text/xml 的 XML 数据的请求。
• 使用自定义请求头（比如添加诸如 X-PINGOTHER）。

提示：从Gecko 2.0开始，text/plain, application/x-www-form-urlencoded 和 multipart/form-data 类型的数据都可以直接用于跨站请求，而不需要先发起“预请求”了。之前，只有 text/plain 可以不用先发起“预请求”，进行跨站请求。

    又有东西可以写的,为何又是样式相关的,其实我很想写点其他的啊啊啊.
    最近做公司招聘网站被设计给虐惨了,一方面是设计太年轻太严谨了,一方面自己做的也不好,好一些图标的垂直对齐都用像素调整,导致被设计师贼亮的眼睛发现好多个一两个像素的差距,最终导致我需要改动好多.之前以为vertical-align效果不同浏览器会有差异所以没怎么用,但现在我已追悔莫及~~让我先从inline-block讲起吧

inline-block

    一些line box什么的就不说了,直接切入问题.举一个栗子可能很多人都遇到类似情况:一个div大小为20px,里面两个inline-block元素,一个不含文本,宽度高度均20px,另一个line-height为20px,包含文本,然后我们会发现div容器是不止20px高的看例1.
    这是什么原因呢,其实是inline-block元素的垂直对齐引起的.inline box垂直方向上默认是与其baseline对齐的，而它的baseline又是和包裹它的line box的baseline对齐的。而当一个inline box里面没有包含文本的时候，没有了baseline，没有基准可以对齐,所以定了一个妥协的规则，就是把该box的底部对准包裹它的line box的baseline。而baseline又是在文本的底线上面的,所以整体会把容器给撑高了.
    那么问题来了,linebox的baseline又是怎么定的呢,很简单,它包裹的带文本的所有inline box,高度最高的那个的baesline就是linebox的baesline,当然这个高度不是指盒子高度,而是指inline box的line-height撑高的高度.这里要注意的是,多行文本的inline box的baseline是以最后一行为基准的看例2.而如果没有包含文本,就是以自身给定的line-height来决定看例3.最后,如果包含文本,本身也设置了line-height,那就哪个高听哪个.