elementUI组件其实已经很方便的使用上传功能，但是有很多弊端，感觉不是很好用，在自己用elementUI的upload实现上传功能感觉很累赘（绑定一堆的方法，绑定一堆的变量，绑定出错还得费时费力去调试……）

• ‘eg’：我就遇到个问题，上传只能上传一个文件，用插件实现的话，还得单独写个，关键还不知道往哪个方法里写，调试了很久也没调好。果断放弃了。

• ‘eg’：选择文件夹，反而还做不到，无语ing，我要做一个选择多张图片，不是234张，是好几十张，让我选择一堆图片，烦不烦，我就选个文件夹不久解决了，element反而做不到。。。

• ‘eg’：存储数据不方便，最主要的就是，绑定一堆乱七八糟的方法和变量，有时候（需要特殊处理的时候）就是不管你怎么操作，就是不对。

* 路由

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import Vue from 'vue'
import VueRouter from 'vue-router'
// 引用路由配置文件
import routes from './config/routes'
// 使用配置文件规则
const router = new VueRouter({
    routes: routes
})
// 跑起来吧
new Vue({
    el: '#app',
    router,
    store,
    template: '<App/>',
    components: { App }
})

在我们使用vue进行开发的过程中，可能会遇到一种情况：当生成vue实例后，当再次给数据赋值时，有时候并不会自动更新到视图上去；

当我们去看vue文档的时候，会发现有这么一句话：如果在实例创建之后添加新的属性到实例上，它不会触发视图更新。

so，网上查阅资料和文档后得知可以使用 Vue.$set

下边是我写过的一个关于图片不同显示代码示例：

前人栽树，后人乘凉。多谢各位大牛的技术文档，让我可以站在巨人的肩膀上眺望远方！(不过在windows上走流程有各种坑)下边是我结合制作自己博客写的总结：（非常建议Windows下用hexo环境创建博客，jekyll下问题多多，坑坑多多）
本人使用Jekyll搭建的博客地址:https://algate.github.io/

修改几个个地方（陆续记录），看起来不起眼，其实很重要的。我也是花了很长时间调试才出来的；

修改配置文件，必须 cnpm 重新启动项目

• babel-polyfill

  main.js 即vue项目的入口文件，开头部分需要引入

  import "babel-polyfill"
  

先安装nodejs，node -v测试，可能需要配置环境变量；

以下 npm 都可以用 cnpm 命令来提高安装效率，需要安装cnpm

npm install vue-cli -g

这个无用多说，全局安装vue-cli。

1.export与export default均可用于导出常量、函数、文件、模块等

2.你可以在其它文件或模块中通过import+(常量 | 函数 | 文件 | 模块)名的方式，将其导入，以便能够对其进行使用

3.在一个文件或模块中，export、import可以有多个，export default仅有一个

4.通过export方式导出，在导入时要加{ }，export default则不需要

效果如下图流程

one.自己定义弹层(弹层实现不包括别的样式和事件-非UI框架实现思路)

通过父组件页面的flag来显示和隐藏弹层

1xx消息
这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送1xx响应。 这些状态码代表的响应都是信息性的，标示客户应该采取的其他行动。
100 Continue
客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。
101 Switching Protocols
服务器已经理解了客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade消息头中定义的那些协议。
只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。
102 Processing
由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

资源教程

1. 
   

   综合类

   
   
   
   
   • 前端知识体系
   
   
   • 前端知识结构
   
   
   • Web前端开发大系概览
   
   
   • Web前端开发大系概览-中文版
   
   
   • Web Front-end Stack v2.2
   
   
   • 免费的编程中文书籍索引
   
   
   • 前端书籍
   
   
   • 前端免费书籍大全
   
   
   • 前端知识体系
   
   

雅虎前端优化的35条军规：可以大量借鉴使用
阅读目录

内容部分
css部分
js部分
javascript, css
图片
cookie
移动端
服务器

目前，通行的Javascript模块规范共有两种：CommonJS和AMD。我主要介绍AMD，但是要先从CommonJS讲起。

服务器端模块以后，很自然地，大家就想要客户端模块。而且最好两者能够兼容，一个模块不用修改，在服务器和浏览器都可以运行。
但是，由于一个重大的局限，使得CommonJS规范不适用于浏览器环境。

这对服务器端不是一个问题，因为所有的模块都存放在本地硬盘，可以同步加载完成，等待时间就是硬盘的读取时间。但是，对于浏览器，这却是一个大问题，因为模块都放在服务器端，等待时间取决于网速的快慢，可能要等很长时间，浏览器处于”假死”状态。

话不多说，直接开始

1.安装Java

要使用tomcat，首先要安装Java，并且配置Java环境，这里不介绍如何安装，重点强调安装过程中遇到的问题

1

tomcat.bat

progress元素属于HTML5家族，指进度条。IE10+以及其他靠谱浏览器都支持。如下简单code:

<progress>o(︶︿︶)o</progress>

不同浏览器下的效果不尽相同,样式控制有巨大差异，详细自己可以写个html的progress的标签看看不同浏览器下的效果，哎，那叫一个惨不忍睹！

原文地址前端架构
前端架构
总述

在互联网应用越来越大，越来越复杂的今天，我们不可避免的需要工具来管理我们的前端代码。 替代以前的一个巨大的脚本文件，我们希望可以将文件写入不同的文件模块。并且希望代码可以 重用，可以简单的引用和添加各种各样的依赖到我们的项目（ 无论是菜单一样的 UI 组件还是 一个类似 jQuery 的 DOM 操作库）。不止是 JavaScript 我们希望可以用这种方式来组织， 他应该也包含 CSS，HTML 模板，字体，图片和其他静态文件。
为什么前端需要模块化开发

随着互联网应用越来越大，前端的开发也越来越复杂。如果还维持在以往以页面为单位的开发， 会导致很多问题，类似依赖管理，命名冲突等棘手的问题。

命名冲突是最常见的问题：

1
2
3
4
5
6
7
8

// util.js
function log(message) {

}
// logger.js
function log(message) {

}

原文地址：浏览器渲染原理及解剖浏览器内部工作原理

[info]很多人对浏览器的渲染原理和浏览器内容工作原理混淆。其实这是两个概念，这篇文章给了一个很全面的解释。

1、浏览器渲染原理
　　简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。先来大致了解一下浏览器都是怎么工作的：
　　1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
　　2. 浏览器开始载入html代码，发现head标签内有一个link标签引用外部CSS文件；
　　3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
　　4. 浏览器继续载入html中body部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
　　5. 浏览器在代码中发现一个img标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
　　6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
　　7. 浏览器发现了一个包含一行Javascript代码的script标签，赶快运行它；
　　8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个