最近前端技术栈的一些想法吧

React VS Vue

之前写过一个文章说一些React应注意的一些基础问题。现在你应该知道,我已经转Vue了。

我非常喜欢Vue的组件的编写方式。用*.vue的组件编写实在是符合正常人的思考方式。相比之下React的写法就不够人性化了。

React 写法:

import React from 'react'

class Foo extends React.Component {
    render() {
        return (
            <h1>Hello world</h1>
        )
    }
}
export default Foo

Vue 写法:

<template>
    <h1 v-text="msg"></h1>
</template>
<script>
export default {
    data() {
        return {
            msg: 'Hello world'
        }
    }
}
</script>
<style lang="stylus">
h1
    background-color #333
</style>

可以看出对于开发来说,Vue要舒服很多。样式可以直接写在模板文件中。每个组件写起来也都是相互独立的。非常的舒服。

而React则比较操蛋了。要写较多的代码,比如头上都得写import React from 'react'。结构也不是很清晰(相比于Vue的写法来说)。

React的生命周期函数是比较正经的。也都很容易懂。然而Vue从命名上来看则更容易。写出的代码即使对Vue了解不多也都能读出个七七八八。而React?冗长的函数名虽然清楚,但是让人看着就头疼。

从这里可以看出我其实是非常偏爱Vue的。然而Vue自然也是有短板,最最最让人难过的是生态。React周边的库简直不要太多。 还有很多类似AmazeUI-react, ant-design的库可以非常快速的构建原型产品。Flux则更是让人耳目一新。严格的单向数据流相信在刚刚出来的时候一定是突破性的。 还有细腻的Virtual DOM,使得性能提升非常的精确。 还有杀手级的React-native,没的说,前端攻城师们看到都疯了。

与之相对的Vue就比较弱了。没有出名的库,大型项目的数据管理的Vuex也是刚出的。和React-native相对应的似乎有一个,阿里巴巴的Weex,不过没有开源,而我看来开源对他们来说似乎也不是很愿意。

在知乎上看到徐飞说Vue在2016会有腾飞,我也比较相信的。所以最近已经把重心押宝到了Vue

对于代码内容,我瞥过几眼react的源码,长,长,长。。。难读。 Vue的源码就比较正常了,虽然风格会乱变,但至少正常。最近在读,有什么进展会写出来的。

Stylus VS Sass

我其实是十分喜欢Sass的,因为它确实写起来比普通的CSS舒服多了。有一些函数,变量,继承什么的,好多特性。

我之所以切换到了Stylus,是因为。。。node-sass太难装了。实在是太难太难装了。似乎是因为node-gyp在windows平台的编译特别困难。

总之我是编译了两天之后实在是装不上只能硬着头皮看了Stylus文档,然后在项目中用了Stylus。

只能说用起来真舒服。

我不说什么基础的语法了,只能说语法非常优美。写起来像是正常人用的。而且安装很简单。

好像还有什么PostCSScssNext的东西。我觉得Stylus暂时是足够我使用了。

对了,我比较推荐的目录方式是这样的。

--- src
  |-- styles
    |-- normalize.styl
    |-- variables.styl
    |-- animates.styl
    |-- global.styl
    |-- forms.styl
    |-- lists.styl
    |-- ...其他全局组件

这里不包含单独的在*.vue中的独特的样式。

其实在Sass中也可以用这样的目录格式。

在单独的文件中,目前比较推荐的做法是BEM的命名方式。三个字母的意思是Block, Element, Modifier。我记得laracasts.com有个课程,可以去看看。

我觉得这样的目录和命名方式都是蛮好的,当然如果你有更好的方案也欢迎写给我说说。

Global State

全局状态在非常非常小的项目中没什么卵用。但是只要稍微上点儿规模就会产生相当大的问题。

我之前用React写过daxuedogs的表单注册页面,结构其实现在想想也并不复杂。而复杂的地方在于状态。。。比如按钮的一个disabled属性,什么时候有这个属性,什么时候没有呢?很简单吗?并没有。

用户在提交表单后可以影响这个值,用户在输入已注册的用户数据,通过Ajax也可以影响这个值,在组件初始化之后从服务端获取数据之后的数据也可以影响这个值。

看吧,现在只有三个操作可以控制,然而真正的大型项目中,几十个操作控制一个状态也并不是不可能的。

这个时候可是相当的乱了。

Flux的出现让人看到了希望。

说说Vuex吧,也是单向数据流的。只不过我觉得它更好理解,可能是中文文档的功劳吧。反正Redux我是看不懂。

而且比较害怕Redux,这货版本号的更迭近乎疯狂,API一天一变都是会出现的。

我觉得Vuex的文档写的非常好,如果你看不懂Redux可以试着看看Vuex,相信我,你差不多会明白的。

Flex VS Float

这里是布局的环节,自从我在我的简历项目:iamhele.com中用了Flex布局后就再也不想用传统的方式了。

众所周知,float比较操蛋,尤其是一个clear:both的坑简直不要太多。各种兼容Hack都要考虑一下。

Flex就比较正常了。除了兼容性比较差以外,布局是非常舒服的。其实硬说兼容性差也是没道理的,能兼容到IE10呢,加上autoprefixer就差不多了。只是里面有一些特性可能要注意: 比如flex-wrap:wrap似乎在微信里不能用。

关于兼容性,我之前也写过文章说过,总是兼容低版本会使得历史总是停步不前。千万种不好。

Components

我觉得组件最好最好的一点在于耦合的降低。

在一开始的想法是页面正式编写之前先写几个commonComponents。比如Alert, Loading这种的。

正式开始写页面的时候又感觉和业务不够合适,于是重写了新的Alert组件。结果仍旧是运行的很好。要改的地方根本不多。实在懒也可以不改。只是风格可能不一致。

想想,普通的页面,一张页面一张页面地改。。。那酸爽。囧

其实更可以在任何新项目之前先把老项目的commonComponents文件夹复制过去,一点儿问题都没有,反正是很通用的。新开个类似于Bootstrap的Vue版项目可能要比普通的情况简单很多。而且源码可读。

不过我最近并没有这个计划,我十分相信,在2016年会出现很棒的类似ant.design的项目。

Webpack VS Gulp

前端变化快,太快了,非常的快。

我记得年初的时候我还在琢磨Grunt插件怎么写,然后就不知道怎么回事,就写了了gulpfile.js。当我享受gulp带来的舒适的时候,好像大家突然就转到了webpack了。。。

这个变化好快好快。

我犹记得上次D2,阿里一个title特别高的人说,他20年前写的js现在根本看不懂,而20年前写的Java依旧在生产环境跑的好好的。

像js这样的变化让人实在是难以追上。然而每次追上之后那种畅快也是用老旧工具的人所不能体会的。

我在一开始是拒绝webpack的,因为我觉得gulp就挺好的。什么功能也都齐全,watch也不慢。

然而在某次写react的时候尝试一下了以后,我发现回不去了。

超快的加载速度,自动reload,打包,压缩,合并。各种各种功能简直不要太开心。

然而我也知道,webpack也绝不是终点。上次在知乎看到贺老说下一代的打包工具看得我高潮迭起。什么自动转义,http2,自动发布cdn什么的。棒棒的。

技术栈

目前来看,最合适的技术栈应该是

我目前用的是纯Vue技术栈了

这个文章写了快一周,算了,暂时就这样了。push!