介绍个前端框架，不是Bootstrap！ Bootstrap已经是公认的主流CSS框架了，我们还需要了解其他的CSS框架么？Bootstrap的主流地位当然是没有争议的Grid布局及其原理（media query）也依然是面试的必考题目没有变，相比之下今天要讲的materializecss技术点并不比Bootstrap复杂，但是，简单地说，好看。 Material Design(原质化设计)由 Google 创建和设计，Material Design 是一种设计语言，结合成功设计的经典原理以及创新和技术。 Google 的目标是开发一个系统的设计，允许在任何平台上的所有产品有统一的用户体验。 实际的效果虽前面讲的可能复杂了，抛开文字看看效果，这就是Material Design的效果 materializecss代码举例举个多选的例子吧 这里就只贴一下那个多选框需要的代码 <select multiple>      <option value="" disabled selected>Choose your option</option>      <option value="1">Option 1</option>      <option value="2">Option 2</option>      <option value="3">Option 3</option>    </select> 它实现的机制和Bootstrap的js组件一样（单从这个多选框它更像select2），需要引入一个JS，然后自动绑定这个类的select，隐藏它并创建假的更好看的一组标签来实现用户交互功能，在用户交互之后更新这个select的值。 react-materialize好看归好看的，materializecss可是基于JQuery的Dom操作实现的这种与众不同的体验，问题是现在谁还用JQuery操作Dom呀，自己要集成它到React中一定要注意React Virtual Dom对Dom的管理和materializecss中JQuery的Dom操作之间的冲突。所以我们更倾向于寻求类似react-bootstrap这种封装方案，没错就这个react-materialize（https://github.com/react-materialize/react-materialize）了 materializecss并没有很神奇的高科技，甚至可以说使用JQuery操作Dom有点过时，但这并不能掩盖它的优点，更好看，更好的交互体验。前端的外延有几个大块：后端-如何更好地实现业务；项目管理-如何按时按预期交付；测试-如何保证交付质量；产品交互及美术-如何保证用户体验。就是最后这一点，美感对前端来讲很重要。 本文来源于：介绍个前端框架，不是Bootstrap！-变化吧门户 特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。

提起前端框架你会想到什么？第一时间是不是想到了 Angular，jQuery 和 React，当然前端开发人员对这些框架都很熟悉。那么前端框架到底是什么？ 框架是提供一套完整的解决方案，按照规定好的代码的结构来做编排，同时前端功能越来越强大而产生的前端框架。像开发 web 产品用框架就是很有必要的。 用过前端框架的人都知道，框架的更新迭代是很快的。 几年前还是在用 jQuery 操作元素，然而近几年 react，Vue 就开始占领前端市场了。所有人都知道用 jQuery 只会造出不可维护的代码，而做前端需要的是动态的，可塑性强的代码。而新的框架和库似乎一直都在不停地发布。 每隔六个月，我们就会看到一个全新的框架声称自己已彻底改变了 UI 的发展，然后成千上万的开发者在自己的项目中使用它们，写门户，分享使用心得，日复一日，然后又出现一个更新的（甚至更革命性的）框架来取代上一个的“王位”。 通过 Stack Overflow 的调查，先看一些相对来说用户群体较大的框架。 这里只是显示部分用户群体较大的框架，事实上，也有较小的框架在争夺主导地位。我们可以从下面的图片看到这些 JavaScript 框架生命周期的残酷程度。 JavaScript 框架的使用似乎有两个主要阶段。随着框架越来越受欢迎，它们似乎都有一个快速上升的阶段，然后又因为开发者采用更新的技术，它们的上升开始变得没那么快而且总体是稳步下降。这些框架的生命周期只有几年。 Javascript 在 2017 年发表了一篇报告，其中可以看出前端三巨头 React，Angular 和 Vue 框架都呈爆炸式的增长，Facebook 发布的 React 始终在“王位上”，Angular 算是资质比较老的框架，Vue 更像是一匹黑马。 npm 发布的 2017 JavaScript 框架报告显示，相对于所有 npm 中的包下载量，React 的使用量增长了 500％。移动、桌面应用程序和 Web 开发都在使用 React。对 React 而言，作为它的性能改进直接替代品Preact 也有 145％ 的增长，React Native 的出现也巩固了 React 的地位。但是谁也不能保证 React 就是未来前端框架的主流，毕竟时间沉淀下去了这么多的框架。 Angular 的社区所占的优势是很大的，但是从 Angular 1 到 Angular2 + 的迁移是一件困难的事。而后起之秀 Vue 则是以 397.4% 的速度增长，如果按目前的趋势继续下去的话，Vue 或将会在 2018 年底或 2019 年初取代 Angular ，成为使用率第二大的框架。 不仅如此，在 JSX 可以用一种更优雅的方式来写 HTML 时，npm 可以用一种更快捷的方式下载模板代替 Bower，Webpack 可以以更灵活的方式代替 Browserify 管理模板时，前端框架的变化都已经见怪不怪 了。不过显然做 Web 开发的，喜欢先把事情搞复杂，然后回归到最朴素的状态。每年都是这么搞的。你就看着吧，过不了两年，说不定就可以在网页上写汇编了。 所以不管框架如何更新换代，技术都是为开发者服务的，在 web 开发大热的潮流下，你始终都要时刻储备着能量，学习新技术。然而今年第一期开班的前端开发工程师，现在已经零基础开班了，这期新课程，将给你带来满满的前端技术干货。如果你也想学习这个课程，马上扫描下面的二维码开始了解课程，开始学习吧！ 点击阅读原文，了解前端开发工程师课程学习详情 本文来源于：前端框架更新迭代那么快，我们该如何选择？-变化吧门户 特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。

在2013年，一位技术人员Sebastian Porto在他的门户上写过一篇文章比较Ember、Backbone、Angular等几种前端语言，文章写的比较详细，在今年8月份，技术人员Jens Neuhaus在Medium上写了一篇文章，比较React、Angular、Vue，同样写的比较详细，文章被认可度很高，我做了一些整理，针对这5种前端框架，客观的做出比较，然后根据实际谈谈对前端开发框架的选择，文章中的一部分数据将会引用上述两位技术人员的内容。 先贴出比较的最终结果，然后逐项做一些解释「这是在没有权重的情况，根据个人需要可以为每项设置权重，然后选择对应框架，见后面」。 Lifecycle Lifecycle主要从以下几个方面的比较， 1.历史、团队、背景 在这方面，无疑React和Angular会因为Facebook和Google的背景被另眼看待，而其它三个框架都是团队式开发维护，特别是Vue，开发人员比较少，一些有长久开发打算的项目，还是比较关注要框架背景的，一旦所选用的框架终止了技术支持，那对于项目来说将是灾难性的。 Ember团队被成为是一群很聪明的人，为什么这么说，看Ember的设计理念，约定优于配置，整个框架中处处都体现了这点 2.社区活跃程度 React和Vue都是后起之秀，特别是Vue框架，在2015年之后在Github上的受欢迎程度，几乎呈直线上升趋势，如上图所示。 值得注意的是，截止目前，Backbone最后一次commit是在今年的8月份，而最后一个release是在去年的4月份，Backbone的代码维护目前看不是很活跃了 3.语言 Angular使用了TypeScript，实际上TypeScript已经不是单纯的Javascript语言了，那么就有额外的学习成本，以及后期是否官方会长久维护的问题，这也是一个风险。 5个框架的license都是MIT，也就是说，对绝大多的项目来说，都可以放心去使用。 Features 这一方面是尤其重要的，大致分为以下， 1.Routing 路由，并没有什么好说的，这也是做为框架最基础要考虑的，这5种框架都做的很好。 2.View bindings 模版，对于模版的渲染方式，可能是仁者见仁，智者见智的问题，比如，我比较喜欢代码和设计完全分离的方式，而Component的设计就很难做到代码设计完全分离，Angular是Html中嵌入Javascript，而React是Javascript中嵌入Html，孰优孰劣完全在个人，不同的设计理念都与开发者的密切相关，比如React这种设计就充分体现了Facebook公司是以工程师为驱动的，对于full-stack的工程师来说，是比较喜欢React框架的。 我不但不喜欢代码和设计混在一起，而且也比较反感Angular的设计方式，DOM中加入了太多东西，有悖Web标准 3.Data bindings 数据绑定方面，Angular、Ember采用的是双向数据绑定，React采用的是单向数据绑定，而Vue是可以进行配置的，既可以选择单向数据绑定，也可以选择双向数据绑定，Backbone原生是不支持数据绑定的，这就意味着如果你使用Backbone框架，数据的处理，就需要手动绑定了，有人认为Backbone不是一个框架，而是一个库，很大程度上在Backbone的项目中有太多的数据手动渲染的代码。 数据绑定也是一把双刃剑，不见得双向数据绑定就是好事，有的时候会给你的开发带来额外的麻烦 4.Components React、Vue、Angular本身就是基于组件形式设计的框架，Ember在这方面做的也比较好。 组件化也是见仁见智的问题，程序的设计很难做到兼顾，可复用会提高开发效率、保持一致性，但同时会降低灵活性 在Feature这方面，总体看Angular、React、Vue优势很明显，这也是为什么这两年来，这三种框架技术大受欢迎的原因。 Flexibility 这方面Backbone是做的最好的，你可以找到很多关于Backbone的扩展应用，还是上面的道理，如果框架已经为开发者做了很多工作，那么就要添加很多约束，自然留给开发者的自由就少了很多。 Learning curve and documentation 总体上看，Angular、React都是比较重的框架，而且比较独立，学习上需要付出一些成本，这5种框架中，我觉得Ember这点做的是最好的，可以通过自带的命令generate工程，Backbone可以通过yoman等工具generate工程，Ember的Guide做的非常详细，新手几乎可以一天之内就能创建应用。 这里说个小故事，某公司一个几千万的客户订单，最终项目出了问题，合同终止，技术方面出现比较严重的问题，就是前端框架的选择，采用了React框架，而实际的开发团队比较年轻，经验不足，没有办法在短期内上手React，要知道React的学习成本很高，不同时精通前端的若干技术是很难做到应用自如的。 Developer productivity 开发效率方面，Ember首屈一指，一旦你熟悉了Ember的一些约定，按照约定做事情就可以了，你想想，连模版的命名都不用你操心了，多省事。 Ecosystem 生态系统方面，Backbone比较好，可以找到很多Backbone开发扩展，其次是Ember，Ember自己建立了扩展的开发规则，而Angular、Vue、React相对比较独立，有雄心的开发框架希望自己搞定一切，会认为自己做的才是最好的。 Performance 性能上，Vue的表现最好，React和Vue都采用了Virtual DOM的设计，这可能是提高性能的一个重要因素，看Benchmark测试结果如下 这里并没有找到Backbone的测试 上面7项是从客观角度做的比较，框架的选择还要根据自身的需要，比如你的项目会更在意那些方面，你喜欢灵活性，喜欢使用生态中现成的扩展，那么你可以在Flexibility、Ecosystem两项中增加权重，然后再进一步比较。 当然还要根据团队的实际情况，比如你的团队中都是full-stack工程师，前端技术样样精通，那么React是个比较好的选择。 对于一个实际项目，如果项目偏大，我更愿意把按照如下设置权重， 如果是一个精小的产品，需要精雕细刻，Ember则是非常好的选择。 本文来源于：五种前端开发框架比较-变化吧门户 特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。

又到了每周分享的时间啦，这周给大家带来的是技术分享，分享的主题是《云窗前端框架升级方案实践以及可视化查询的设计与实现》，下面让我们一起来了解一下我们是怎么实现云窗前端框架升级和可视化查询的吧。 整个分享分为二个部分，第一部分是云窗前端框架升级方案的选择。第二部分是方案升级的实践案例。 页面部分升级——可视化查询项目 部分页面全量升级——知识库项目 云窗原版的前端使用了angularjs的前端框架，前端发展这么块，云窗项目已经维护了3年了，需要跟着时代的潮流，使用使用新的技术了。 如何和新的技术结合？选择什么技术呢？ 在技术选型上，我们选择了在写法上比较相近的vue。 相比与原来的angularjs，vue在检查机制，压缩大小，相关生态...都随着这几年的发展越来越完善。 而我们原先的angularjs项目，鉴于整个项目内容太大，重构成本大，成效低。现在项目也在开发过程中注意性能优化，整体使用效果还能满足需求。 我们的更新方案为： 旧项目angularjs继续维护，新功能使用vue开发。 这个目标需要真正的实践方案支持： 1. ngvue 2. iframe 1. ngvue ngvue是一个angularjs的插件，可以让我们在angularjs的项目里使用vue。 它是如何做到的呢？ ngvue将vue环境封装成了一个angularjs的指令。当我们在angularjs的环境里调用这个指令时，这个指令内部的环境都变成vue的环境。可以在这个环境里，使用vue的相关特性。 ngvue github地址：https://github.com/ngVue/ngVue 下面就是可视化查询使用ngvue的效果，红框内部就是vue的环境，而访问的整个页面都是angularjs的环境。 下来让我们在这个vue环境里做点事情。 实现一个可视化查询。 什么是可视化查询呢？ 有一些同学，并不会写SQL，但是他有查数的需求，作为一个完善的大数据解决方案，当然要有可视化的查询解决方案。 但是前端怎么实现呢？ 整个功能框架分为三个部分。 页面功能层 ——>  交互存储数据结构 ——> 接口层（输出SQL语句） 页面功能层（画布功能、SQL语句功能实现、实时SQL展示三个模块） 接口层的SQL语句的后端在支持SQL已经实现了，现在先设计交互存储的数据结构。 如何用一个数据结构存储SQL语句？ SQL语句的基础模块：字段、表、条件 可复用的条件规则实现了a=b and c=d 的效果。在生成规则的时候也可以用递归的方法，访问到每一个数据。 将这个结构存储在vuex里。 设计完存储结构，就到了真正实现可视化查询页面效果的时刻了！！！ 我们要实现什么样的效果呢？ 进入到可视化查询功能后，筛选数据库，找到需要查询的表，通过拖拽或者双击，在我们的画布上生成这个表的节点。 节点的表头支持全选、别名、删除。 节点支持拖拽、放大、缩放。 节点的每个字段支持勾选、右键、重名、计算规则（summaxmin...） 右键支持where、group by、order by。 节点间支持连线，生成join条件。 ....... 功能这么多，实现分4步： 1.angularjs和vue通信 2.画布功能 3.SQL功能实现 4.动态数据组装 1.angularjs和vue通信 ngvue提供了v-props的属性可以实现通信。 也可以把相关数据绑定在window上绕过angularjs。 2.可视化 一个可视化功能可以分为三个部分：画布、节点、连线。 在svg的画布里画一个支持vue双向绑定的dom请使用vue的extend方法。 chrome的forignObject内部不支持滚动条，请在forignObject上写。 3.SQL实现 from和join的效果展示效果是node之间的连线，连线多了就成了一个无向图。如何处理无向图，将join的条件正常存储？ 我们的方案是对每一个node进行编号，将join的条件存储在两个表编号大的节点上。保证条件的唯一性。 where条件的处理： 针对where条件支持字段和值，无法区分字段和值的特征。对字段进行处理，用@001@aaa@002@进行标记，有这个标记的是字段。 从vuex的数据结构，计算成SQL。 2. iframe 知识库是一个完全用vue开发的单页应用。 使用iframe内嵌到云窗的angularjs的环境，保留云窗的导航。 使用html5的postMessage进行通信。 使用URL存储vue路径，保证后退、重新访问更新正常。 上面就是我们之前尝试部分升级前端框架的方案和实践，希望对你们的框架升级和产品设计有启发。在开发过程中遇到了很多问题，在解决过程中，也提升了自己的开发和设计能力，体验了科技的升级。每一个前端人为了技术的发展都在努力创造更加通用，更简单、好用的服务产品，虽然前端的历史，很短，快速发展也是这几年。是历史的机遇，也是我们每个人的机遇，在中美贸易战的今天，希望我们每一个人都努力，完成祖国的伟大复兴，早日实现中国梦。谢谢大家。 本文来源于：云窗前端框架升级方案实践以及可视化查询的设计与实现-变化吧门户 特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。

点击标题下「蓝色微信名」可快速关注，涨知识，好工作等你来！ 拼图响应式前端框架视频教程 素材及高清视频下载：http://pan.baidu.com/s/1skqHDDF  注：该教程由视频作者邱嵩松录制提供，感谢邱嵩松的辛勤付出。 以上文章内容来自，拼图响应式前端CSS框架作者，大火兔原创，转载请注明出处或帮忙分享给身边的前端、开发、UI并邀请Ta们关注，大火兔会非常感谢您，祝各位心想事成。多关注拼图动态，分享转发是对拼图最好的支持。 大家都在关注 ①资源：拼图相册插件预览及源码获取途径 ②资源：分享一套基于拼图响应式CSS框架开发的门户模板                           长按二维码，可以关注我们哟提供腾讯、百度、阿里内推职位并提供内部试题，不定期放送各类原创后台模版、企业模版、Js插件、微信 小程序源码等资源，后台、前端开发人员都会关注的公众号！ 目前100000+人已关注加入我们                 每日脑洞大开早晨醒来，每个人都要做的第一件事是什么？ 关注拼图前端框架（pintuercss）回复 Q505 获取答案，不区分大小写 本文来源于：第1节 拼图响应式前端框架的效果介绍及获取方式-变化吧门户 特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。

ArthurSlog SLog-6 Year·1 Guangzhou·China July 13th 2018 微信扫描二维码，关注我的公众号 时间 时间 时间 每一份有限的时间里 都饱含无限的价值 需要非常珍惜 开发环境MacOS(High Sierra 10.13.5) 需要的信息： brew官方手册，一款MacOS工具，具体内容请移步官方手册 npm官方手册，一刻nodejs代码包管理工具，具体内容请移步官方手册 vue官方安装手册，前端框架 chrome浏览器devtools扩展，用于调试Vue.js应用程序，下一篇进行详细介绍和应用，本篇先自己花一分钟做个了解 vue快速使用手册，可以先花20分钟的时间写一写感受一下vue的写法 执行方案 切换至桌面路径 cd ~/Desktop 创建一个新文件夹 mkdir node_vue_learningload 切换至新建的文件夹路径下 cd node_vue_learningload 使用npm指令初始化nodejs项目环境，一路回车，完成初始化 npm init 安装 koa 和 kao-static sudo npm install koa koa-static 需要管理员权限，输入密码 在当前路径下创建 index.js 和 index.html 这两个文件 index.js constserve = require('koa-static');constKoa = require('koa');constapp = newKoa();// $ GET /package.jsonapp.use(serve('.')); app.listen(3000);console.log('listening on port 3000'); index.html <!DOCTYPE html><html>    <head>    <metacharset="utf-8">    <!-- 开发环境版本，包含了有帮助的命令行警告 -->    <scriptsrc="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>    <title>ArthurSlog</title>    </head>    <body>        <div id="app">{{ message }}</div>        <script>            new Vue({...

当我2015年开始做理杏仁的时候，当时前端框架选择了如日中天的angular，事实证明这是一款极为优秀的前端框架，让我们早期的开发带来了极大的便利。时隔三年多后，我们依旧在使用angular1.5.8的版本，成为了我们一个不得不考虑的瓶颈，要知道现在的angular已经成快到版本8.0了。 可以在经过一系列调研后，越发觉得angular不招人喜爱，一个闭合的生态系统，几乎无所不能，从commander到compile，从typescript到vs editor，从http request模块到ui router，从component到service……这几乎是一个让人抓狂的举措，因为他给你设定了你所有可能需要的解决方案，让大量优秀的三方开发者缺乏合适的生存空间，也让应用层的开发者失去了选择。 要知道我更喜欢es6，其灵活性正式我们快速开发的基础，也是理杏仁这种大量泛型存在而得以灵活展示的基础，而typescript虽然带来了很多便利，也给大型项目开发者带来了规范，却让我看到的像是另一款c#或者java，一种腐朽的气味挥之不去；做http request，我更喜欢的是axios，后者足够的灵活；做router，有更好的ui-router，后者不仅灵活还功能异常强大；做打包，webpack已经足够优秀，而angular却说“NO，我们已经为了考虑新的方案，并且还可以预编译”…… 这让我不得不回到早期我甚至不太喜欢的react，严格意义上讲他还不能称之为框架，而只能称之为package，他继承了js原本的灵活性，而因为react的开放，又仅仅focus在component层面，其大量的衍生开发项目让人耳目一新，随便一个js-in-css的github上关注度在3000以上的项目，都达到十款之多，其社区之强大，也让人不得不感叹这个开源世界的人们的热情。这里也不得不提及react的一个衍生项目antd，阿里出品的这一款ui components，确实难能可贵的优秀，这些年也确实看到了国内开源项目的越发强大，部分企业也愿意投钱在这类长期项目上。 笔者这里谈谈一点个人互联网的认识，大的生态系统往往是由优秀的头脑共同建立的，其主要特点是开放和包容。这也是linux系统在开源后生生不息的内在力量，也是andorid系统得以快速发展的根本缘由，因为无数的优秀头脑从世界各地聚集起来，他们共同工作，甚至不求回报的在一起推动项目本身的发展。而我个人确实是不太喜欢封闭式系统，包括iOS，以及腾讯的所作所为，他们极尽可能地将所有可以触及的功能纳入其系统本身，而不遵循于一套已有的公共标准模式。虽然对于不喜欢做选择的人们提供了一个懒人模式，但是却很难让大家利益一致，更多的是屈从于平台本身的利益。 理杏仁是一个以技术和产品为核心的公司，决定在这个时间点彻底的升级前端框架，以保证更长远的发展，我们决定选择react，从改动上而言，类似于我们要重写绝大部分整个网站的前端代码。后期开发新功能的速度会慢下来，还望用户海涵。 本文来源于：理杏仁前端技术框架升级-变化吧门户 特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。

 百度智能运维（Noah）产品前端技术方向负责人，在运维数据可视化、中后台前端解决方案等方向上，有着丰富的实践经验。  干货概览 众所周知，前端有三大主流框架：Vue、React、Angular，这些前端框架可以帮助我们快速搭建项目，但是我们在实际项目中往往还需要投入很大精力去使用其他代码库与应用作为补充支持（如：需要一些基础的 UI 组件库，需要 HTTP 请求库等），另外，在实际应用到不同领域时，会有很多重复性的开发工作。 正因为上述原因，我们构建了自己的智能运维前端框架 —— NoahV（现已开源），它可以结合运维业务场景，提供常用的运维组件库及工具，比如：表格、表单、趋势图、数据请求、数据模拟等等。 除了上面提到的一些可视化组件，NoahV 还特别提供了布局应用，我们的布局应用除了左-右，上-下布局，还有运维领域中经典的左侧服务树与右侧应用的交互布局。 此外，我们还把数据请求、数据交互与组件结合，并用配置化的开发模式来大幅度降低二次开发的成本。下面，我们就来详细介绍 NoahV 是如何帮助开发人员快速提升研发效率的。 NoahV 把后端工程师变成了全栈 1、表格组件 在运维业务中，表格通常用来展示一些运维对象、运维事件列表（比如上线任务列表、监控任务列表、监控报警事件列表等）。但是运维的表格与基础表格不同的是，有一些运维对象，如图1，上线模板表格，除了渲染上线模板的列表信息，还需要按模板名称、创建时间进行筛选(图1.b)，对具体的一条模板信息进行编辑或者删除操作(图1.c)。 所以运维业务中的表格应用通常包含了增删改查的操作，这类操作虽然简单，对于非前端人员上手这类开发还是需要一定的前端知识。我们在 NoahV 中把表格组件做了进一步的增强，用配置化实现数据展示，数据操作等行为的开发，让非前端开发人员轻松上手。 图1  上线模板表格 具体的配置看下图： 图2  上线模板表格配置•  columns：表格每列的数据定义，对应图1.a•  url: 表格数据请求的url，对应图1.a•  method: 表格数据请求的方式，对应图1.a•  items: 表格筛选的交互，对应图1.b•  action: 表格编辑，删除的数据交互，对应图1.c在前后端分离的开发模式中，前端需要后端提供数据，但是后端通常还没开发完毕，这个时候前端就需要按照固定的数据结构自己来模拟数据。模拟数据其实是一个很繁琐的工作，比如上面的表格这类应用，在我们的实际业务场景中，需求还挺多的，模拟数据就是一个重复性的工作。在 NoahV 中，我们就用 NoahV Mockup 工具来生成这类重复性的应用。 noahv cli 就是我们的命令行工具，里面包含了 NoahV Mockup 模块，这个模块有一个命令就是 noahv create 命令，当执行 noahv create，提示输入模拟数据的接口名称，这个接口名称由一个具体的文件路径+文件名称组成，比如输入 api/table, 会自动在 mockup 目录下生成 api 文件夹，同时会在 api 文件夹中创建 table 模拟数据。 备注：使用 noahv create 之前需要安装 noahv cli 命令行工具，更详细的使用步骤，请查看我们的文档中心（ https://baidu.github.io/NoahV）。2、布局应用表格是前端的一个常用应用，当然还有一些如表单应用、列表应用等等，但是这些应用都不能成为独立的页面。这个独立的页面是包含了导航、面包屑、内容体，有的页面还会有更复杂的布局。所以前端应该如何布局，是很多开发人员关心的问题。 2.1 上-下布局 我们常用的页面布局有上-下布局，或者左-右布局模式。通常上-下布局中的上就是头部导航，下就是内容体，头部导航又有一级导航、二级导航之类，登录/退出等。这类共性的布局需求，我们在 NoahV 中也做了统一的封装，就是导航配置，我们先看下导航配置出来的效果图。 图3  导航应用a 对应 logo，b 对应导航菜单，c 对应登录，d 对应面包屑，e 对应内容体。我们来看下通过怎样的配置来实现上面的界面： 图4  导航配置 •  图 4 中的 logo 是对图 3.a logo 的配置•  header 是对图 3.b 的菜单导航配置•  login 是对图 3.c 的登录配置•  separator 是对图 3.d 面包屑的配置，hasBread 可以配置是否需要面包屑2.2 左-右布局 前面说到除了上-下这类布局，还有左-右这类情况，顾名思义，就是左侧导航，右侧内容体，通常情况下，头部导航与左侧导航有联动，其实看图 4 的导航配置中，看到有个 type 类型，type 类型这里有两种值: header/header-sidebar，看具体的值就能对应上 header-sidebar 就是头部导航与左侧导航的情况。我们直接把图4 中的 type 值改为 header-sidebar，就得到下图的布局界面： 图5  左侧导航配置2.3 自定义布局扩展 当然，页面布局远不止这两种情况，比如在运维场景中，我们有很多交互是对服务的某个节点做操作，所以就有左侧是服务树，右侧是服务节点对应的应用。这类布局就需要前端开发人员自己做自定义的布局开发。 我们在布局的入口页面做了普通布局与自定义布局的开关，可以在两种模式中进行切换。我们提供了自定义布局的 layout 文件，如果需要自定义模式就把这个文件引入，并使用即可。NoahV 可扩展性是前端工程师的利器上面详细介绍了...

  前端框架的变迁，体系架构的完善，使得我们只知道框架，却不明白它背后的道理。我们应该抱着一颗好奇心，在探索框架模式的变迁过程中，体会前人的一些理解和思考。   本篇将讲述的是前端框架变化过程中的一些思考，前端框架模式的变化：从无到有，从MVC(Flux或者Redux)->MVP->MVVM。这段变化的过程，会让人不断琢磨，每次的变化，都是一次大的进步。现在在前端的框架都是MVVM的模式，还有像Flux和Redux之类的MVC变种——独特的单向数据流框架。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的github门户（https://github.com/laizimo/zimo-article/issues）。   正文   其实，这些框架模式我们平时都会有所接触。它遵循着将整体应用的功能块进行分离的原则，对开发者开发软件进行一定的规范，以保持系统的稳定以及可维护性。   讲述前端框架变迁的过程中，我们可以通过梳理最近几十年的前端发展时间线，来深入分析前端的从无到有，从有到优的过程。   最初的时代   最初的时代，应该是web1.0时代吧。当时，开发者们并没有前端的概念。开发一个应用，或许只要5个人的小团队，就能够很快的配置出可运行的环境。而开发的语言使用的也是最初的JSP、ASP和PHP。拿JSP举例的话，当时系统的整体架构图可能是这样子的： 记得在学校的时候，最早搭建系统就是使用的这种架构。   这种架构的好处是简单快捷。使用Eclipse+tomcat就可以之间把程序跑起来，以及jsp的强大功能，足够满足小应用的开发。   但是，同样缺点也非常明显：   1. 业务体系增大，调试困难：随着业务体系的增大，后台service也会逐步膨胀，大致需要建设一个开发服务器进行存放，这会导致一个问题就是前端无法在本地进行调试，每次进行修改之后，都必须上传到开发服务器进行测试（况且开发服务器可能本身就不稳定）。   2. JSP代码难以维护：或许人少的时候，学JSP挺简单的。但是，一旦团队人数增多，JSP内参杂的业务逻辑也会逐渐增加，这会导致的是JSP本身难以维护。   为了让开发更加的便捷，代码变得更加的可维护，同时使得前后端的职责加以分离。这时，我们或许会考虑改变一下开发模式，将后端MVC化，而前端的展示则以模板的形式进行嵌套。典型的框架就是Spring、Structs。整体的框架，如图所示： 使用这样子的架构，复杂度被降低了，职责也会比较清晰。这个时代被称为后端的MVC时代。这个时候，前后端开始形成了一定的分离。前端只需要在本地编写好相应的页面，然后交给后端开发的人，让他们可以根据模板进行一个嵌套。这是前端只完成了后端开发中的view层内容。淘宝的早期使用的就是这种模式。现在仍有小部分创业型的公司会使用这种方式进行开发，主要是节约用人成本。   但是，同样的这种模式存在着一些：   1. 前端页面开发效率不高：其实，早期的时候根本也没啥前端开发工程师，有的只是页面仔。更多公司可能也有后端的人使用js在写页面的。因此，问题就暴露了出来，前端所做出来的页面需要放到后端环境去运行，使得前端开发的效率并不是特别之高，因为对于后端环境的依赖程度比较大。   2. 前后端职责不清：由于前端并未做太多的工作，以至于后端的开发体量比较庞大。就拿路由管理来举例子，本来路由管理可以由前端开发的人员来进行开发和管理。但是，使用这种架构时，后端需要去维护一个庞大的路由表，增加了后端的开发量。   前端的第一个春天   有个东西带来了前端的第一个春天——AJAX。自从Gmail的出现，ajax技术开始风靡全球。许多公司和开发者都不断地利用它做实验。有了ajax之后，前后端的职责就更加的清晰了。因为前端可以通过Ajax与后端进行数据交互，因此，整体的架构图也变化成了下面这幅图： 通过ajax与后台服务器进行数据的交换，前端开发的人员，只需要开发自己页面这部分的内容，数据可由后台进行提供。而且ajax可以使得页面实现部分刷新，极大的减少了之前需要反复开发的页面。这时，才开始有前端工程师开始慢慢从事前端。同时前端的类库也慢慢的开始发展，最著名的就是jQuery了。   但其实，这样子的架构中还是存在一定的问题——前端缺乏一种可行的开发模式。整体的内容都杂糅在一起，一旦应用增大，就会导致难以维护了。举个例子，当图书少的时候，我们就算随意放置，整理起来都比较方便；但是，一旦具有像图书馆一样多的图书时，必须有一种统一的管理方式。同样的，前后端分离之后，前端的开发业务逐渐增多，责任也愈加的巨大，开发者急需一种比较好的框架来规范整个应用。因此，前端的MVC也随之而来。   前后端分离后的架构演变——MVC、MVP和MVVM   MVC   前端的MVC应该与后端类似，具备着View、Controller和Model。   Model：负责保存应用数据，与后端数据进行同步   Controller：负责业务逻辑，根据用户行为对Model数据进行修改   View：负责视图展示，将model中的数据可视化出来。   理论上，他们三者形成了一个如图所示的模型： 这样的模型，在理论上是可行的。但往往在实际开发中，并不会这样去操作。因为开发的过程需要灵活，而这种模式并不满足灵活的条件。例如，一个小小的事件操作，都必须经过这样的一个流程，那么开发就不再便捷了。   在实际场景中，我们往往会看到另一种模式，如图： 这种模式在开发中更加的灵活，backbone.js框架就是这种的模式。   但是，这种灵活，也会导致一些严重的问题：   1. 数据流混乱。或许，你还不一定能够很好的理解，何为数据流混乱。那么，我们来看一副图： 这幅图中，特别是model和view这一块的数据交互，感觉看起来像是连连看，非常的混乱，而且维护起来非常麻烦。这就是灵活开发带来的后遗症。拿backbone举个例子，backbone将Model的set和on方法暴露出来，方便外部对其进行直接操作。   2. View比较庞大，而Controller比较单薄：由于很多的开发者都会在view中写一些逻辑代码，逐渐的就导致view中的内容越来越庞大，而controller变得越来越单薄。   既然有缺陷，就会有变革。前端的变化中，好像少了MVP的这种模式，或许是因为Angular早早地将MVVM的框架模式带入了前端，这也许就是Google工程师的智慧吧。那我们还是需要来了解一下MVP这种模式，虽然前端开发并不常用，但是在安卓等native开发时，开发者都会考虑到它的。   MVP   MVP与MVC很接近，P指的是Presenter，presenter可以理解为一个中间人，它负责着View和Model之间的数据流动，防止View和Model之间直接交流。我们可以看一下图示： 我们可以通过看到，presenter负责和Model进行双向交互，还和View进行双向交互。这种交互方式，相对于MVC来说少了一些灵活，VIew变成了被动视图，并且本身变得很小。虽然它分离了View和Model。但是应用逐渐变大之后，缺陷也会随之暴露。   缺陷：   由于大部分逻辑都需要presenter去进行管理，从而导致presenter的体积增大，难以维护。如果需要去解决这个问题，或许可以从MVVM的思想中找到答案。   MVVM   首先，何为MVVM呢？MVVM可以分解成(Model-View-VIewModel)。ViewModel可以理解为在presenter基础上的进阶版。废话不多说，先上图例： 在这里View是ViewModel的外在显示，和ViewModel的数据是同步的。一旦View中的数据发生变化，会自动同步到ViewModel，然后ViewModel可以将变化的数据传给Model；反过来也是一样的，Model中的数据一旦发生改变，就会将值传给ViewModel，而ViewModel也会同步更新到view中。现在的框架实现这样的形式，各有各的不同。主要的三个框架angular2、vue、react都是实现了这样子的模式。   这种的好处就是View和Model之间被分离开来。view不知道model的存在，viewmodel和model也觉察不到view。事实上，model也完全忽略viewmodel和view的存在。这是一个非常松散耦合的设计。   但它也不是所用地方都适用的，例如，后端开发是适用的。因为网络资源成本过高，开发成本过高导致的。   Flux或者Redux   讨论完上面的三种框架，我们再来看一下Flux。之前，我们在讨论MVC的时候，提及过MVC最主要的缺点就是数据流混乱，难以管理。但是，Facebook却在这个基础上对MVC做出了改变，那就是——单向数据流。只要将数据流进行规范，那么原来的模式还是大有可为的。   我们可以来看一下，Flux框架的图示： 从图中，我们可以看到形成了一条Action到Dispatcher，再到Store，之后是View的，一条单向数据流。在这里Dispatcher会严格限行我们操作数据的行为，而Store也不会暴露setter接口，让其随意被修改。最终，这样的一套框架在大多数场景下，比MVC更加完美。（细节部分我们不做探究，有兴趣可以研究一下Redux源码，也就近千行代码）。   总结   我们依据前端发展为时间线，整理了前端整体框架的从无到有，从有到优的过程。   1. 最初的时代——web1.0 2. 前端的春天——Ajax...

  经常有小伙伴会问：“你一个人设计、开发，效率还那么高，怎么做到的？” 其实这个问题从某个角度已经给出了答案——是我自己进行的UI设计，所以设计规范我很清楚，开发的时候效率也会有所提高。   如果设计和开发人员之间能共用一套大家都熟悉的设计规范，对其内容、样式、组件、扩展组件…达成共识，那么你们的协作效率将会大大提升～   下面要推荐的这些前端框架可以来规范你的设计，提升和程序员的协作效率！         1Bootstrap网站链接：http://www.bootcss.com   Twitter 推出的基于 HTML / CSS / JS 开发的开源工具包，GitHub Star 131528，在世界范围内得到了广泛的支持和应用。链接给出的是Bootstrap中文网，除了关于Bootstrap相关介绍及教程外，网站还推荐了大量优质项目方便大家预览学习。   2Ant Design网站链接：https://ant.design/index-cn   蚂蚁金服出品的基于 React 开发的框架，GitHub Star 43580，相信大家或多或少都听说过这个框架，目前已经很成熟了，很多公司也都在用。网站提供了大量设计资源及设计工具，你可以直接下载使用。   关于 Ant Design 的更多介绍及教程都可以从网站上找到，这里也就再不过多说明，不过在具体运用中，如有创新还是预先要和开发团队进行沟通。   3Fusion Design网站链接：https://fusion.design   阿里巴巴推出的协助设计师与开发人员共同使用的设计规范框架，GitHub Star 1751，网站提供了一系列设计资源、教程及案例供大家参考学习。   4WeUI网站链接：https://weui.io   WeUI 是一套同微信原生视觉体验一致的基础样式库，GitHub Star 21528，由微信官方设计团队为微信内网页和微信小程序量身设计，令用户的使用感知更加统一。网站提供了微信页面常用的组件样式，非常清晰明了。   5QMUI网站地址：https://qmuiteam.com   腾讯针对Web、iOS、Android三个方向出品的设计框架，GitHub Star 分别是1558、3748、7357，每个方向都有详细的网页描述，同时 iOS 和 Android 还提供了 Demo 下载，方便在手机端操作学习。     6Element网站链接：http://element-cn.eleme.io   饿了么出品的基于 Vue 2.0 的桌面端组件库，GitHub Star 35724，适合开发者、设计师和产品经理使用，网站提供了相关介绍和教程，以及Axure和Sketch组件。   7iView网站链接：https://www.iviewui.com     一套基于 Vue.js 的高质量 UI 组件库，GitHub Star 20195，网站提供的UI组件都对应给出了代码，方便开发人员进行查看。   8Taro UI网站链接：https://taro-ui.aotu.io/#/     京东用户体验设计部凹凸实验室出品的一套基于 Taro 框架开发的多端 UI 组件库，GitHub Star 1688，Taro UI 一套组件可以在微信小程序 / H5...