2015年最受欢迎的20篇[原创]文章

第一篇:【原创】移动端高清、多屏适配方案 【移动端H5】

背景

  1. 开发移动端H5页面

  2. 面对不同分辨率的手机

  3. 面对不同屏幕尺寸的手机

视觉稿

在前端开发之前,视觉MM会给我们一个psd文件,称之为视觉稿

对于移动端开发而言,为了做到页面高清的效果,视觉稿的规范往往会遵循以下两点:

  1. 首先,选取一款手机的屏幕宽高作为基准(以前是iphone4的320×480,现在更多的是iphone6的375×667)。

  2. 对于retina屏幕(如: dpr=2),为了达到高清效果,视觉稿的画布大小会是基准2,也就是说像素点个数是原来的4(对iphone6而言:原先的375×667,就会变成750×1334)。

问题:

  1. 对于dpr=2的手机,为什么画布大小×2,就可以解决高清问题?

  2. 对于2倍大小的视觉稿,在具体的css编码中如何还原每一个区块的真实宽高(也就是布局问题)?

带着问题,往下看…

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Mobile-terminal-H5-mobile-terminal-HD-multi-screen-adaptation-scheme%203041

作者:Lovesueee  发表日期:2015-07-02

第二篇:javascript组件开发方式 【js从零单排】

作为一名前端工程师,写组件的能力至关重要。虽然javascript经常被人嘲笑是个小玩具,但是在一代代大牛的前仆后继的努力下,渐渐的也摸索了一套组件的编写方式。

下面我们来谈谈,在现有的知识体系下,如何很好的写组件。

比如我们要实现这样一个组件,就是一个输入框里面字数的计数。这个应该是个很简单的需求。

图片

我们来看看,下面的各种写法。

为了更清楚的演示,下面全部使用jQuery作为基础语言库。

最简陋的写法

嗯 所谓的入门级写法呢,就是完完全全的全局函数全局变量的写法。(就我所知,现在好多外包还是这种写法)

代码如下:

<!DOCTYPE html><html><head>
  <meta charset="utf-8">
  <title>test</title>
  <script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
  <script>
    $(function() {

      var input = $('#J_input');

      //用来获取字数      function getNum(){
        return input.val().length;
      }

      //渲染元素      function render(){
        var num = getNum();

        //没有字数的容器就新建一个        if ($('#J_input_count').length == 0) {
          input.after('<span id="J_input_count"></span>');
        };

        $('#J_input_count').html(num+'个字');
      }

      //监听事件      input.on('keyup',function(){
        render();
      });

      //初始化,第一次渲染      render();


    })
  </script></head><body><input type="text" id="J_input"/></body></html>

这段代码跑也是可以跑的,但是呢,各种变量混乱,没有很好的隔离作用域,当页面变的复杂的时候,会很难去维护。目前这种代码基本是用不了的。当然少数的活动页面可以简单用用。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/JS-from-zero-single-row-JavaScript-component-development-method

作者:竹隐    发表日期:2015-03-16


第三篇:移动Web开发技巧汇总 【前端分享】

META相关

1. 添加到主屏后的标题(IOS)

<meta name="apple-mobile-web-app-title" content="标题">

2. 启用 WebApp 全屏模式(IOS)

当网站添加到主屏幕后再点击进行启动时,可隐藏地址栏(从浏览器跳转或输入链接进入并没有此效果)

<meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="apple-touch-fullscreen" content="yes" />

<!–more–>

3. 百度禁止转码

通过百度手机打开网页时,百度可能会对你的网页进行转码,往你页面贴上它的广告,非常之恶心。不过我们可以通过这个meta标签来禁止它:

<meta http-equiv="Cache-Control" content="no-siteapp" />

百度SiteApp转码声明

4. 设置状态栏的背景颜色(IOS)

设置状态栏的背景颜色,只有在 "apple-mobile-web-app-capable" content="yes" 时生效

<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />

content 参数:

  • default :状态栏背景是白色。

  • black :状态栏背景是黑色。

  • black-translucent :状态栏背景是半透明。 如果设置为 default 或 black ,网页内容从状态栏底部开始。 如果设置为 black-translucent ,网页内容充满整个屏幕,顶部会被状态栏遮挡。

5. 移动端手机号码识别(IOS)

在 iOS Safari (其他浏览器和Android均不会)上会对那些看起来像是电话号码的数字处理为电话链接,比如:

  • 7位数字,形如:1234567

  • 带括号及加号的数字,形如:(+86)123456789

  • 双连接线的数字,形如:00-00-00111

  • 11位数字,形如:13800138000

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Front-end-sharing%202983

作者:凯凯刘     发表日期:2015-06-09

第四篇:React Native第一课 【即学即用React Native】

React Native第一课

前言

本篇文章的作用在于帮助你快速上手使用React Native编写iOS应用。如果你现在还不太了解React Native是什么以及Facebook为什么要创建React Native,你可以先看看这篇博客

阅读本文之前,我们假设你已经有过使用React创建网站的经验。如果你还是一个React新手,那么我们建议你从React的网站开始学习。

设置

使用React Native开发iOS应用需要OSX系统,Xcode,Homebrew,node,npm以及watchman,你也可以有选择的使用Flow。

在安装完这些依赖项目之后,你可以简单的使用两行命令来开启一个React Native项目:

  1. npm install -g react-native-cli

react-native-cli是用来开发React Native的命令行工具。你需要使用npm来安装它。上面这行代码将会帮助你在terminal中安装react-native命令。当然,你只需要运行一次这行代码。

  1. react-native init AwsomeProject

这行代码可以获取所有React Native的源码以及依赖项,同时会创建一个叫做AwsomeProject/AwsomeProject.xcodeproj的全新Xcode项目。

开发

现在你可以在Xcode中开发这个新项目(AwsomeProject/AwsomeProject.xcodeproj),并简单的使用cmd+R来运行它。运行代码的同时也会自动开启一个node服务器来实现代码的热重载。这样一来你就可以通过cmd+R来查看变化而不需要每次都在Xcode中进行重编译。

在本文中我们将创建一个简单的电影应用,这个应用将抓取目前正在上映的最新的25部电影,并将它们展示在一个ListView中。

Hello World

react-native init会复制Example/SampleProject中的内容到你命名的项目中,在本文中项目名称为AwsomeProject。这是一个简单的hello world应用。你可以通过编辑index.os.js来改变这个应用,然后使用cmd+R在模拟器中查看变化。

伪造数据

在我们开始编写代码从Rotten Tomatoes网站抓取数据之前,我们先来伪造一些数据以便我们可以马上体验一下React Native。在Facebook我们一般会在JS文件的顶部声明常量,并在后面使用,但是随便你加在哪里都好。在index.ios.js中添加以下代码:

var MOCKED_MOVIES_DATA = [
  {title: 'Title', year: '2015', posters: {thumbnail: 'http://i.imgur.com/UePbdph.jpg'}},];

渲染一部电影

我们会渲染电影标题,年份以及电影海报略缩图。由于略缩图在React Native中是一个Image组件,我们需要将Imagei到React的依赖项中。

var {
  AppRegistry,
  Image,
  StyleSheet,
  Text,
  View,} = React;

现在我们修改render函数以便我们可以将上面渲染上面的数据而不仅仅是渲染一个hello world:

 render: function() {
    var movie = MOCKED_MOVIES_DATA[0];
    return (
      <View style={styles.container}>
        <Text>{movie.title}</Text>
        <Text>{movie.year}</Text>
        <Image source={{uri: movie.posters.thumbnail}} />
      </View>
    );
  }

按下cmd+R你应该在”2015”上面看到”Title”。注意此时Image什么都不会渲染。这是因为我们还没有指定想要的宽度和高度。这需要通过styles属性来设置。在我们修改styles的同时我们还需要把那些不再会使用的样式删除:

var styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#F5FCFF',
  },
  thumbnail: {
    width: 53,
    height: 81,
  },});

最后我们需要将样式运用在Image组件上。

<Image
          source={{uri: movie.posters.thumbnail}}
          style={styles.thumbnail}
 />

按下cmd+R你会发现图片已经渲染出来了。

#图片1

添加其他样式

很好,我们现在已经把数据渲染出来了。现在我们来让我们的应用变得好看一些。我想把文字放在图片的右侧,同时让标题大一些并居中:

+---------------------------------+|+-------++----------------------+|||       ||        Title         |||| Image ||                      ||||       ||        Year          |||+-------++----------------------+|+---------------------------------+

我们会添加另一个container,这是为了让我们的组件在外层的组件中垂直居中。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Learn-that-use-React-Native-React-Native-the-first-lesson

作者:张小俊128     发表日期:2015-03-27

第五篇:Javascript 之高逼格代码 【js菜鸟中的菜鸟开始学飞】

在学习javascript的路上,偶尔会遇到那么几个看不懂的代码或者符号之类的就忍不住百度一下!搜嘎~ 原来如此!也许这就是装逼的一种效果吧!但是作为程序员也不想让别人一眼就看出你的代码!所以就有那么一批人开始了装逼之旅,但是能写出高逼格代码的人绝对理解的比看不懂的要深刻~ 侬晓得吧!

推荐一下javascript装逼指南 这本书 很有益处哦!!!

下面列出一些装逼技巧 供像我这样菜鸟级的学生看一下:

技巧一:javascript高逼格之取整

也许你会想到Math的方法Math.ceil() 以及Math.floor()

但是你也许在别的代码中看到过这么两种符号 ~~ 和 |0

他们当然也是取整的了

没有这两样东西怎么能装的彻底嘞

enter image description here特别注意的一点就是这两种方式是将小树后面的直接砍掉的当取负数的时候与Math.floor(-15.96)有所不同

enter image description here

下面多列举几个让大家明白enter image description here

技巧二:javascript高逼格之匿名函数

一般情况下的匿名函数是这样的

 (function(){})();

但是还有其他的写法

enter image description here当然,这样的写法,没有什么区别,纯粹看装逼程度。

这些可能只是一少部分,可能还有很多。我只是举例说明一下

我们知道这种是闭包的一种形式,

并且在编程中运算符(+ – ~ ! 优先级相对其他的代码程序较高)

所以闭包前面加个运算符是木有关系的只是写法不同

·················

阅读全文请点击原文链接:http://www.html-js.com/article/JS-rookie-in-the-rookie-to-start-learning-to-fly-high-force-lattice-code-Javascript

作者:古道川     发表日期: 2015-03-19

第六篇:屌爆了,完美调试 微信webview(x5) 【微信】

前面的话

自从腾讯家族 移动webview入口换成了x5以来,业界褒贬不一,总体来说给开发者带来许多惊喜,其中最重要的就是微信x5调试能力,想想过去 码农们 苦逼的完成code 本地浏览器一跑ok 上微信 手q上 出现一堆兼容性的问题 惨不忍睹 过去微信 q 没有调试能力 只能借助 什么weinre debugeap等等 半吊子工具 凑合去使用

转眼2015 微信已经开放webview调试能力 借助chrome 调试不再是梦想(换肤 断点调试 性能测试 控制台 等等 )

由于使用起来稍微有些复杂 以下按照模块方式介绍使用方式:

调试原理 借助chrome 和android adb 功能http://upload-images.jianshu.io/upload_images/326507-590b84de3dc09486.png?imageMogr2/auto-orient/strip|imageView2/2/w/1240

前期准备

  1. 下载最新微信 我用是6.1

  2. 下载TbsSuiteNew.apk安装到手机中 地址(http://res.imtt.qq.com///tbs_inspect/TbsSuiteNew.zip)

  3. 打开微信 进入聊天界面(任意) 输入框内输入//deletetbs,点发送

enter image description here

输入//gettbs可以查看当前 tbs情况

4.打开TbsSuiteNew 选择按照本地tbs内核
5.下载tbs调试包

enter image description here

应用包名 微信:com.tencent.mm,qq:com.tencent.mobileqq,qq空间:com.qzone】 我们选择微信即可

·················

阅读全文请点击原文链接:http://www.html-js.com/article/WeChat-cock-burst-perfect-debugging-WeChat-WebView-x5%203076

作者:sherlock221b     发表日期:  2015-07-23

第七篇:2015前端组件化框架之路 【民工精髓的博客】

1. 为什么组件化这么难做

Web应用的组件化是一个很复杂的话题。

在大型软件中,组件化是一种共识,它一方面提高了开发效率,另一方面降低了维护成本。但是在Web前端这个领域,并没有很通用的组件模式,因为缺少一个大家都能认同的实现方式,所以很多框架/库都实现了自己的组件化方式。

前端圈最热衷于造轮子了,没有哪个别的领域能出现这么混乱而欣欣向荣的景象。这一方面说明前端领域的创造力很旺盛,另一方面却说明了基础设施是不完善的。

我曾经有过这么一个类比,说明某种编程技术及其生态发展的几个阶段:

最初的时候人们忙着补全各种API,代表着他们拥有的东西还很匮乏,需要在语言跟基础设施上继续完善 然后就开始各种模式,标志他们做的东西逐渐变大变复杂,需要更好的组织了 然后就是各类分层MVC,MVP,MVVM之类,可视化开发,自动化测试,团队协同系统等等,说明重视生产效率了,也就是所谓工程化 那么,对比这三个阶段,看看关注这三种东西的人数,觉得Web发展到哪一步了?

细节来说,大概是模块化和组件化标准即将大规模落地(好坏先不论),各类API也大致齐备了,终于看到起飞的希望了,各种框架几年内会有非常强力的洗牌,如果不考虑老旧浏览器的拖累,这个洗牌过程将大大加速,然后才能释放Web前端的产能。

但是我们必须注意到,现在这些即将普及的标准,很多都会给之前的工作带来改变。用工业体系的发展史来对比,前端领域目前正处于蒸汽机发明之前,早期机械(比如《木兰辞》里面的机杼,主要是动力与材料比较原始)已经普及的这么一个阶段。

所以,从这个角度看,很多框架/库是会消亡的(专门做模块化的AMD和CMD相关库,专注于标准化DOM选择器铺垫的某些库),一些则必须进行革新,还有一些受的影响会比较小(数据可视化等相关方向),可以有机会沿着自己的方向继续演进。

2. 标准的变革

对于这类东西来说,能获得广泛群众基础的关键在于:对将来的标准有怎样的迎合程度。对前端编程方式可能造成重大影响的标准有这些:

module
Web Components
classobservepromise

module的问题很好理解,JavaScript第一次有了语言上的模块机制,而Web Components则是约定了基于泛HTML体系构建组件库的方式,class增强了编程体验,observe提供了数据和展现分离的一种优秀方式,promise则是目前前端最流行的异步编程方式。

这里面只有两个东西是绕不过去的,一是module,一是Web Components。前者是模块化基础,后者是组件化的基础。

module的标准化,主要影响的是一些AMD/CMD的加载和相关管理系统,从这个角度来看,正如seajs团队的@afc163 所说,不管是AMD还是CMD,都过时了。

模块化相对来说,迁移还比较容易,基本只是纯逻辑的包装,跟AMD或者CMD相比,包装形式有所变化,但组件化就是个比较棘手的问题了。

Web Components提供了一种组件化的推荐方式,具体来说,就是:

通过shadow DOM封装组件的内部结构 通过Custom Element对外提供组件的标签 通过Template Element定义组件的HTML模板 通过HTML imports控制组件的依赖加载 这几种东西,会对现有的各种前端框架/库产生很巨大的影响:

由于shadow DOM的出现,组件的内部实现隐藏性更好了,每个组件更加独立,但是这使得CSS变得很破碎,LESS和SASS这样的样式框架面临重大挑战。 因为组件的隔离,每个组件内部的DOM复杂度降低了,所以选择器大多数情况下可以限制在组件内部了,常规选择器的复杂度降低,这会导致人们对jQuery的依赖下降。 又因为组件的隔离性加强,致力于建立前端组件化开发方式的各种框架/库(除Polymer外),在自己的组件实现方式与标准Web Components的结合,组件之间数据模型的同步等问题上,都遇到了不同寻常的挑战。 HTML imports和新的组件封装方式的使用,会导致之前常用的以JavaScript为主体的各类组件定义方式处境尴尬,它们的依赖、加载,都面临了新的挑战,而由于全局作用域的弱化,请求的合并变得困难得多。

3. 当下最时髦的前端组件化框架/库

在2015年初这个时间点看,前端领域有三个框架/库引领时尚,那就是Angular,Polymer,React(排名按照首字母),在知乎的这篇2014 年末有哪些比较火的 Web 开发技术?里,我大致回答过一些点,其他几位朋友的答案也很值得看。关于这三者的细节分析,侯振宇的这篇讲得很好:2015前端框架何去何从

我们可以看到,Polymer这个东西在这方面是有先天优势的,因为它的核心理念就是基于Web Components的,也就是说,它基本没有考虑如何解决当前的问题,直接以未来为发展方向了。

React的编程模式其实不必特别考虑Web标准,它的迁移成本并不算高,甚至由于其实现机制,屏蔽了UI层实现方式,所以大家能看到在native上的使用,canvas上的使用,这都是与基于DOM的编程方式大为不同的,所以对它来说,处理Web Components的兼容问题要在封装标签的时候解决,反正之前也是要封装。

Angular 1.x的版本,可以说是跟同时代的多数框架/库一样,对未来标准的兼容基本没有考虑,但是重新规划之后的2.0版本对此有了很多权衡,变成了激进变更,突然就变成一个未来的东西了。

这三个东西各有千秋,在可以预见的几年内将会鼎足三分,也许还会有新的框架出现,能不能比这几个流行就难说了。

此外,原Angular 2.0的成员Rob Eisenberg创建了自己的新一代框架aurelia,该框架将成为Angular 2.0强有力的竞争者。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/The-essence-of-the-2015-migrant-workers-blog-frontend-component-framework-road

作者:民工精髓     发表日期:  2015-03-25

第八篇:【原创】ui.router源码解析 【前端源码解析】

angular路由

路由(route),几乎所有的MVC(VM)框架都应该具有的特性,因为它是前端构建单页面应用(SPA)必不可少的组成部分。


那么,对于angular而言,它自然也有内置的路由模块:叫做ngRoute

不过,大家很少用它,因为它的功能太有限,往往不能满足开发需求!!

于是,一个基于ngRoute开发的第三方路由模块,叫做ui.router,受到了大家的“追捧”。


ngRoute vs ui.router

首先,无论是使用哪种路由,作为框架额外的附加功能,它们都将以模块依赖的形式被引入,简而言之就是:在引入路由源文件之后,你的代码应该这样写(以ui.router为例):

angular.module("myApp", ["ui.router"]); // myApp为自定义模块,依赖第三方路由模块ui.router

这样做的目的是:在程序启动(bootstrap)的时候,加载依赖模块(如:ui.router),将所有挂载在该模块的服务(provider)指令(directive)过滤器(filter)等都进行注册,那么在后面的程序中便可以调用了。

说到这里,就得看看ngRoute模块ui.router模块各自都提供了哪些服务,哪些指令?

  1. ngRoute

    • $routeProvider(服务提供者) ——— 对应于下面的urlRouterProvider和stateProvider

    • $route(服务) ——— 对应于下面的urlRouter和state

    • $routeParams(服务) ——— 对应于下面的stateParams

    • ng-view(指令) ——— 对应于下面的ui-view

  2. ui.router

    • $urlRouterProvider(服务提供者) ——— 用来配置路由重定向

    • $urlRouter(服务)

    • $stateProvider(服务提供者) ——— 用来配置路由

    • $state(服务) ——— 用来显示当前路由状态信息,以及一些路由方法(如:跳转)

    • $stateParams(服务) ——— 用来存储路由匹配时的参数

    • ui-view(指令) ——— 路由模板渲染,对应的dom相关联

    • ui-sref(指令)

(服务提供者:用来提供服务实例和配置服务。)

这样一看,其实ui.routerngRoute大体的设计思路,对应的模块划分都是一致的(毕竟是同一个团队开发),不同的地方在于功能点的实现和增强


那么问题来了:ngRoute弱在哪些方面,ui.router怎么弥补了这些方面?

这里,列举两个最重要的方面来说(其他细节,后面再说):

  1. 多视图

  2. 嵌套视图


多视图

多视图:页面可以显示多个动态变化的不同区块。

这样的业务场景是有的:

比如:页面一个区块用来显示页面状态,另一个区块用来显示页面主内容,当路由切换时,页面状态跟着变化,对应的页面主内容也跟着变化。

首先,我们尝试着用ngRoute来做:

html

<div ng-view>区块1</div><div ng-view>区块2</div>

js

$routeProvider    .when('/', {
        template: 'hello world'
    });

我们在html中利用ng-view指令定义了两个区块,于是两个div中显示了相同的内容,这很合乎情理,但却不是我们想要的,但是又不能为力,因为,在ngRoute中:

  1. 视图没有名字进行唯一标志,所以它们被同等的处理。

  2. 路由配置只有一个模板,无法配置多个。

ok,针对上述两个问题,我们尝试用ui.router来做:

html

  <div ui-view></div>
  <div ui-view="status"></div>

js

$stateProvider    .state('home', {
        url: '/',
        views: {
            '': {
                template: 'hello world'
            },
            'status': {
                template: 'home page'
            }
        }
    });

这次,结果是我们想要的,两个区块,分别显示了不同的内容,原因在于,在ui.router中:

  1. 可以给视图命名,如:ui-view=”status”。

  2. 可以在路由配置中根据视图名字(如:status),配置不同的模板(其实还有controller等)。

:视图名是一个字符串,不可以包含@(原因后面会说)。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Front-end-source-code-analysis-original-uirouter-source-code-analysis

作者:Lovesueee     发表日期:  2015-04-20

第九篇:前端选择麻痹症 【前端说】

前端选择麻痹症

目前来看,前端开发这个行业面临的一个重要问题是我们有太多的选择。我们有足够多的工具、框架、语言、抽象和平台。一般来说,更多的选择意味着更多的竞争性和创新,然而当选择实在太多太多的时候,我们常常会感到麻痹。因为选择太多常常会导致无法选择。这并不是前端开发这个行业才有的问题 – 这是个人类社会的难题。

你可以想象一下在Netflix上点播一部电影这件事情。

就在这个周末,我打算在Netflix上点播一部电影。一开始,我已经计划花两个小时的时间来看电影,我想两个小时怎么样都足够了。

但事实证明我错了!Netflix电影目录给我推荐了上百部电影,于是接下来的时间中我一直在不停地挑选。看暮光之城吗?暮光之城2?还是暮光之城3?这部电影从头到尾都在讲一个呆萌少女在肌肉猛男和帅气暖男之间无法选择的故事。看阿凡达吗?看起来像是蓝人军团和侏罗纪公园的混合体。

面对这么多的选择,我开始慌了。换句话说:我不知道该怎么办了。我花了一个小时才找到一个似乎感兴趣的电影么,结果才看到一半我的预计时间就花完了。看还是不看,我又陷入了两难。

心理学家巴里•施瓦茨在他2004年出版的著作《选择的悖论》一书中阐述过这个问题,他在书中说:对于消费者来说,选择越少意味着更少的焦虑。

在书中,他引用了一个由Sheena Iyengar和Mark Lepper进行的相关果酱实验:

“研究人员(在一家精品食物超市中)放置一行外国的、高质量的果酱,消费者可以先品尝其中一些,然后获得一个优惠劵,这个优惠劵可以在购买一瓶果酱时获得一美元的优惠。在情况一中,有6种果酱提供品尝。在情况二中,由24种果酱提供品尝。在两种情况下,都有24种果酱可以购买。由于两种情况下可供给购买的果酱数量都一致,因此可以认为两种实验中消费者的平均数量是一致的。但是最后的购买数量却有巨大的差别。在情况一中,有30%的消费者购买了果酱。而情况二中只有3%的消费者购买了果酱”

人类面临的一个巨大挑战在于当面临许多的选择时,你可能会不确定哪一个才最适合你。选择太多,你可能不会感到开心,反而会感到焦虑。我是不是选择了一个错误的选项?我的朋友们都在用些什么?我是不是应该问问他们?我不想被认为是一个笨蛋!我们正在慢慢陷入一个无敌的泥潭,因为我们无时无刻不在担心是否有更好的选择。扪心自问,你是否曾经在午夜梦回时怀疑自己的技术选择?

当你面临太多选择时,你的期望往往也会水涨床高。或许你会觉得如果你再观望一会,你可能会找到“最好的”那个。好比在马群中找到一只独角兽。选择越多,正确的选择往往会更惊人。然而,在寻找完美的道路上我们往往会越来越不满足。我们的高期待常常难以满足,这令我们陷入无休无止的不满足中。

JavaScript有“天哪又是一个框架综合症(想想看我们现在有多少种MVC框架,模板渲染框架以及数据绑定方式)”,Perl有“方法是多种多样的综合症”,而Python有“这不是显而易见的么综合症”,当然这也是“Python的禅道”。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Front-end-front-end-select-paralysis

作者:张小俊128     发表日期:  2015-03-02

第十篇:如何面试一名前端开发工程师? 【大搜车前端团队专栏】

从公司前端团队建立以来,一年多的时间已经过去了。这期间,招聘自然是少不了的,招进来的人有10来个,面过的人更是数不胜数,自然也从中得到一些体会,不能算是深刻地经验,只能算作一些思考吧,或许对于认同其理念的人来说,也算是一种参考了。

我现在已经很少纠结面试一个人应该问什么、考什么等问题了,不是说成长了或是怎么了,只是之前仔细分析了一下面试的目的,然后从目的往前推算如何在面试中获取这些信息,最后结合前端的知识点和职业特性,把“如何面试一个前端开发”总结成几条规则。每次以此套用,屡试不爽。今天要分享的也正是这一个过程,可能对于其他人来说并不一定完全适用,但是这种思路,我感觉还是有些意义的。

第一步,分析你想要什么样的人

面试的第一步就是要分析你想要什么样的人,不管是你的个人喜好,还是团队气质,技术水平,甚至是性别年龄,都是一些衡量标准,把这些标准用优先级列一个表格出来,按照表格继续进行下一步的分析。

例如对于我来说,在这一步我会这样总结,暂且称之为“期望点”:

  • 技术热情很重要,我不需要单纯的把技术当做吃饭家伙的人。

  • 做事态度很重要,我不想招聘天天抱怨却不去解决问题的人。

  • 学习能力,总结能力,能够自我进步的人,而不是需要手把手教的。

  • 分析能力,其实也就是解决问题的能力。

  • 技术经验,当然越多越好,如果缺乏,至少要表现出成长潜力。

其实每个条件,都是针对以后工作中可能出现的问题的规避,也是职场生存的基本素质。

第二步,分析如何考察每个“期望点”

考察有几种方式,就跟面试有很多种方式一样,这里只是提供一个思路啦,就是我自己的想法,算作参考吧。

  1. 技术热情。我面试人的时候一般很少用“提问式面试”,不会刻意提一个技术问题让你去解决然后搞得对方紧张兮兮,我主要靠引导,会引导出一些技术话题来,例如一些热门话题,一些技术热点难点,一些新工具,然后我会看对方的反应,他们听到这些话题后是立马来了兴趣,还是一点反应都没有,甚至从来没听说过也不表现出希望学习它们的状态?其实这样就很容易看出一个面试者对待技术的热情了,然后再补充一些类似于“平常玩些什么技术?”之类的话题。主要是让对方来说,来表达,我见过很多面试者都是比较腼腆的,但是谈到技术话题就两眼发光精神焕发,这样的开发者,技术想不好都不行。

  2. 做事态度。今天中午我还跟朋友出去吃饭的时候谈起这个话题。创业公司有时候真的就是个坑,需要面对很多不如意,例如薪资、福利或者是业务流程之类的问题,面对这些问题你的态度是怎样的?一味抱怨?还是能从大局的角度来考虑这些问题?老板跟员工从来就不是对立面的,其实他们是合作共赢的,如果不能理解这一点,那就没法在一个创业公司好好做下去。所以面试的时候,我会问”为什么离开上一个公司?”,如果能说出一些前公司的问题来,最好就要带着解决方案,至少你要想过我下一家公司在这些问题的方面应该是怎样的。而不是一味的抱怨,这不好那不好,片面的看待问题。创业公司是个坑,但是也有可能会是一座崎岖不平的高山之路,我们希望能招聘到可以跨着崎岖一起爬上山顶的人。

  3. 学习总结能力。创业公司相对于大公司来说,的确是忙的,而且人又少,能够手把手教你的机会太少,大多数时间还是要靠个人成长(当然有个好的团队还是很重要的,潜移默化的影响)。而且做技术大多提倡自我提升。对于这个“期望点”,我会通过考察第一点的时候顺带提取这些信息,例如谈到某个技术的时候,我会问一下,学这个是为了做什么?什么时候学的,如何学习的。又或是问一些“平常看什么书?什么时候看?从什么渠道了解最新的知识?”。看着是很虚的话题,面试者完全可以瞎编乱造,不过一个小时的面试下来,如果面试者都是胡编乱造的话,破绽只会越来越明显。

  4. 分析解决问题的能力。 之前在知乎上看到一个问题,就是讨论前端面试应该问一些什么。其中提到一点,问他在前公司做过什么项目,如何做的,使用了什么技术,是怎么考虑的,遇到了什么问题如何解决的之类的问题。这点对于有工作经验的人非常有用,所以毕业第一份工作一定要选好,不要去那种会让你技术逼格降低的公司,例如一些传统技术公司,你在那里工作就是为了拿薪水,对于自身的成长方面只能是“呵呵”。前几天面过一个要价3W/m的技术,问他什么都一问三不知,年纪也熬的不小了,30多岁,但是真的是啥都不会,连刚毕业的大学生都比不过,我感觉他对自我的思考对技术的思考基本上是不断在倒退的状态,很难让人接受他。

  5. 技术经验和成长潜力。技术经验就是指你之前积累的经验,当然越多越好,包括 技术广度和深度方面的经验,项目管理经验,架构经验工具化经验开发流程经验,协调管理经验。如果没有经验的应届生也没事,我一般会给应届生讲一些知识点,有的面试者会充满兴趣,问这问那,或者试着自己给出解决方案,这样的面试者我认为就是具备这种潜力的,所以即使现在经验不足,那潜力还是有的,毕竟对应届生要求不能太高。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Large-search-front-team-column%202961

作者:芋头     发表日期:2015-05-26

第十一篇:影响网页渲染的关键! 【OneAPM技术博客】

经常有站长、开发者、运维疑惑:为什么我们的后台服务器很快,但是用户要看网页里面的内容却需要很长时间?我们在上一篇文章《怪兽大作战: 解析网站打开慢的原因》中简单介绍了影响网站打开速度的几个指标,感兴趣的同学可以再读一下。今天我们主要讲一下,是哪些因素拖慢了我们的首屏加载时间,也就是用户看到网页中内容时所等待的时间。pic 1

用过OneAPM的读者对这幅图肯定不陌生,一般来讲,如果服务器很快,机房所在线路很快,那么影响用户看到网页内容的主要时间,就是最后两个时间阶段:DOM处理以及网页渲染,在这两个阶段中,浏览器需要解析网页中的各种资源并进行渲染,最终形成用户页面。这个过程是否流畅,直接影响到用户需要等待的时间,从更深层次而言,直接会影响最终的用户体验,现在大家也普遍接受一个观点“延迟就是故障”,所以你需要重视网站的加载速度。

打造轻量级的资源路径–关键渲染路

网页加载速度中最重要的概念是关键渲染路径。如果能理解好这个概念,的确可以让用户更快看到网页中的内容。

轻量级资源和路径,可以缩短复杂网页的构建和渲染时间,甚至比简单网页还要快! 由于大多数网页都包含许多不同的组成部分,仅仅移除部分资源并不能保证更快的加载速度。 如果你曾经想过:“为了提高网页的加载速度,我还能做什么?”或者“新浪、QQ、网易是如何做到在一秒钟内加载那么多网页内容的?”那么关键渲染路径这个概念正是你需要了解的。

什么是关键渲染路径?

清楚起见,让我们先定义一些概念:

关键:绝对需要
渲染:显示或者展示(在我们的情境中,网页经过渲染才能呈现给用户)
路径:使我们的网页展示在浏览器中的一系列事件
首屏:是用户滚动页面之前就能看见的部分。

因此,换言之,渲染路径就是一系列使你的网页呈现在浏览器中的事件。而关键渲染路径是呈现网页首屏所需的那些事件。因为几乎所有网站在渲染网页时都包含了不必要的步骤,而减少这些不必要的路径,能使你的网页加载速度提高几秒钟,这也是提高网页速度的最快方法。

路径

为了显示一张网页,浏览器必须获取网页所需的所有资源。一个简单的例子:一个网页需要一张图片,一个CSS文件,一个JavaScript文件。

我们来看看这张网页在展示之前经历的路径:

1, 浏览器下载html文件 2, 浏览器读取html文件,发现里面涉及一个CSS文件,一个JavaScript文件和一张图片 3, 浏览器开始下载这张图片 4, 浏览器发现不获取CSS和JavaScript文件就无法显示网页 5, 浏览器下载CSS文件并读取之,确保除此之外没有别的文件需要被访问 6, 浏览器发现不获取JavaScript文件还是无法显示网页 7, 浏览器下载JavaScript文件并读取之,确保除此之外没有别的文件需要被访问 8, 浏览器发现现在可以显示网页了

上面的路径是简单网页的加载过程。现在,试想一下你的网页加载路径会怎么样?你很可能会有几个交互按钮,数个CSS和JavaScript文件,很多图片和小插件,甚至可能还有音频或者视频文件。这意味着,你的渲染路径很可能会像一个大迷宫。大多数网站的渲染路径都极其复杂,因为浏览器在显示网页之前需要加载的文件太多。这就是你可以超过他人的地方。如果你让自己的网页加载得比竞争者的快,你就能获得访问者的青睐(百度就喜欢这样的开发者),例如新浪微博的路径就是这样的:pic2

渲染过程

在展示网页所需的众多资源中,存在一些资源会阻塞网页的渲染过程。最常见的两种资源就是CSS文件和JavaScript文件。不管你需要多少个这样的文件,浏览器必须逐一下载并分析这些文件,然后才能给用户展示内容。让我们来看一个最常见不过的场景:

WordPress博客使用主题。几乎每一个WordPress主题都包含多个CSS文件。

许多主题包含六七个CSS文件。所有的CSS文件都可以合并到一个文件中,但是当你添加主题时,会包含多个CSS文件。因此,在你的博客显示哪怕一个字之前,浏览器都不得不经过六七次的与服务器交互,把这些文件一个个地下载下来,并分析读取,之后才能开始显示。

在加载的过程中,访问者都只能看到一篇空白的屏幕。因为只有当关键步骤完成以后,才会有东西显示。

但是,即便下载完这些CSS文件,你的博客还是不能完成渲染。因为WordPress主题还需要几个JavaScript文件。

因此,渲染一页典型的WordPress博客网页,需要浏览器与服务器交互大约20次,才能将主要的CSS和JavaScript文件下载完毕。但是,等等,现在你还需要交互按钮,小插件……噢,不,针对每一个这样的部件,你还要下载几个CSS,JavaScript文件。

你可能要下载几十个文件,才能让自己的博客展示在用户面前。真是麻烦!(去查查你的网页都要加载什么文件,可以使用OneAPM 的SessionTrace 功能看看网页加载资源在用户那里的速度)

但是事情不仅限于WordPress,本文只是拿它举个例子而已。通常创建网页的初始视图都很多资源,因此会产生多个请求。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/OneAPM-technology-blog%202947

作者:OneAPM_王鹏     发表日期:2015-05-22

第十二篇:Vue.js 0.12 发布 【Vue.js 中文入门】

很久没更新了,其实 Vue 0.12 发布有段时间了,如果你没有 follow Vue.js 的 twitter 账号或者不常看 GitHub 的话,这里是 0.12 的一些简略更新:

更整洁的组件语法

  • 不再推荐使用 v-component 和 v-with ;组件统一推荐使用自定义元素风格;

  • 组件名不再要求必须含有短横;

  • 数据传递统一使用 props 选项(0.11 的 paramAttributes)。

  • 可以精确地指定 props 的数据绑定方式:单向,双向,或是一次性。

  • 可以对 props 进行运行时类型检查。

以后组件的调用大部分时候长这样:

<my-component prop="{{parentData}}"></my-component>

动态组件使用特定的 <component> 标签:

<component is="{{componentId}}"></component>

过滤器参数语法改进

原本的过滤器参数是全部当做字符串传入过滤器函数里的,现在默认视作动态数据,只有包在引号里的参数才会作为字符串传入:

{{ msg | filter a 'b' }}

这里传入 filter 函数的参数依次为:vm.msg 的值, vm.a 的值, 字符串"b"

异步组件

定义组件时,可以提供一个异步的组件加载函数:

Vue.component('async-example', function (resolve, reject) {
  setTimeout(function () {
    resolve({
      template: '<div>I am async!</div>'
    })
  }, 1000)})

组件会自动在加载函数调用 resolve 回调后才渲染。此功能可以配合 $.getScript, AMD/Require,js,或是 Webpack 使用:

Vue.component('async-example', function (resolve, reject) {
  // 利用 webpack 自带的代码分割功能  require(['./my-async-component'], resolve)})

加强动画系统

  • CSS transition 和 JS transition 现在可以混合使用,暴露的 JS 钩子函数也更多了。

  • v-repeat 可以通过简单地添加一个 stagger 属性来实现渐进动画;也可以通过 JS 钩子函数自定义渐进的时间差。

性能提升

  • 大列表首屏渲染速度提升最高达 40%,内存使用量也减少将近 40%

  • 新增 track-by=”$index”,大列表新数据重绘速度超过 React。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Vuejs-Chinese-entry-Vuejs-012-release%203035

作者:尤小右     发表日期:2015-06-25


第十三篇:《web前端最佳实践》—高性能css 【前端家园】

性能,这个词如今被炒的很热,也是每个开发者,由“知道”、“会做”之后必经的一个“怎样做好”的阶段。性能关乎用户在不同设备和不同网络状态下的体验。也被多方面因素所影响。此文说说css方面怎样做到高性能。

高性能css

Html和css本身的性能问题并不突出,在提高可读性和可维护性的前提下,如果能让代码运行和解析的速度更快,则是锦上添花了。

一、使用高效css选择器

简单来说,能被浏览器快速解析和匹配的css选择器,就是高效的选择器。

首先要知道浏览器如何解析css

举个例子:.nav ul.list li div{}

我们常见的思维是,先去找到nav这个类,再找类包含的ul,再找ul中类为list的后代所有li中所有的div,简而言之,就是从左到右。可事实是这样么?么?么?~

事实是相反的!意味着什么呢?就是说它不是从第一个开始去慢慢的缩小范围,而是从div这个“裸奔”的盒子开始,相当于遍历,然后再找到li,以此类推,好吧不用我形容你应该知道这当中的消耗。理解这一原理非常重要,高效的选择器意味着匹配更快,查找次数更少。所以我们定义选择器时,应该让第一次匹配时的数量达到最少,并且让整体的匹配查找次数最少。

以上这些解释恰恰遵循了这样一些原则

(1)避免使用通配符

(2)避免使用标签选择器和单个属性选择器作为关键选择器

(3)不要在id选择器前加标签名

(4)尽量不要在选择符定义过多层级,层级越少,同时也降低了css和dom结构的耦合程度,提高样式的可维护性

(ps:老实说上面的这些“禁忌”你是不是都有犯过?~)

做个小结,以上所说,有两点需要知道,第一点在开头就已经提到,css的性能问题表现的并不突出,特别是在小项目中,所以,可维护性为先;第二点是虽然定义id选择器,有唯一性的优势,但是一个页面只能定义唯一id,定义过多id会使重用性降低,维护更困难,所以不建议多用id。

二、css相关的图片处理

现在的网页当中,图片所占的比重以及它的重要性大家都知道。那么如何处理好图片以及如何为图片设置样式,才能让用户打开网页时体验更好呢?下面给出一些意见:

(1)不给图片设置尺寸

在我个人的从业经历当中,有过这样的情况,我按照设计稿做好了页面,交给后台去测试,他就突然跑过来跟我说:hi,你看,这儿出状况了,我一看,坏菜,图片出格了,我才想起没有给图片定义宽高(直接从设计稿里切的也不需要),然后就犯错了似的在css样式里定义了宽高。以至于后来我把这个作为下次再做页面时候的注意事项。当我看到这一条意见的时候,才更知一二。

来看解释,第一、设计人员为了画面的精美,会制作一些超出需求尺寸的图片;第二、同一张图片可能会在页面不同地方多次使用,比如缩略图、正常图、大图。问题来了,如果图片原始尺寸和实际需求不同,在使用过程中就会存在性能问题,利用样式缩放会带来cpu的额外计算过程,增加了图片在浏览器的渲染时间,网络传输过程也会占更多带宽,增加下载时间。因此,最佳做法是,为需要的部分单独做一套图片,初始页面加载时就能更快展示。

(2)使用css“雪碧图“

是将零散的图片合并成一张大图,在利用css进行背景定位。好处是减少请求数,提高了图片整体的加载速度。

但它也存在一些缺点:

比如,多张图片合并成大图,需要精确计算,仔细的调整位置,单纯手工制作是一件很复杂的事情。(所幸现在有一些工具可以帮我们做)

另外,维护过程复杂,要尽量让已有的图片保持原来的位置不变,如果是背景图的尺寸发生变化导致原有区域无法放置,那就只好放弃,如果非要在原有位置修改,则剩余的图片样式都需要修改,是很繁琐的过程。新加的图片最好放在最后面。

还有就是使用不当会导致性能问题,最大的问题就是内存消耗。如果制作过程不做任何的规划,随意摆放,则可能会使图片变得相当大,从而很占内存。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Front-end-home-best-practice-in-front-of-the-web-high-performance-CSS

作者:灵感_idea     发表日期:2015-04-04

第十四篇:“NodeJS在大搜车” 之 MVC基础结构 【大搜车前端团队专栏】

长长而且无关的前言

经常会有同学来问我前端是否适合向NodeJS方向发展,其实大多数时候我是拒绝的,为什么呢?其实前端接触一下NodeJS这个东西本身我是不排斥的,毕竟是基于JS,能够掌握一门手艺,拓展一下自己的技术视野,然后写一些读写文件,grunt插件之类的工具,也是极好的。我所谓的拒绝,主要是基于很多同学并非如此考虑,很多同学想借NodeJS轻轻松松的把魔爪伸向纯服务端开发,NodeJS本身对于前端来说是极其容易掌握的,照着文档写一个服务器也是极其简单的,很多同学觉得自己一下子跨进了服务端开发的大门,然而,真是如此么?

现在很多技术方面的营销文,荼毒!让新人变得也浮躁起来。

在我看来,如果我面前有一个牛逼的前端和牛逼的PHP工程师,让我选一个来转型NodeJS服务端开发,我会毫不犹豫的选择PHP。这样我需要做的就是让他去看一个周的JS语法,给他花一天讲解下callback(对php,java,ruby来说这个的确很难理解),花一点时间熟悉下nodejs的模块和写法。然后下面就很顺畅了。

而对于一个前端,好喽,麻烦喽,以为服务端开发只是简单的堆积业务么?服务端逻辑那么紧密,如何hold住?服务端跟其他系统之间的耦合,如何hold住?整体业务的把握,请求量太大天天挂,IO瓶颈了如何搞定,缓存该怎么用,应用架构如何设计,分层如何设计,数据库如何优化,代码如何调试,如何分析内存泄露,单元测试写没写过,HTTP原理了解多少,Nginx配置服务器部署知道几何,性能监控跟踪呢?

扯远了。

其实我本来只是想说一下服务端开发思维在NodeJS开发方面也是非常重要的,而今天要分享的就是其中重要的一部分:MVC。

在写NodeJS之前,我写过一阵Java,基于spring框架,所以思维中对MVC模式也算有个比较简单的理解,所以在构建NodeJS框架的过程中,多少带入了一点Spring的思维。

基本要素:

1. Controller,Model,View。

三要素啦,不用质疑,再复述一遍。

Controller ,负责业务逻辑的控制,是中枢,连接数据和视图之间的关系。不过controller一般不会直接操作数据,这中间需要再加一层,这个后面说。所以一个干净的controller里,应该调用各方数据,最后组装成一个可用的数据,最后把数据传给视图。

Model,从概念上来说,Model就是一个数据层,不过在我们的NodeJS项目中,Model是通过一个ORM抽象成对象的,变成了实体定义,这个也是后面具体讲。

View,视图层,一般通过模板引擎把数据渲染成动态的页面,我们公司统一使用Jade,Jade的结构严格清晰,速度也够快,功能够丰富,无它。

2. Service

这个名字是从Spring里面学过来的,感觉Service这个词本身就很能代表这个分层所担当的角色,那就是服务层。

什么是服务呢?它凌驾于数据层之上,对数据操作进行抽象,通过服务类型抽象成不同的服务,提供给不同的业务调用。例如在我们公司最基础的几个服务:车辆数据服务,用户数据服务,推送服务,搜索服务。这些服务大部分不是单纯的操作某个数据表之类的,而是在顶层的封装,因为车辆相关的业务可能有很多数据表,例如车辆基础信息,车辆审核信息,各种状态变更记录等一系列数据表,而且会横跨在mysql,mongodb,以及redis缓存之间的各种逻辑。我们把种种数据操作通过service层完全隐藏起来,把数据操作变成了一个个针对车辆的“操作”。这就是service最后提供出来的功能:“操作”。

所以说,其实service层是整个架构中最重的一层,大部分业务逻辑都集中于这一层。

每个请求进来,进入controller的时候,controller就会调用各个service来拼装服务数据,最后把数据返回给前端。到此,其实service层是做什么的,为什么有其存在的必要就很清楚了。

这里注意一点,一个清晰的MVC里,controller里不应该有任何直接对数据库的操作,所有操作都调用service层来操作数据,这样controller才能称为一个“干净的controller”。

3. Route

咦,奇怪的一层,Route跟controller有啥区别?怎么说呢,很难分清。controller是每个请求进来之后处理的逻辑,而route则定义了请求应该进入那个controller。

这里把Route单独拿出来说,只是为了展示下我们是如何管理Route的。那就是我们自己修改过的一个小库:rainbowy。

这个玩意的作用是:用文件目录结构自动生成route。恩就是这么简单,然后我们给他集成了一些小特色,例如在route中直接定义接口文档,然后最后汇总生成一个api文档汇总页面,供前端自己模拟请求接口。

具体文档和代码见:https://github.com/xinyu198736/rainbow

我们不是用包的方式引入的,而是直接内置到项目lib里,所以这里不能保证及时更新,其实原理很简单。

不要小看这种route管理方式,当route变得成百上千的时候,文件夹嵌套的方式就变得非常实用了,可以快速定位到某个业务代码中。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Front-team-search-car-front-team-NodeJS-in-search-car-MVC-basic-structure%202985

作者:芋头     发表日期:2015-06-09

第十五篇:Angular 2.0 和 1.x比较 【AngularJS乱炖】

奥斯本效应

Angular团队面临着这样的问题:如何在不影响1.x版本使用的情况下谈论很多2.0的高级新功能。这就是奥斯本效应,上个世纪80年代的电脑公司,终因市场源于而歇业后命名。简而言之,2.0版本听起来越好,就越少有人去使用1.x版本。不同的是,Angular 2.0版本已经可以从github上通过npm install angular@2.0.0-alpha.6 得到它了。但是,这个不能用于生产,它还在被大量的修改。

Angular 1.x vs. 2.0

为什么Angular团队会做出如此大得变化的原因是什么呢。Angular不只是试图跟上,他们还推动了大量的标准的应用,增强了现有的应用架构。

双向数据绑定

2.0 单向数据绑定

在大型项目中,双向数据绑定会被使用的像意大利面条一样。Angular 2.0引入了无回路有向图的单向结构概念。

这听起来很像React的Flux所做的工作。这种结构也可以被Angular来使用。

虽然双向绑定会消失,Angular创始人Misko已经声明:2.0中会有方法实现双向绑定,虽然实现的背后数据是单向的。

观察器

2.0:Zone.js

$scope.$watch, $scope.$apply, $timeout这些都不在需要了,这也是1.x版本有如此之大的学习曲线的原因。

Zone.js可以帮Angular实现变化的自动检测。这听起来很像React的差异比较算法。

Angular团队解释道,现在的变化检测更快了,内存更小了,同时也更加强大了。变化检测的性能可能随着将来的object.observe的到来而有更大的提升。

Zone.js同时支持不变对象,这样检测的速度上会有更大的提升。这是因为编译器会认为数据对象不会变化从而进行优化。

组件通信

2.0:除了$broadcast 和 $emit,2.0还有一些小得变化,1)你可以在DOM层发送消息,而不是在scope;2)你可以组件嵌套,然后link他们,这看上去很像每个组件都使用它们独立的scope。

DOM

2.0:从很多方面可以看出,Angular 2.0对于DOM样式的操作很像React的virtual DOM,它引用的是最近呈现的view层。关于Angular Native,Misko提到,这个view层可以运行于web worker,甚至是native。

scope

数据将会被组织成树形结构

Angular 2.0也会使用web组件标准。比如,shadow DOM可以用来创建独立的scope。Angular团队解释到,2.0会有一个shadow DOM模拟模块(当前浏览器还不支持web组件),这将给独立css提供新的选择,很酷不是么!

模块

2.0:2.0将肯定使用ES6的模块语法。同时,2.0还希望通过懒加载来引入依赖注入。和以往通过单例方式管理不同的是,2.0希望使用一种层次化数据结构来提供继承特性。你将能够控制模块的生命周期,比如services。

指令

2.0:现在将被成为“组件”。在1.x版本中,指令在大型项目解决冲突中随处可见。但是在2.0中,你必须导入你的组件才能去解决初始化中得命名空间冲突问题。虽然我不明白它是如何工作的,但是2.0将会创建一个原型模板用于潜在的绑定以优化编译器速度。

Router

2.0:虽然没有1.x里面不稳定的懒加载特性,但看上去应该是从1.x版本移植过来的。

Brian Ford发了一篇关于新路由的介绍,值得我们关注下。他描述了一个新的路由如何能够同时工作于1.x和2.x版本,这就允许团队逐渐的过度到新的版本中。他同时建议使用当前流行的ui-router来迁移地址。Ui-router很不错,但是缺少一些重要的特性。比如,解析只能在页面加载之后才能传递参数。但是如果你想在到下个页面之前去校验form表单中当前的数据咋办呢?Ui-routers的解析是一次性触发的。相反,新的router会提供一个钩子,允许你在制定地方做一些你想要的动作。

HTML

2.0:虽然语法看上去有些不一样,但是记住,在这背后肯定是有一定好的原因的。

ng-指令

HTML中得组件被拆分魏两种类型:(事件)和[属性]。他们被包装在圆括号和中括号中,这样肉眼和机器都能识别了,从而可以优化这两种类型。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/AngularJS-mass-Angular-2-and-1x-comparison

作者:jnotnull     发表日期:2015-03-09

第十六篇:Webpack,101入门体验 【webpack】

最近在看许多React的资料,发现了大部分的项目都是用webpack行模块化管理的工具。这次也是借着写了一个React-Todos的小应用,对webPack最基本实用的功能体验了一番,顺带做个小记录。

为什么用webpack


CommonJs与AMD

在一开始,我们先讲一下它和以往我们所用的模块管理工具有什么不一样。在最开始的阶段,Js并没有这些模块机制,各种Js到处飞,得不到有效妥善的管理。后来前端圈开始制定规范,最耳熟能详的是CommonJs和AMD。

CommonJs是应用在NodeJs,是一种同步的模块机制。它的写法大致如下:

var firstModule = require("firstModule");//your code...module.export = anotherModule

AMD的应用场景则是浏览器,异步加载的模块机制。require.js的写法大致如下:

define(['firstModule'], function(module){

    //your code...    return anotherModule})

其实我们单比较写法,就知道CommonJs是更为优秀的。它是一种同步的写法,对Human友好,而且代码也不会繁琐臃肿。但更重要的原因是,随着npm成为主流的JavaScript组件发布平台,越来越多的前端项目也依赖于npm上的项目,或者自身就会发布到npm平台。所以我们对如何可以使用npm包中的模块是我们的一大需求。所以browserify工具就出现了,它支持我们直接使用require()的同步语法去加载npm模块。

当然我们这里不得不说的是,ES2015(ES6)里也有了自己的模块机制,也就是说ES6的模块机制是官方规定的,我们通过babel(一种6to5的编译器)可以使用比较多的新特性了,包括我们提到的模块机制,而它的写法大致如下:

import {someModule} from "someModule";// your codes...export anotherModule;

当然上面的写法只是最基本的,还有其他的不同加载模块的写法,可以看一下阮一峰老师的ECMAScript 6 入门或者babel的相关文档Learn ES2015

功能特性

browserify的出现非常棒,但webpack更胜一筹!

我们来看看webpack支持哪些功能特性:

  1. 支持CommonJs和AMD模块,意思也就是我们基本可以无痛迁移旧项目。

  2. 支持模块加载器和插件机制,可对模块灵活定制。特别是我最爱的babel-loader,有效支持ES6。

  3. 可以通过配置,打包成多个文件。有效利用浏览器的缓存功能提升性能。

  4. 将样式文件和图片等静态资源也可视为模块进行打包。配合loader加载器,可以支持sass,less等CSS预处理器。

  5. 内置有source map,即使打包在一起依旧方便调试。

看完上面这些,可以想象它就是一个前端工具,可以让我们进行各种模块加载,预处理后,再打包。之前我们对这些的处理是放在grunt或gulp等前端自动化工具中。有了webpack,我们无需借助自动化工具对模块进行各种处理,让我们工具的任务分的更加清晰。

我们看一下官方对webpack理解的图。

enter image description here

任何静态资源都可以视作模块,然后模块之间也可以相互依赖,通过webpack对模块进行处理后,可以打包成我们想要的静态资源。

既然已经大致知道为什么我们要使用webpack了,我们接下来就开始使用webpack吧!

开始使用webpack


首先新建一个webpack101的项目,我们将在webpack101这里开展我们接下来的各项学习。

$ npm init // 用于初始化项目的package.json//初始化文件目录:webpack101    --- src        --- entry.js        --- module1.js    --- index.html    --- package.json    --- webpack.config.js

安装webpack

我们通过npm来将webpack安装到全局

$ npm install webpack -g

一个最简单的webpack

webpack配置

webpack是需要进行配置的,我们在使用webpack的时候,会默认webpack.config.js为我们的配置文件。所以接下来,我们新建这个js文件。

// webpack.config.jsvar path = require("path");module.exports = {
    entry: '../src/entry.js', //演示单入口文件    output: {
        path: path.join(__dirname, 'out'),  //打包输出的路径        filename: 'bundle.js',              //打包后的名字        publicPath: "./out/"                //html引用路径,在这里是本地地址。    }};

编写入口文件

接下来就编写我们的入口文件entry.js和第一个模块文件module1.js。我们一切从简,里面只用来加载一个Js模块。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Webpack%203009

作者:Yika     发表日期:2015-06-18

第十七篇:【译】15个必须知道的chrome开发者技巧(GIF) 【前端分享】

在Web开发者中,Google Chrome是使用最广泛的浏览器。六周一次的发布周期和一套强大的不断扩大开发功能,使其成为了web开发者必备的工具。你可能已经熟悉了它的部分功能,如使用console和debugger在线编辑CSS。在这篇文章中,我们将分享15个有助于改进你的开发流程的技巧。

一、快速切换文件

如果你使用过sublime text,那么你可能不习惯没有Go to anything这个功能的覆盖。你会很高兴听到chrome开发者功能也有这个功能,当DevTools被打开的时候,按Ctrl+P(cmd+p on mac),就能快速搜寻和打开你项目的文件。

二、在源代码中搜索

如果你希望在源代码中搜索要怎么办呢?在页面已经加载的文件中搜寻一个特定的字符串,快捷键是Ctrl + Shift + F (Cmd + Opt + F),这种搜寻方式还支持正则表达式哦

三、快速跳转到指定行

在Sources标签中打开一个文件之后,在Windows和Linux中,按Ctrl + G,(or Cmd + L for Mac),然后输入行号,DevTools就会允许你跳转到文件中的任意一行。

另外一种方式是按Ctrl + O,输入:行数,而不用去寻找一个文件。

四、在控制台选择元素

DevTools控制台支持一些变量和函数来选择DOM元素:

  • $()–document.querySelector()的简写,返回第一个和css选择器匹配的元素。例如$(‘div’)返回这个页面中第一个div元素

  • $$()–document.querySelectorAll()的简写,返回一个和css选择器匹配的元素数组。

  • $0-$4–依次返回五个最近你在元素面板选择过的DOM元素的历史记录,$0是最新的记录,以此类推。

想要了解更多控制台命令,戳这里:Command Line API

五、使用多个插入符进行选择

当编辑一个文件的时候,你可以按住Ctrl(cmd for mac),在你要编辑的地方点击鼠标,可以设置多个插入符,这样可以一次在多个地方编辑。

六、保存记录

勾选在Console标签下的保存记录选项,你可以使DevTools的console继续保存记录而不会在每个页面加载之后清除记录。当你想要研究在页面还没加载完之前出现的bug时,这会是一个很方便的方法。

七、优质打印

Chrome’s Developer Tools有内建的美化代码,可以返回一段最小化且格式易读的代码。Pretty Print的按钮在Sources标签的左下角。

八、设备模式

对于开发移动友好页面,DevTools包含了一个非常强大的模式,这个谷歌视频介绍了其主要特点,如调整屏幕大小、触摸仿真和模拟糟糕的网络连接

·················

阅读全文请点击原文链接:http://www.html-js.com/article/The-front-end-to-share-translation-15-must-know-the-chrome-developer-skills-GIF%203003

作者:凯凯刘     发表日期:2015-06-16

第十八篇:《web前端最佳实践》—高维护性css 【前端家园】

有人说html很简单,它甚至不被认为是一种真正的编程语言,当然还有另一个技术同样被类似的看待,它就是css。说实话,css的代码的确不复杂,如要要会简单的使用你只需要知道它是什么,然后任何一个人都能够轻松的用它来控制一个元素的宽高,内容字体的类型、大小、颜色等等。但它真的不只是一些规则。 就像是同样认识字,会写字,但总有人能写出更好的文章一样。会用和科学的用,灵活的用仍然有距离。这篇文章来谈谈css中一些可能的最佳实践方法。

高维护性css

Css有些什么特点?

简单来说,使用方式:内联、内嵌、外联、import。为元素设置样式的方式:元素标签名、类名、id、各种选择器,以及它们的组合。所以,它是很灵活的,如果不做任何的规范的限制,就肯定会导致css代码的混乱和难以维护。

如何高效组织css代码?

结构清晰、模块分明,合理的代码组织结构可提高代码的重用性和可维护性,降低开发复杂度。那怎样组织呢?

首先是组织代码文件,可分为两大类:通用类和业务类。 然后,有一个文件用来重置,常见命名是reset或者default、normalize等。

有一个文件用来存放通用模块和一些基础样式,常命名为mod、common等,如页面对话框,提示框,头部,底部,侧边栏等,会在多个页面用到,这样方面各页面引用,提高代码复用度。

另外需要一个文件存在兼容旧版IE浏览器的样式,这样做的好处有二:

一、减少非IE浏览器加载样式文件的负担

二、如果未来决定不再支持旧版的IE浏览器,则只需要去修改一个文件,不需要多个文件到处找去修改。当然,在处理浏览器兼容问题上,有个原则是,是否有其他不存在兼容问题的方案,如果没有,则把要做兼容的部分单独放在一个文件中。

其余的css样式文件则用于业务模块,不同模块的样式文件放置于不同的文件夹中,原则上每个模块的样式文件不宜太大。

这样可能会造成一个问题,一个页面不是要引入很多文件了?页面加载的时候http请求不是多很多?其实并不矛盾,文件的划分只是为了方便开发和维护,发布的时候会使用工具把多个文件压缩合并成一个文件,所以不用担心引入多个文件的问题。

上面说的是文件的组织,那么在文件中也要按照一定规则来组织样式的声明。 比如,按照模块中元素的层级,如果是同级,则按照元素在页面中的位置,从上到下,或者从左到右,若存在多个元素共用相同声明,则应先声明共通样式。 如果觉得这样还不够,则可以使用一些更高级的方式,如less、sass,它们将css赋予了动态语言的特性,如变量、继承、运算、函数等。

以上是从几个大的方向去说的,下面涉及某几个点谈一谈

使用css reset 统一浏览器显示效果

首先,html的标签是有原始样式的,但问题是在不同浏览器中,标签的默认样式不尽相同,其中的某些差异给开发造成了麻烦,早在2004年,就有人开发了第一个重置样式文件,叫undohtml.Css,后续又有了多种重置方案,其中有个方案“火爆一时”,此方案总共就一行代码*{margin:0;padding:0;}。重置了所有标签默认的margin、padding样式,但有一个弊端是增加了后续开发的复杂度,并不能很有效的提高整体开发的效率。另外,此方案性能也不佳,当页面元素很多时就会影响页面渲染的性能。所以,人们还在逐渐的探索更好的重置方式,目前有多个流行的重置方案,有Eric Meyer开发的Reset CSS和雅虎公司前端技术团队开发的YUI Reset CSS。其实并不存在一种方案适合所有项目,所以最好还是选择参考别人的方案然后设计一套适合自己项目的方案。

需要考虑如下几点:

(1)HTML5新标签 需要重置它们的display样式,因为在低版本IE中没有定义它们的默认display样式。

(2)padding、margin、border 标签在浏览器中的差异主要是与这三个样式有关的默认样式产生的,但也不是需要重置全部元素的margin、padding、border,应根据实际情况。

(3)字体设置 <h1>~<h6><strong><em>等语义化标签都有默认字体,但实际当中所需要的字体大小或者粗细都跟默认不同,所以一般项目中都会对他们进行重置。

(4)其他元素的样式重置 典型的有li默认的列表项样式,table的单元格之间默认空间,a链接的下划线等。

给css定义排序

Css的逻辑性不强,随意的书写也不影响其作用,如果不借助工具对其排序也会很繁琐,所以,很少有人会在意,但是排序还是有好处的。

比如:

1、更整洁

2、防止重复定义

3、能够清晰查看定义

4、后续维护能快速定位

排序方式:

1、按类型 如,显示和浮动、定位、尺寸、字体等

2、按字母 按字母顺序排列,优点是规则简单

3、按定义长度 按照样式定义的字符长度排列

各有优劣,实际应用中,推荐使用第一种。 但是如果单靠前端工程师在编写过程中这么做的话也是很难的,可以在写的过程中按照效率最高的方式写,提交代码时使用工具为css排序。既提高效率,又方便后续代码阅读和维护。有一款免费工具是 CSScomb。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/The-front-end-of-the-frontend-Web-Best-Practice–CSS-home

作者:灵感_idea     发表日期:2015-03-28

第十九篇:一个月时间整理《深入浅出Node.js》 【小前端tw93】

今天终于把朴灵老师写的《深入浅出Node.js》给学习完了, 这本书不是一本简单的Node入门书籍,它没有停留在Node介绍或者框架、库的使用层面上,而是从不同的视角来揭示Node自己内在的特点和结构。建议有一定Node基础或者做过Node方面的小项目的同学阅读,看完以后你的思维会有很奇特的碰撞,我看的时候就常常会有这样的想法:“哦,原来这个功能是这样实现的哦”。下面这篇文章是我第二次阅读《深入浅出Node.js》的一些学习记录,并且通过百度脑图这个工具来画出思维导图,每天将自己的学习总结写在这篇文章下面。

新增原始文件脑图地址,这样大家就可以直接到脑图去看思维导图,建议新标签页打开

Node简介

这一章简要介绍了Node,从中可以了解Node的发展历程及其带来的影响和价值。

为什么叫Node?起初,Ryan Dahl称他的项目为web.js,就是一个Web服务器,但是项目的发展超过了他当初单纯开发一个Web服务器的想法,变成构建网络应用的一个基本框架,这样可以在它的基础上构建更多的东西,诸如服务器、客户端、命令行工具等。Node发展为一个强制不共享任何资源的单线程、单进程系统,包括十分适宜网络的库,为构建大型分布式应用程序提供了基础设施,其目标也是成为一个构建快速、可伸缩的网络应用平台。它自身非常简单,通过通信协议来组织很多Node,非常容易通过扩展来达成构建大型网络应用的目的。每一个Node进程都构成这个网络应用中的一个节点,这是它名字所含意义的真谛。 脑图

Node简介

模块机制

这一章主要介绍Node的模块机制,从中了解到Node如何实现CommonJS模块和包规范的。在这一章中,我们详细的解释了模块在引用过程中的编译、加载规则。另外,我们还能读到更深度的关于Node自身源代码的组织架构。 
CommonJS规范为JavaScript定制了一个美好的愿景—希望JavaScript能够在任何地方运行。
脑图Node模块机制

异步I/O

这一章展示了Node中我们将异步I/O作为主要设计理念的原因。另外,还会介绍到异步I/O的详细实现过程。 
事件循环是异步实现的核心,它与浏览器中的执行模型基本上保持一致。而向古老的
Rhino{:target="_blank"},尽管是较早就能在服务器运行的JavaScript运行时但是执行模型并不像浏览器采用事件驱动,而是使用像其他语言一样采用同步I/O作为主要模型,这造成它在性能上面无法发挥。Node正是依靠构建了一套完善的高性能异步I/O框架,打破了JavaScript在服务器止步不前的局面。 脑图

Node异步I/O

异步编程

这一章主要介绍异步编程,其中最常见的异步编程问题介绍,也有详细的解决方案。在这一章中我们可以接触到Promise、事件、高阶函数是如何进行流程控制的。 (这一章建议多看书)脑图 
Node异步I/O

内存控制

这一章主要介绍了Node的内存控制,主要内容有垃圾回收、内存限制、查看内存、内存泄漏、大内存应用等细节。 
Node将JavaScript的主要应用场景帮到了服务器端,相应要考虑的细节也与浏览器端不同,在服务器端,资源向来是寸土寸金,要为海量用户服务,就使得一切资源都要高效循环利用,需要更严谨为每一份资源作出安排。
脑图

Node内存控制

理解Buffer

这一章主要介绍了前端JavaScript里不能遇到的Buffer。由于Node中会涉及频繁的网络和磁盘I/O,处理字节流数据会是很常见的行为,这部分的场景与纯粹的前端开发完全不同。 
体会过JavaScript友好字符串操作后,有些开发者可能会形成思维定势,将Buffer当作字符串来理解。但字符串与Buffer之间有实质性的差异,即Buffer是二进制数据,字符串与Buffer之间存在编码关系。因此,理解Buffer的诸多细节十分必要,对于如何高效处理二进制十分有用。
脑图

·················

阅读全文请点击原文链接:http://www.html-js.com/article/The-little-front-end-tw93-a-month-finishing-explain-profound-theories-in-simple-language-Nodejs

作者:tw93     发表日期: 2015-03-23

第二十篇:前后端数据交互方法 【Nimojs | 前端开发】

好像出 bug 了,你可能是要看

在此介绍几种常用的前后端数据交互方法,并给出使用建议。以提高前后端协同开发的效率。 
此文章适合前后端协同开发经验不足的新手阅读。

目录:

  1. HTML赋值

  2. JS赋值

  3. script填充JSON

  4. AJAX获取JSON

  5. WebSocket实时传输数据

  6. 总结

HTML赋值

输出到 Element 的 value 或 data-name

<input type="hidden" value="<?php echo $user_avatar;?>" /><div data-value="<?php echo $user_avatar;?>"></div>

渲染结果

<input type="hidden" value="https://avatars1.githubusercontent.com/u/3949015?v=3&s=40" /><div data-avatar="https://avatars1.githubusercontent.com/u/3949015?v=3&s=40"></div>

使用 JS 获取

$('input').val();// http://jquery.bootcss.com/jQuery.data/$('div').data('avatar');

优点: 
不占用全局变量,由 JS 自由获取。

使用建议:

适合传递简单数据,也非常适合多个简单数据与 Element 绑定关系。

<ul><li>nimojs <span data-userid="1" >删除</span></li><li>nimo22 <span data-userid="2" >删除</span></li><li>nimo33 <span data-userid="3" >删除</span></li><li>nimo44 <span data-userid="4" >删除</span></li><li>nimo55 <span data-userid="5" >删除</span></li></ul><script>$('span').on('click',function(){
    $.post('/ajax/remove/',$(this).data('userid'),function(data){
        // ...    })})</script>

JS赋值

将数据填充到 <script> 的 JavaScript 变量声明中。

<script>var user_avatar = "<?php echo $user_avatar;?>";// 渲染结果// var user_avatar = "https://avatars1.githubusercontent.com/u/3949015?v=3&s=40";</script>

或使用 Smarty 后端模板引擎:

<script>var user_avatar = "{$user_avatar}";</script>

优点: 传递数据非常方便。前端直接调用 user_avatar 变量使用数据。

缺点: 1. 为了传递一个字符串数据占用了全局变量 user_avatar,当有很多数据需要传输时则会占用很多全局变量。 2. 如果返回数据存在换行将会导致JS报错

// 渲染结果有换行符var user_id = "

https://avatars1.githubusercontent.com/u/3949015?v=3&s=40";// Uncaught SyntaxError: Unexpected token ILLEGAL

优化: 
可以通过指向的某一个变量存放所有后端返回的内容,最小程度占用全局变量。例:

// PHP 代码var SERVER_DATA = {
    username: {$username},
    userid: {$userid},
    title: {$title}}// 渲染结果var SERVER_DATA = {
    username: "NimoChu",
    userid: 1,
    title: 'F2E'}

使用建议: 
需要最快速度传递数据给 JS 并十分确定此数据稳定时,使用此方式。数据格式复杂的建议使用script填充JSON 或AJAX获取JSON 方法。

script填充JSON

什么是JSON?

填充 JSON 数据到 <script> 标签中,前端通过 DOM 获取 JSON字符串并解析成对象。

·················

阅读全文请点击原文链接:http://www.html-js.com/article/Nimojs–frontend-development

作者:nimo     发表日期: 2015-03-09

【说明】

2015年最受欢迎的20篇原创技术文章均来源于:@前端乱炖

原文链接:http://www.html-js.com/static/htmljs-year-2015.html

本篇文章由 HTML5梦工场 小编从其他媒体精选前端相关文章转载,仅供网友学习和交流,如果小编的工作有侵犯到您的权益,请及时联系小编QQ:123464386,将会在第一时间进行处理!投稿与合作,请发至邮箱:tommy@html5dw.com