选项式API（Options API）：

• 基于对象（data、methods、computed、watch等）的API。
• 每个组件的选项是集中在一个地方的。
• 可能会导致组件变得庞大而复杂。

// 选项式API示例
Vue.component('my-component', {
  data() {
    return {
      message: 'Hello, Vue!'
    };
  },
  methods: {
    updateMessage() {
      this.message = 'Updated message';
    }
  },
  template: '<div>{{ message }}</div>'
});

组合式API（Composition API）：

• 基于函数的API，使用setup函数。
• 使用函数组合而非类继承。
• 可以更灵活地使用Vue的响应式系统和其他API。
• 需要Vue 3.x。

// 组合式API示例
Vue.component('my-component', {
  setup() {
    const message = Vue.ref('Hello, Vue!');
 
    function updateMessage() {
      message.value = 'Updated message';
    }
 
    return { message, updateMessage };
  },
  template: '<div>{{ message }} <button @click="updateMessage">Update</button></div>'
});

选项式API更适合于旧版Vue 2.x，而组合式API则是Vue 3.x推出的一个新特性，旨在提供更简洁、更易于理解的方式来组织组件逻辑。

伴随着新到的vue3，我们编写组件的书写方式也发生了变化。
除了底层的更新，编写方式的改变或许才是我们最能直观感受到的。

其实就是vue3多了一种名为组合式api(composables api)的写法，相对应传统的选项式api(options api)
组合式api简单来说就是使用setup方式编写组件。

传统的选项式api

来看看这种传统的写法：65行

<template>
  <div class="home" v-if="userInfo">
    <my-header/>
    用户详情：{{fullUname}},{{userInfo.age}}岁
  </div>
</template>
<script>
import MyHeader from '../components/my-header.vue';

export default {
  // 组件：公共头部
  components: { MyHeader },

  // 属性： 接受属性用户id
  props: {
    userId: {
      type: String,
      default: '2022-01-01'
    }
  },

  // 状态：用户信息
  data() {
    return {
      userInfo: null
    }
  },

  // 计算属性：给用户名加一个牛逼的前缀
  computed: {
    fullUname() {
      if(this.userInfo && this.userInfo.name){
        return '牛逼的' + this.userInfo.name;
      }
      return ''
    }
  },

  // 监听：用户id改变
  watch: {
    userId: {
      handler(newVal, oldVal) {
        console.log('用户id变化啦:'+newVal);
      },
      immediate: true
    }
  },

  // 方法：同步用户信息
  methods: {
    syncUserInfo(userId) {
      this.userInfo = {
        id: userId,
        name: '小明',
        age: 20
      };
    }
  },

  // 钩子：初始化
  mounted() {
    this.syncUserInfo(this.userId)
  }
}
</script>

先进的组合式api

来看看这种先进的写法：48行

<template>
  <div class="home" v-if="userInfo">
    <my-header />
    用户详情：{{ fullUname }},{{ userInfo.age }}岁
  </div>
</template>
<script setup>// <script setup> 是在单文件组件 (SFC) 中使用组合式 API 的编译时语法糖。
import { ref, onMounted, watch, computed } from 'vue';
import MyHeader from '../components/my-header.vue';

// 属性： 接受属性用户id
const props = defineProps({
  userId: {
    type: String,
    default: '2022-01-01'
  }
})

// 状态：用户信息
const userInfo = ref(null);

// 计算属性：给用户名加一个牛逼的前缀
const fullUname = computed(() => {
  if (userInfo.value && userInfo.value.name) {
    return '牛逼的' + userInfo.value.name;
  }
  return ''
})

// 监听：用户id改变
watch((newVal, oldVal) => {
  console.log('用户id变化啦:' + newVal);
}, { immediate: true })

// 方法：同步用户信息
const syncUserInfo = (userId) => {
  userInfo.value = {
    id: userId,
    name: '小明',
    age: 20
  };
}

// 钩子：初始化
onMounted(() => {
  syncUserInfo(props.userId)
})
</script>

而 NODE_ENV 就是其中的一个环境变量。这个变量主要用于标识当前的环境（生产环境，开发环境）。默认是没有这个环境变量的，需要自己手动配置。不同系统有不同的环境变量配置方式，在这里就不多加赘述。

NODE_ENV 变量只能在系统中配置吗？其实不然。在 Vue 项目中， Vue 提供了自己的配置方式。这就要涉及到 Vue CLI 中模式的概念了。 Vue CLI 文档说明了这个问题。

也就是说，在 Vue 中， NODE_ENV 可以通过 .env 文件或者 .env.[mode] 文件配置。配置过后，运行 Vue CLI 指令（ npm run dev(serve) ，npm run build ）时，就会将该模式下的NODE_ENV载入其中了。而这些命令，都有自己的默认模式：

• npm run dev(serve) ，其实是运行了 vue-cli service serve ，默认模式为 development 。可以在 .env.development 文件下修改该模式的 NODE_ENV 。
• npm run build ，其实运行了 vue-cli service build ，默认模式为 production 。可以在 .env.production 文件下修改该模式的 NODE_ENV 。

除了以上的修改方式外，也可以在命令后直接使用 –mode 参数手动指定模式。当然，每个模式配置的变量也不只有 NODE_ENV , 也可以通过配置其他的变量简化工作流程。

模式的应用

有了模式的概念，就可以根据不同的环境配置模式，就不用每次打包时都去更改 vue.config.js 文件了。比如在测试环境和生产环境， publicPath参数 （部署应用包时的基本 URL） 可能不同。遇到这种情况就可以在 vue.config.js 文件中，将 publicPath 参数设置为：publicPath: process.env.BASE_URL
设置之后，再在各个 .env.[mode] 文件下对 BASE_URL 进行配置就行了，这样就避免了每次修改配置文件的尴尬。其他的配置也是同理。
Tips: 即使不是生产环境，也可以将模式设置为 production ，这样可以获得 webpack 默认的打包优化。

process.env使用

1、在nodejs中使用

1、安装

npm install dotenv

2、根目录下创建 .env 文件

HOST = localhost
PORT = 8080

3、入口文件中引入 dotenv 并使用

require("dotenv").config({path: '.env'})
console.log(process.env.HOST); // localhost
console.log(process.env.PORT); // 8080

2、在vue中使用

在使用脚手架创建项目的时候，会自动安装dotenv，可以从package-lock.json中找到配置。在main.js入口文件中打印console.log(process.env);可以看出，默认的模式是development即开发模式。

也就是说，在Vue中， NODE_ENV 可以通过 .env 文件或者.env.[mode]文件配置。配置过后，运行 Vue CLI 指令（ npm run dev(serve) ，npm run build ）时，就会将该模式下的NODE_ENV载入其中了。而这些命令，都有自己的默认模式：

• npm run dev(serve) ，其实是运行了 vue-cli service serve ，默认模式为 development 。可以在 .env.development 文件下修改该模式的 NODE_ENV 。
• npm run build ，其实运行了 vue-cli service build ，默认模式为 production 。可以在 .env.production 文件下修改该模式的 NODE_ENV 。

注意：只有 NODE_ENV，BASE_URL 和以 VUE_APP_ 开头的变量将通过 webpack.DefinePlugin 静态地嵌入到客户端侧的代码中。这是为了避免意外公开机器上可能具有相同名称的私钥。

NODE_ENV = development
VUE_APP_BASE_API = 'http://localhost:8099/'

注意：.env 环境文件是通过运行 vue-cli-service 命令载入的，因此环境文件发生变化，你需要重启服务。除了以上的修改方式外，也可以在命令后直接使用--mode参数手动指定模式。

当运行 vue-cli-service 命令时，所有的环境变量都从对应的环境文件中载入。如果文件内部不包含 NODE_ENV 变量，它的值将取决于模式，例如，在 production 模式下被设置为 “production”，在 test 模式下被设置为 “test”，默认则是 “development”。

NODE_ENV 将决定您的应用运行的模式，是开发，生产还是测试，因此也决定了创建哪种 webpack 配置。

例如通过将 NODE_ENV 设置为 “test”，Vue CLI 会创建一个优化过后的，并且旨在用于单元测试的 webpack 配置，它并不会处理图片以及一些对单元测试非必需的其他资源。

同理，NODE_ENV=development 创建一个 webpack 配置，该配置启用热更新，不会对资源进行 hash 也不会打出 vendor bundles，目的是为了在开发的时候能够快速重新构建。

当你运行 vue-cli-service build 命令时，无论你要部署到哪个环境，应该始终把 NODE_ENV 设置为 “production” 来获取可用于部署的应用程序。

示例配置

我们现在有三个配置文件，分别如下：

#.env.development
NODE_ENV=development
VUE_APP_AXIOS_BASEURL=http://xxxx

#.env.preview 测试环境的配置
NODE_ENV=production
VUE_APP_AXIOS_BASEURL=http://xxxx

#.env.production
NODE_ENV=production
VUE_APP_AXIOS_BASEURL=http://xxxx

在 axios 中使用

import axios from "axios";
const conf = {
  baseURL: process.env.VUE_APP_AXIOS_BASEURL,
};
return axios.create(conf);

package.json 配置

{
  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build --mode preview",
    "build:release": "vue-cli-service build"
  }
}

启动方式

npm run serve # 默认 dev
npm run build # 测试环境
npm run build:release # 正式环境

Vue网站基本架构

Vue是一个轻量级、高性能的JavaScript框架，其核心思想是数据驱动和组件化。在Vue中，我们使用组件来构建页面，每个组件都有自己独立的状态和行为。而整个应用程序则由多个组件组合而成。

前后端分离模式

前后端分离模式是指将前端和后端代码完全分离开来，前端只负责展示数据和交互逻辑，后端则只负责提供API接口和数据处理。这种模式可以使得前后端开发团队专注于自己的领域，并且可以更加灵活地进行部署和维护。

单页应用程序

Vue通常被用于构建单页应用程序（SPA），这种应用程序只有一个HTML页面，所有的内容都是通过JavaScript动态加载的。由于SPA只有一个页面，搜索引擎难以抓取其中的内容，因此Vue网站通常会被认为不利于SEO。

Vue SSR

Vue SSR是指将Vue组件在服务器端渲染成HTML字符串，然后将其发送给浏览器进行展示。使用Vue SSR可以使得搜索引擎更容易地抓取网站内容，并且可以提高首屏加载速度和SEO效果。

预渲染

预渲染是指在构建时将Vue组件渲染成静态HTML文件，然后将其发布到服务器上。当用户访问该页面时，服务器直接返回静态HTML文件，无需进行任何动态渲染。预渲染可以提高首屏加载速度和SEO效果，但对于动态更新频繁的页面不太适用。

优化Vue网站SEO

除了使用Vue SSR和预渲染外，还有一些其他方法可以优化Vue网站的SEO效果。比如使用vue-meta-info插件来优化页面元信息、使用路由懒加载来提高页面加载速度、使用图片懒加载来减少首屏加载时间等等。

总的来说，Vue网站能否被搜索引擎抓取取决于具体的实现方式。我们可以通过使用Vue SSR、预渲染等方法来提高SEO效果，同时还可以使用一些优化技巧来进一步提升网站性能和用户体验。

路由异步加载

Vue项目的页面是使用的虚拟路由，页面内容是靠vue-router配置的路由链接来访问的，SPA单页面应用开发，适合开发后台系统，但是对搜索引擎不友好，因为最后只生成一个页面。

搜索引擎是靠页面的链接来爬取网页内容，然后搜录进去搜索引擎数据库的，而vue打包以后的项目只有一个页面，所以其中的内容搜索引擎蜘蛛当然无法收录，这是一个比较不好的地方，当然后期可以进行SEO优化。

所以当你的项目vue组件很多的时候，打包以后的首屏渲染优化就是一个非常重要的问题，改善性能，提高加载打开速度，是很关键的一点。

下面，我就vue中的路由异步懒加载做一个方法分享，建议如果组件不是很多的项目不要使用这种方法，会增加加载时间和速度，对于组件很多的项目可以采用这种方法。

默认es6引入

但是这种方法组件多了，加载就会变慢，打包以后的app.js文件体积会变得非常大，推荐使用后面比较常用的两种。

import example from '../components/example.vue'

vue官方推荐

使用import把组件分割成一个个小的单独的文件，缩小文件体积。webpackChunkName里面的就是这个组件/子组件的打包后的名字。

const example = () => import(/* webpackChunkName: "group-example" */ '../components/example.vue')

require方法

下面就是我比较喜欢的require方法，这个也是可以把组件分割成小的块。

const example = resolve => require(['../components/example.vue'], resolve);

element组件优化

由于是后台项目，所以选择element-ui框架进行后台系统搭建，对这个进行优化也可以减小体积，提高速度和减少加载时间，提高用户体验。

对这个框架的优化可以使用二种方法，但是我还是比较喜欢这种方法，就是对组件不用全局引入，还是改成按需加载的比较好。

全局使用

全局引入和使用

import elementUI from 'element-ui'
Vue.use(elementUI)

这种方法对于只用少量element-ui组件的情况来说，很多组件都是多余的，会无形中加大加载时间和项目打包后的体积，所以使用下面这种按需引入的方法可以有效解决这个问题。

按需引入

// 按需引入
import {
  Form,
  Button,
  Table,
} from 'element-ui'

// 按需使用
Vue.use(Form)
Vue.use(Button)
Vue.use(Table)

还要一些加载和消息提示等的组件

// 按需引入
import {
  Loading,
  Message,
  MessageBox,
  Notification,
} from 'element-ui'

// 按需使用
Vue.use(Loading.directive)
// 挂载到vue实例上面
Vue.prototype.$loading = Loading.service
Vue.prototype.$msgbox = MessageBox
Vue.prototype.$confirm = MessageBox.confirm
Vue.prototype.$alert = MessageBox.alert
Vue.prototype.$prompt = MessageBox.prompt
Vue.prototype.$message = Message
Vue.prototype.$notify = Notification

webpack配置优化

依赖包体积优化

众所周知，日常开发过程中，前端这块早就已经开始进行工程化和组件化开发了，所以免不了下载各种node包，使得打包后的体积也是非常的庞大，下面使用webpack的一个配置外部扩展就可以解决这类问题。

externals配置练习

webpack官方文档是有一个配置用来处理各种依赖包打包优化的，这是【externals外部扩展】。

使用方法：这个案例以jQuery为主。

• 引入cdn,在index.html的head标签中写入。

<script
  src="https://code.jquery.com/jquery-3.1.0.js"
  integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
  crossorigin="anonymous">
</script>

• 修改webpack配置文件webpack.config.js

属性就是你在项目中引入的名称，后面的值就是jQuery的暴露出的方法名称。

externals: {
  jquery: 'jQuery'
}

• 最后使用

import $ from 'jquery';
$('.my-elem').animate(/*some things*/);

这样三步以后，打包后的文件体积会缩小很多，一个不是很明显，但是很多个包使用这种方法，效果就比较显著了。

externals配置实战

在index.html中引入cdn，以下是几个常见的cdn服务商。

• bootcdn
• 七牛云
• 又拍云
• unpkg
• jsdelivr
• cdnjs

这里使用国内的bootcdn服务，版本的话你自己项目使用的哪个就引入哪个。

<script src="https://cdn.bootcss.com/vue/2.6.10/vue.min.js"></script>
<script src="https://cdn.bootcss.com/vue-router/3.0.7/vue-router.min.js"></script>
<script src="https://cdn.bootcss.com/vuex/3.1.1/vuex.min.js"></script>
<script src="https://cdn.bootcss.com/axios/0.19.0/axios.min.js"></script>
<script src="https://cdn.bootcss.com/element-ui/2.10.1/index.js"></script>

在webpack配置文件webpack.base.conf.js中entry属性后面加下面一段：

同样的，属性是你在项目中使用的名称，后面的值是包暴露出的方法名称。

externals: {
  'vue': 'Vue',
  'vue-router': 'VueRouter',
  'vuex': 'Vuex',
  'element-ui': 'elementUI',
  'axios': 'axios',
}

Gzip压缩和sourceMap优化

这个也是压缩文件的一个方法，线上服务器的nginx也开启gzip功能更好；取消资源地图，可以有效保护源码。

在webpack的build文件中，开启Gzip压缩功能和禁用资源地图。

module.exports = {
  // ...
  build: {
    productionSourceMap: false,
    productionGzip: true,
  }
}

这样做的话，打包以后就不会再有sourceMap文件了，也会多了几个以.js.gz后缀名的文件。

项目依赖包统计分析

最后，介绍一点日常开发过程中用到的依赖包分析包，开启以后可以可视化的观察每个包的体积，帮助你整理分析每个包的结构。

webpack配置

• 下载依赖包webpack-bundle-size-analyzer

npm i -D webpack-bundle-size-analyzer

• 引入配置

两种引入方法

// commondjs方法
var WebpackBundleSizeAnalyzerPlugin = require('webpack-bundle-size-analyzer').WebpackBundleSizeAnalyzerPlugin;
// es6方法
import { WebpackBundleSizeAnalyzerPlugin } from 'webpack-bundle-size-analyzer';

在webpack的配置文件中插件部分加入：

module.exports = {
  // ...
  plugins: [
    new WebpackBundleSizeAnalyzerPlugin('./reports/plain-report.txt')
  ]
  // ...
}

使用上面配置会生成以下内容：

<webpack-output-path>/reports/plain-report.txt

vue-cli脚手架配置

由于vue-cli已经集成了这个插件，所以使用方法就是下载插件，最后执行命令npm run build --report就可以打包后查看了，会自动在http://localhost:8888打开。

我是否需要使用框架？

如果不尝试回答这个问题就是我们的失职，这越来越成为社会上某些人的口头禅，在网络平台上的争论也已经发展到犹如不需要额外编写 API 能更简单创建 Web 应用那样的地步。就像本系列中所有的内容一样，我们的回答也大都是依据这些内容。

虽然无框架也能正常工作，但是，这也是有代价的。那些主张无框架手写 JavaScript 的人，那些通常会被我们认为是斯德哥尔摩综合症（情感上会依赖他人且容易受感动的人）的人，忘记了网络平台上有多套快速发展的 API ，至少有三种不同的技术，三种截然不同的语法。web 平台规范并确定了超过 12000 个 API，事实上浏览器中的维恩图也显示了这些巨大差距。

如果你是一个有着深厚技术和经验的人，确实可以坦诚的不使用框架。但你团队的其他成员呢？你手下的那些人呢？或者当你的决定把你自己陷入困境的时候呢？

这种情况下，我们将会看到一个不用框架的团队在展开冒险，最后他们会发现自己创建了一个需要自己着手维护的框架。接着就会出现寻找人才的问题，他们不需要知道框架是如何工作的，只需要寻找会调用网络平台 API 的高级技能人才或者一些自称有经验的人才，最后却发现缺少利于团队发展的技能深度和经验。

团队应该避免虚假等价（false equivalence）的陷阱，很显然，在 web 技术的应用方面具有创新性的公司在不断提高他们的市场价值和竞争力，Google、Facebook 和 Netflix 公司都是很好的例子。但是大多数公司不是这样，他们应该承认这一点。

Angular 2+

• 有什么优势？

Angular 2+ 的最大优势在于它的流行程度。也有人认为它和 Google 密切相关的名字，会影响团队使用它。Angular 1 的迅速流行是因为那些来自其他交互式应用程序开发环境的人会发现对于开发单页面 web 应用程序具有相似的模型-视图模式。

通过对 Angular 1 进行现代化演变和重新构建框架的某些部分，Angular 2+ 已经真正的爆发了，大量的正式的和非正式培训机构数量都让人印象深刻，开发者有很强的市场竞争力。对于用户来说它有一套用于构建用户界面的丰富组件，这也是本系列中少有的几个框架能够做到这点。

• 有什么弱点和挑战？

我们觉得 Angular 框架着重于在单个页面应用程序中创建用户界面并没有处理构建完整的 web 应用这个更大的关注点，如果不及早确定下来，这将会导致整个项目难以维护，在实际项目中，运行时提供不属于核心框架的技术往往让人觉得不可思议，这大大降低了 TypeScript 对最终开发者的价值。

• 未来将何去何从？

Angular 5 刚刚发布，这看来是 Angular 已经成功的印证了快速发布版本的承诺，在 Google 的持续支持下，Angular 会越来越成熟。

像许多的大型组织一样，Google 具有多重（分裂）的人格，从外表上看，Angular 团队和那些专注于浏览器标准的团队之间显得很和谐。但我们的观点是，和谐只是一层薄薄的窗户纸。Angular 团队对于 web 组件和渐进式 web 应用没有一个真正解决方案。我们认为，业界普遍认可的标准将会在 Angular 框架中会逐步实现，这将会影响到如何更好的构建 Angular 应用将成为一个中/长期的风险。

• 何时选择 Angular 2+

如果你需要在一个大型的框架内获取技术资源，框架内的技术通常很容易移植；或者你需要在框架中训练开发人员，并且还要有一定的信心，他们会在短期内获得一定的开发能力，这样的话你可以考虑 Angular 2+ 。需要注意的是 Angular1（angular.js）与 Angular2+ 是截然不同的，其中的应用、技术和经验不能直接移植到 Angular2+ 的开发中去。

如果你的 Web 应用能够很好的转化为标准的模型-视图模式，那么你也可以忽略其他直接考虑使用 Angular2+ 。

如果你对 Google Material UX 设计模式满意，那么 Material Angular 是遵循该模式的一种快速、简单且可靠的方式。

React + Redux

• 有什么优势？

React 和 Redux 的最大优势在于它们相对简单和专注。做一件事情并把它做好是非常困难的，但这两个库都很有效地完成了它们的目标。虽然对于某些状态容器方法可能是外部的，但大多数开发人员还是可以轻松掌握概念，并了解单向数据体系结构的好处，简化大量的用户界面应用程序。

• 有什么弱点和挑战？

React 和 Redux 最大的弱点不是它们是什么，而是它们不是什么。要构建一个功能丰富的 Web 应用程序，你需要许多功能，一旦脱离 React 和 Redux 和其他一些库的核心，你将发现一个非常分散的社区，拥有无数的解决方案和模式，不容易整合在一起。

因此，虽然 React 和 Redux 都是非常专注的库，但缺乏经验的团队还是会很容易地生成不可维护的解决方案，而不是意识到他们所做的选择会导致性能不佳或错误。 即使有经验的开发人员也可能意识到，一个松散的架构或惯例可能会在未来困扰他们。

假省钱是一种对自己的欺骗，组织范围内采用 React 和 Redux 将轻松降低无效率问题。 没有其他库和模式的广泛约定和标准化，标准化 React + Redux 比较于我们正在采用的 JavaScript 来编写我们的应用程序效率要高。

• 未来将何去何从？

Facebook 和 React 最近从繁琐的附加专利纠纷中抽离，他们认识到，就像其他项目一样，更广泛的社区能够提高自己的声音。 我觉得这有助于 Facebook 意识到他们还不能更好地了解我们，相信我们来引导项目。 希望这将继续贯穿项目的特点和技术方向。

很难预测 React 和 Redux 的未来。 但是，将库集中在一起，确实会显着提高适应性，大多数 React + Redux 模式都会促进一个分离的体系结构，从而可以轻松地进行重构和迭代。 两年前，大家喜欢的还是 React + Flux，但整个社区很快就拥抱了 Redux。 思维或模式的其他重大转变可能很容易被采纳。 这种关键能力可能会持续到未来。

• 何时选择 React + Redux？

如果你很少需要手把手指导，并且正在寻找更好的库而不是全面的框架，那么 React + Redux 可能是正确的。 在这一过程中，你不仅需要对你的团队和组织的能力保持诚实，还要在你的初始开发过程中，以及在整个应用程序的长期维护过程中保持诚实。

Vue.js

• 有什么优势？

渐进式构建能力是 Vue.js 最大的优势，Vue 有一个简洁而且合理的架构，使得它易于理解和构建。

Vue 有一个强大的充满激情人群的社区，这为 Vue.js 增加了巨大的价值，使得为一个空白项目创建一个综合的解决方案变得十分容易。

• 有什么弱点和挑战？

在模型-视图应用程序和状态容器类型的应用程序之间的互相转换可能会令人感到困惑，即使没有完美包含一个模式到另一个模式的完美转换，但让人感觉希望能维持两个模式的相关性。对于那些期待 vue.js 完美解决方案，并可能导致难以维护不一致的应用程序的人来说，这至少是令人困惑的。

一个更大的挑战是 vue.js 依赖于一个单独的人，很明显，其他的项目基本是由一个组织提供支持，但这让人感觉更加有意义，虽然它有一个强大文件的社区和许多有创新的新增项目，但是 vue 核心的开发基本落在一个人身上。

我们很高兴看到 vue 更加容易接受新兴的标准方法，但是它的类似于 web 组件的模式，而不是真正的 web 组件，这可能是 vue 所得不偿失的地方。

• 未来将何去何从？

虽然 vue.js 有相当广泛的应用，但也很难预测在中期发展中这个势头能持续多久，它不是由一个商业组织直接支持并维护，因此，这很大程度上依赖于维护者的生存能力和继续维护下去的愿望来决定。

它也表现出了一定程度的语言适应能力，并且随着某些模式的落伍和失宠而继续保持自身语言的现代化和时代性，目前没有迹象表明 vue.js 架构将来无法适应进一步发展。

• 何时选择 Vue.js？

如果你有一个传统的 web 应用程序，并需要一个强壮稳健的应用程序层，那么 vue.js 可能是一个很好的选择，它有清晰的模式，即使没有经验的团队也能正确或者错误的使用它。尽管 vue UX 框架没有开箱即用的功能，但在 vue.js 上也能大量持续性构建应用，这将有利于你的项目。 

Dojo 2

• 有什么优势？

Dojo2 专注于带来更多构建在状态容器体系之上的动态组件的体验模式，填补了 react+redux 等框架的许多空白。

Dojo2 也知道它不单单只是在自己的生态圈发展，通过包含 web 组件导入和导出功能，也意识到需要支持不同的应用实例，但它依旧提供了一个结构化和固有的框架价值，Dojo2 的核心基础仍然是专注于提供交互性。

Dojo2 觉得它提供了大量重要的功能和解决方案，这对于构建完整的 web 应用是十分重要的，对于其他大多数框架而言这并不是重点。提供一个国际化系统和广泛的易接入性的模式也是其中之一，同时也提供一个主题系统和演进模式，用以确保不仅能为 Typescript/JavaScript 提供良好的代码开发，也能像 CSS 那样管理资源。

Dojo2 专注于提供一个结构化和符合人体工程学的开发环境，通过使用 typescript 和其他开发模式，它试图提供安全的防护机制去引导新手开发人员，通过专注于提高框架开发效率和开发安全性，旨在让开发团队能够快速交付更好的 web 应用程序。

• 有什么弱点和挑战？

有争论的是，通过进一步延长 Dojo2 的发布时间的做法是否是在阻碍框架的发展，反观其他项目由于其资源的扩大能够继续发展和快速迭代，导致 Dojo2 目前明确的处在一个拥挤的竞争环境之中。

这也许是一个潜在的发展机遇和挑战，同时希望能够在灵活性和交互性上而不是别的特殊理由去使用 Dojo2 。

• 未来将何去何从？

Dojo2 将是未来优秀 web 框架之一，它将继续努力为构建可扩展性的 web 应用程序提供清晰的模式和指导。随着新标准的不断出现，Dojo2 将进一步努力去在框架中实现新的标准方法，继续尝试扩大框架的开放性和交互性，创造适合更多人使用的解决方案。

• 何时选择 Dojo2？

如果你想采用一个灵活的、现代的、响应式的 web 应用程序架构，并且你需要很多智能化的默认设置，那么 Dojo2 将是一个不错的选择。不用去拼凑和构建一个管道，并且为你提供更高阶的命令模式让你可以更加专注的开发项目，更加确认它是直接为你可以直接生产开发所准备的。另外，如果你了解 typescript 的优势，Dojo2 会十分严谨的使用 typescript 来管理并提供一个稳健的开发者开发环境。

Ember

• 有什么优势？

Ember.js 可能是最固执己见的主流框架，这也是其最大的优势。它有创建 Ember.js 应用程序的正确方法，通常只有一种方法来创建应用程序。Ember.js 更类似于一个产品或平台，在那里你会到一个供应商的长期支持和维护。Ember.js 提供了对其平台的全面版本管理，升级工具以及对 API 升级的强大指导和工具。成熟，是对 Ember.js 的一个很好的总结。

Ember.js 多年来已经证明，它可以保持其框架并使其与现代标准保持一致，同时不会过早遗忘传统浏览器。

Ember.js 有一个清晰合理的架构来全面构建 Web 应用程序。

• 有什么弱点和挑战？

Ember.js 可能是最固执己见的主流框架，这也是它最大的弱点。虽然社区是开放的并且接受投资，但是仍然需要找到一个正确的方式来摆脱下滑的趋势，这可能是具有挑战性的问题。

拥有一个丰富的第三方社区也可能具有挑战性。由于没有开箱即用的 UX 组件，这很可能会让你使用第三方套件。你可能会发现，虽然这些套件并不全面，你将需要建立或寻找其他组件。由于 Ember.js 没有扩展，所以对如何交互和管理 DOM，你会发现你有不一致的部件，而且也没有提供一个易于管理的界面。

• 未来该何去何从？

Ember.js 的主要贡献者是 JavaScript 语言标准委员会 TC39 的核心参与者。在过去的几年中，Ember.js 对 JavaScript 的方向比任何其他框架都有更直接的影响。我们的观点是，这将在未来继续受影响，并帮助促进 JavaScript 的特性和模式。这也意味着 Ember.js 将继续保持与未来标准的紧密结合的关系。

Ember.js 不可能在将来随时消失，尽管他们的创新很可能是通过与 Ember.js 紧密结合的其他项目来实现的，比如 Glimmer，它为 Ember.js 应用程序提供了一个新的 UI 框架，该框架基于 TypeScript。

• 为什么我会选择 Ember.js？

如果你在框架中寻找成熟度，那么 Ember.js 很难出错。另外，由于 Ember.js 提供的内容被理解，并且有广泛的官方和官方认可的培训，以及严格的结构，找到能够建立基于 Ember.js 的应用程序的人才可能比其他框架更容易。也可以教大型团队如何构建应用程序，并确保整个团队的共同对话和理解。

如果你想要对社区保持信心，并批判性地思考他们平台的变化，那么 Ember.js 会是一个很好的考虑因素。您可以花更少的时间跟随当前的技术趋势，并更多地关注创建应用程序。

Aurelia

• 优势在哪？

Aurelia 有很多关于构建 Web 应用程序的方法，结构和想法。 这个框架的编写有很多技术上的优点。

• 有什么弱点和挑战？

我们估计最大的挑战就是核心发展的动力和临界物质的缺乏。我们感觉很多的观点和概念都是我们对其他框架的批评性的想法，但是这些愿望都没有完全交付。它似乎就像是一个正在进行的工作一样，就像 Dojo 2，但是它已经是一个已发布的框架。

大部分的 Aurelia 是坐落在一个人的肩膀上，如果这个人的的注意力或可用性改变，那么将会带来挑战。

• 未来会如何？

对于 Aurelia 来说，有一个很大的机会。如果它能够实现他的愿景，他将要完整的保存这个构建 Web 应用程序的已有的模板，但会以更健全、更完整的方式交付。我们不知道 Aurelia 是否能够充分的利用这次机会。

• 为什么我会选择 Aurelia？

如果您致力于 Web 模型视图应用程序模块，并且你和你的团队试图想把一些事做的更好，那么 Aurelia 会是一个选择。它就像是一个正在寻求一个更大的社区来帮助它的发展和进化的框架。

最后的思考

一个框架仅仅是一些模式的体现，一些科技的集成，源码帮助我们更加容易去构建和维护网站应用，如果你是个体开发者，我们能提供的最好的建议是花费尽可能多的时间使用那些你认为可以为你所用的框架。

如果你是公司的管理者或骨干领导要去做决定，请记住功能特性只是决定的一方面，有时候并不是越多越好。要根据团队情况和项目需要选择合适的框架，适合自己的才是最好的。

JavaScript ES2015+ 功能

ECMAScript 6（简称 ES6）于 2015 年 6 月正式发布，是 JavaScript 语言的下一代标准。它的目标，是使得 JavaScript 语言可以用来编写复杂的大型应用程序，成为企业级开发语言。

标准的制定者有计划，以后每年发布一次标准，使用年份作为标准的版本。而 ES6 是在 2015 年发布的，所以又称 ECMAScript 2015。也就是说，ES6 就是 ES2015。目前最新版本已更新到 ES8。以下为 ES2015、ES2016、ES2017 的新特性。

JavaScript ES2015+ 更多功能模块详见：https://devhints.io/es6

JavaScript

以下基于 JavaScript 学习资源、以及基本对象、数据对象、核心 DOM 等 API 进行汇总，完整的 API 原图详见：http://overapi.com/javascript

JavaScript 正则表达式

JavaScript 正则表达式汇总，如下图所示。

React

React 是一个用于构建用户界面的 JavaScript 库，本 API 主要以 React v15 和 v16 版本为主。

更多 API 详见：https://devhints.io/react

Redux

Redux 对于 JavaScript 应用而言是一个可预测状态的容器。换言之，它是一个应用数据流框架，而不是传统的像 underscore.js 或者 AngularJs 那样的库或者框架。

Redux 最主要是用作应用状态的管理。Redux 用一个单独的常量状态树（对象）保存这一整个应用的状态，这个对象不能直接被改变。当一些数据变化了，一个新的对象就会被创建（使用 actions 和 reducers）。更多功能特性及准则如下图所示：

Vuejs

Vue.js 是一套构建用户界面的渐进式框架。与其他重量级框架不同的是，Vue 采用自底向上增量开发的设计。Vue 的核心库只关注视图层，它不仅易于上手，还便于与第三方库或既有项目整合。另一方面，当与单文件组件和 Vue 生态系统支持的库结合使用时，Vue 也完全能够为复杂的单页应用程序提供驱动。

更多内容详见：https://vuejs-tips.github.io/cheatsheet

Vuex

Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。它采用集中式存储管理应用的所有组件的状态，并以相应的规则保证状态以一种可预测的方式发生变化。Vuex 也集成到 Vue 的官方调试工具 devtools extension，提供了诸如零配置的 time-travel 调试、状态快照导入导出等高级调试功能。

更多内容详见：https://vuejs-tips.github.io/vuex-cheatsheet

Angular 4

就在 2017 年的 3 月，Angular 已经发布了 4.0 的版本（兼容 2.x 版本）， 4.0 版本中主要是大幅度的减小了代码体积（60%），同时提高了加载的速度（肉眼可查的程度），同时报错的信息更清晰了。根据官方的文档，Angular 的版本升级会以比较快的速度进行迭代。

更多内容详见：https://angular.io/guide/cheatsheet

Flexbox

Flexbox 模块提供了一个有效的布局方式，即使不知道视窗大小或者未知元素情况之下都可以智能的，灵活的调整和分配元素和空间两者之关的关系。简单的理解，就是可以自动调整，计算元素在容器空间中的大小。

更多内容详见：https://yoksel.github.io/flex-cheatsheet/

SASS

Sass 是对 CSS 的扩展，让 CSS 语言更强大、优雅。 它允许你使用变量、嵌套规则、 mixins、导入等众多功能， 并且完全兼容 CSS 语法。 Sass 有助于保持大型样式表结构良好， 同时也让你能够快速开始小型项目， 特别是在搭配 Compass 样式库一同使用时。

更多内容详见：https://devhints.io/sass

Stylus

Stylus——富有表现力的、动态的、健壮的 CSS。更多语法内容可查看：https://devhints.io/stylus

GraphQL

GraphQL 是一个由 Facebook 提出的应用层查询语言。GraphQL并不是一个面向图数据库的查询语言，而是一个数据抽象层，包括数据格式、数据关联、查询方式定义与实现等等。GraphQL 也并不是一个具体的后端编程框架，如果将 REST 看做适合于简单逻辑的查询标准，那么GraphQL 可以做一个独立的抽象层，通过对于多个 REST 风格的简单的接口的排列组合提供更多复杂多变的查询方式。与 REST 相比，GraphQL 定义了更严格、可扩展、可维护的数据查询方式。

使用 GraphQL，你可以基于图模式定义你的后端，然后客户端就可以请求所需要的数据集。