项目开发之——前端

小坏坏

ajax

  前后端的分离是经历了很长一段的历史的(详细看此博客),最初的前端页面是由后端加入数据渲染完毕后再发送至前端,而前端的一些数据的变动带来的也经常是整个页面的跳转和刷新,在代码的编写和页面的加载上都带来了极大的不便;

  直到后来有了ajaxAsynchronous JavaScript And XML)这一理念,这一问题才得以缓解,后来这一理念被发扬光大,使得前后端的交互只剩下最基础的业务逻辑相关的——数据(可以看出,数据才是一个工程的灵魂);

  示例代码

<!DOCTYPE html>
<html>
<body>
<div id="demo">
<h1>XMLHttpRequest 对象</h1>
<button type="button" onclick="loadDoc()">修改内容</button>
</div>
<script>
function loadDoc() {
  var xhttp = new XMLHttpRequest();
  xhttp.onreadystatechange = function() {
    if (this.readyState == 4 && this.status == 200) {//请求成功后响应
      document.getElementById("demo").innerHTML =
      this.responseText;
    }
  };
  xhttp.open("GET", "/demo/js/ajax_info.txt", true);// 请求地址
  xhttp.send();
}
</script>
</body>
</html>

  尽管已步入前后端分离时代,模板后台渲染这一理念仍然在广泛使用,因为若前端页面加载逻辑较为复杂,客户端算力或带宽不足,便可能出现首屏白屏的问题,通常这种情况下,在后端将加入了数据渲染好的页面直接发送来是一种高效的解决方案;此文只以前后端分离的理念讲解

webpack

  在开始之前先介绍下webpack的开发方式,将commonJS或es6层层引用的代码,打包压缩成一两个浏览器可以准确执行但人类看不懂的es5代码;这种开发方式的优势在于

  1. 可以更好的模块化前端的开发,并方便了对外部依赖的引用,打破传统的<script>式低效低可读性的引用,可以像开发nodejs后端一样四处调用好心人写的轮子(除了一些涉及到本地文件读取的轮子,不过这些只能用于后端,前端一般也用不上)
  2. 代码的自动化的丑化(uglify)/压缩/编译,最大限度将本项目以及引用的外部项目压缩成所有浏览器能够识别的es5标准乱码,可加快向前端发送的速度以及保密一些关键的代码逻辑
  3. 若担心代码被丑化后影响前端的调试工作,还可以通过特定指令生成乱码的map文件,在乱码中还原开发时的代码,并一样高效调试;

常用前端框架

  前端有着许多优秀的框架,例如广为人知的jQuery,最初附带了ajax理念的框架,同时集成了前端所需要的几乎全部的功能,只需要简短的几行<script>引入,即可将一个静态html页面写的风生水起;

  但随着目前前端的发展,前端的开发所需要的已经不仅仅是零碎的方法库了,而是一个更高层面上页面的架构、模型、状态等的管理,但这并不代表jQuery已经退出了历史舞台,jQuery仍然是前端强大的调用库,只是在仅仅需要其中的几个功能时要谨慎引入,因为与专门完成那几个功能的框架相比,jQuery已经属于重量级框架了,引用它会使客户端加载过多不必要的资源

老夫写代码就用jQuery

  一个优秀的前端框架,应能做到

  1. 首先提供一种高可读性的开发风格或开发方式(即可能易于开发易于维护)
  2. 其中的理念或api应尽量贴合大部分开发者的开发观念(即尽可能易于理解和学习)
  3. 应有着尽可能高的运行效率,体积小、运行快
  4. 应有着良好的社区生态,遇到bug有地方问,需要轮子一找一大把(总的来说就是用的人多)

  在开发开始前,前端开发框架的选择也是一个重要环节,要把握好每个框架的优势和劣势,来根据自己项目的特点做选择、制定开发计划(虽然各个框架间有办法兼容,但是保持一种框架更有利于项目的维护),此处仅介绍几个目前广为人知的开发框架

React

特点

  • 开发上:可以用纯原生js的语法来管理整个前端页面的逻辑,有着all-in-js的高自由度开发理念;
  • 运行上:采用虚拟dom的形式,即脱离浏览器本身的dom,使用react定义dom来管理组件状态,虽然还是可以采用原生dom来解决问题,但是react有意让开发者完全抛弃原生dom的理念;

代码示例

  贴出部分示例,详细见官方文档

class HelloMessage extends React.Component {
  render() {
    return (
      <div>
        Hello {this.props.name}
      </div>
    );
  }
}

ReactDOM.render( // 此为react的虚拟dom与真实dom对接的唯一入口
  <HelloMessage name="Taylor" />,
  document.getElementById('hello-example')
);

  此为jsx文件,可以看出,react以自己的格式,以自己的标准重定义出了html全部的一整套标准,包含了html种全部的内容,又很好的贴合了js的语法;

  问题又来了,既然react有了一套自己的虚拟dom,那么岂不是更改了ReactDOM.render,就可以将react移植到web以外的平台了?是的,详见react-nativetaro的react支持,即通过react,便可以开发app,小程序,以及桌面应用(使用electron,但是与虚拟dom无关)

总体评估

  • 开发和维护:react使用all-in-js的理念,开发风格过于自由,既是优势,也是不足,优势在于随意发挥,不足在于风格过于自由以至于到目前为止没有一种公认的稳定的代码架构,一千个react开发者,一千种风格,一个问题往往有多种解决方案,难以抉择
  • 学习成本:只要懂js,就可以进行react的开发,但是想要高效的开发,需要深入理解许多衍生概念,学习react全家桶(react-domreduxmobxreact-routerredux-saga等),当然只了解一部分也不影响项目的开发,可以都了解一下,按需使用
  • 运行效率:压缩后大小可以忽略不计,由facebook掌舵开发的框架,效率自然是不用担心的;一个项目结构的好坏对页面的运行速度影响才是最大的
  • 生态:react拥有着全世界最高的使用人数,但是在国内确远落后于vue,所以只要懂点英文,轮子和bug排除这块是完全不用担心的

Vue

特点

  • 开发上:使用原生html模板来进行开发,并在其中提供一些api来增强页面的管理;但同时又可以使用react类似的jsx语法来编写页面
  • 运行上:在vue1.x后,vue2、3均使用虚拟dom形式,所以,vue也可以很好的用来跨平台的开发,例如国内的强大的uni-app框架,taro的vue支持

代码示例

  贴出部分示例,详细见官方文档

<div id="app-2">
  <span v-bind:title="message"><!--此处 v-bind 即为vue提供的api之一,意为将span的原生属性title,绑定在message这个data上-->
    鼠标悬停几秒钟查看此处动态绑定的提示信息!
  </span>
</div>
<script>
var app2 = new Vue({
  el: '#app-2',
  data: {
    message: '页面加载于 ' + new Date().toLocaleString()
  }
})
</script>

  可以看出,尽管使用虚拟dom管理页面,但是开发风格还是比较贴近原生的网页开发,非常的简单易上手

总体评估

  • 开发和维护:vue使用部分自定义api来方便常用的开发需求,对于一些关键问题vue已经提供了很好的解决方案,代码架构也较为稳定、统一,对中小型的项目有着快速的开发周期;但是自定义api既是优势,也是缺陷,在长期大型项目中会有所体现,会导致出现一些编辑器无法理解的语句,无法提供准确的提示,会导致debug困难
  • 学习成本:只要懂原生网页开发,即可上手,理解少数概念即可,不需要学习像react那样繁琐的全家桶
  • 运行效率:压缩后的大小同样可以忽略,运行效率也是不需要担心的
  • 生态:国际范围内可能人数远少于react,国内下载量远超react,毕竟作者是中国人——尤雨溪,国内用户多,这也就使得国内vue相关的轮子众多,也就使得无论是vue的官方文档还是vue的插件还是vue相关的bug问答,都是不缺中文的,这也就极大的降低了国内的开发门槛

Angular

特点

  • 开发上:使用纯粹的模板式页面开发,以java(确定不是js)的语法风格进行网页的开发(面向对象、依赖注入等)
  • 运行上:使用Incremental DOM而非虚拟dom,相较于虚拟dom来说更加节省内存,但在代码模式上,angular依然抵制直接操作原生dom;正是如此,angular同样可用于跨平台开发,但是小程序这部分有所缺失

代码示例

  贴出部分示例,详细见官方文档

/*此为ts语法编写*/
import { Component, OnInit } from '@angular/core';
import { Hero } from '../hero';
import { HEROES } from '../mock-heroes';

@Component({
  selector: 'app-heroes',
  templateUrl: './heroes.component.html',
  styleUrls: ['./heroes.component.css']
})

export class HeroesComponent implements OnInit {

  heroes = HEROES;//为hero列表数据,
  selectedHero?: Hero;//当前选中的hero

  constructor() { }

  ngOnInit() { }

  onSelect(hero: Hero): void {
    this.selectedHero = hero;
  }
}
<h2>My Heroes</h2>
<ul class="heroes">
  <li *ngFor="let hero of heroes"
    [class.selected]="hero === selectedHero"
    (click)="onSelect(hero)">
    <span class="badge">{{hero.id}}</span> {{hero.name}}
  </li>
</ul>
<div *ngIf="selectedHero">
  <h2>{{selectedHero.name | uppercase}} Details</h2>
  <div><span>id: </span>{{selectedHero.id}}</div>
  <div>
    <label for="hero-name">Hero name: </label>
    <input id="hero-name" [(ngModel)]="selectedHero.name" placeholder="name">
  </div>
</div>

  可以看出,ng框架有着更浓厚的“框架味”,或者说“模板味”,将大部分页面逻辑封装成api,使用起来未免少了些灵活性

总体评估

PS:由于国内angular使用太少,只对angular略有耳闻,并未深入了解,内容均源自查阅大量博客、文档和知乎

  • 开发和维护:angular由于其语言风格较受后端开发者的欢迎;angular可以说是统一了前端的代码风格,而且由于TS的语法,即使是新手,开发出来的内容也是规规矩矩的;但是严格的标准同时也限制了一定的angular的开发自由,当然,大而全和小而美二者都有各自的优缺点,评判标准在每位开发者自己的心中;这同时也使得angular开发一些小项目如同大炮打苍蝇,杀鸡用牛刀一般

img

  • 学习成本:据资深ng开发者描述,ng学习曲线陡峭到令人发指的地步,此时应祭出这张图,angular的学习曲线.jpg

213419-20160813161202968-1681549992.png

  • 运行效率:作为谷歌团队开发的项目,angular有着优秀的运行效率,这点是毋庸置疑的,早期的ng有着体积臃肿的诟病,这个问题也已经在后期的版本中得到了解决
  • 生态:国际乃至国内相较于react和vue都有着极少的使用人数,少到甚至难以搜索到近两年对此框架评价的文章,但这并不代表这个框架的思想是落后的,不少的开发者对ng都有着较好的开发体验,高自由的开发风格最终都将走向一个统一的标准,正如天下大势,分久必合一般,而ng会不会是那个标准,有待进一步的观望

总结

  从以上介绍中不难看出,vue是取react和angular二者特点所诞生的中庸之道,没有绝对的自由,但又给予开发者自由的渠道;而尤雨溪本人起初也是受angular的启发,创造了vue这一框架;三者的互相比较论战也可以上演一场精彩激烈的宫斗戏了;总之要客观的看待开发框架,框架只是一种开发工具,不是pvp论战的工具,再者不要过分纠结三门框架学习哪个,都去学习一点加深了解并不是坏事,最后只有深入了解了,才能知道每个框架的优缺点以及这个项目真正需要使用的是哪个框架

  省流助手:

  • 英文好用react
  • 中小型交互简单短期维护项目用vue,长线维护交互复杂大项目用react
  • 水平不够不要轻易碰angular

附图:三者下载量比较
Vue、React 和 Angular:该选择哪个框架?

阅读 159
13 声望
1 粉丝
0 条评论
你知道吗?

13 声望
1 粉丝
文章目录
宣传栏