记得是2005年，但也许更早，前端工程师这个职位开始在中国出现。如果再往前推，CSS的发展不过是十几年，HTML也才是个20岁风华正茂的小伙子。现在HTML5和CSS3，带来了诸多新的变革，web发展是日新月异还是略显老态？

浏览器路向何方？

曾经名赫一时的各种壳浏览器还剩下多少呢？像 IE green browser 这样的壳还有人在用么？主流里剩下了遨游，世界之窗，以及一干插足者。360和世界之窗的合作生出来个360浏览器，凭借360客户端数量和安全的旗号割据一方。搜狗打出了双核的旗号也同样凭借着输入法的装机量分到了自己的一杯羹。腾讯，仍旧是凭借其QQ加以推广。也许后来者还会有百度和阿里巴巴，今天的新闻又看到一个新的插足者——金山。

这种混乱的局面以前也曾经出现过，但过往的各种壳的特点是草根气息，现在的壳却都是大腕在暗自部署他们的客户端。但对普通用户来说，浏览器其实都是类似，他们不关心能不能用方便的插件，他们可能更关心隐私和安全，这也是360成功的原因。双核可能是个趋势，webkit被加壳后的影响是广泛的，更多的网站需要考虑兼容标准而不仅仅是IE。这几年，非常欣喜地看到整个Web向标准大幅迈进，但是这么多搅局的浏览器又让前景显得扑朔迷离。

通常，测试仅仅围绕内核，但是总是会有壳浏览器莫名奇妙不一致的时候。对于双核浏览器这种倾向更加的明显。有的时候我也在想，是不是三核浏览器也会加入新的力量？Lunascape那号称全球唯一的三核浏览器，其名号也就不能标榜的如此显眼了:)

各种壳，伴随这各种势利的目的应运而生。他们的内核，无非是Trident，以及webkit。就像Adobe的AIR选择了Webkit一样，它们的第二核也同样选了webkit。这并不是巧合，webkit的开放和快速，开源软件的生命力可能正是其崛起的关键。随着时间的流逝，将来这些壳会剩下多少呢？

这种核，素来已久地继续着他们的发展。四大排版引擎，Trident(IE)、Gecko(Firefox, Seamonkey)、WebKit(Safari, Chrome)以及Presto(Opera)之间的共存渐渐在失去平衡。我记得以前听到过这么一句话，桌面操作系统只会有两个，一个是Windows，另一个是Unix/Linux。这样的话用在浏览器内核一样是合适的。即使出现了第五种挤入主流的内核，其近况可能也和现在的Opera无异。所以Google没有写新的内核，而是进驻了webkit社区。如此以来技术上的天平出现了第一次真正意义上的倾斜，使得webkit成为了当今发展最快的内核。

Trident 划江而治，WebKit 则趁势而起。Gecko 继续尽心尽责地支持着标准，Presto 则继续边缘化。我觉得他们一个都不会倒下，IE不会倒自然不用说，webkit正是风华之年，Firefox很大程度上体现了标准，Opera有它独特的天性。有一点趋势很明显，标准正在扩散，并且随着IE9的出世，达到一个高峰。

CSS路向何方？

这并不是个匪夷所思的问题，因为标准对于单纯的重构来说是一把双刃剑。也许有一天我们欣喜地看到了标准的盛行，也许前端人员终于可以不在为各种兼容性问题而苦恼，但随之而来的是技术门槛的降低和整个行业的泛化。作为一种技术，核心难度损失掉的话，要被复制就太过容易了。5年前真的有这么多前端工程师么？而5年后，CSS真的还会有很大的难度么？

对于CSS样式表来说，它的本质是描述性的。既然是描述性的，必然不涉及自身逻辑上的难度。换句话说，控制CSS需要的不是逻辑力，而是想象力！是视觉！是复用出来的严谨！前两者自然不用多说，复用出的严谨是什么？复用的代码，从某种意义上来，是在实际中被复用出来的，而不是一开始被设计出来的。这称的上是一种熟能生巧。我相信任何人可以在工作中总结他自己的CSS复用和严谨的规则，怎么避免非标准的用法，怎么避免浏览器的兼容问题，怎么优化自己的样式。差异可能只是快慢和风格上的问题。

换言之，我隐隐感觉标准正在扼紧CSSer的生存空间。当标准真正被遵守，是否还需要这么多人“专门地”来重构？简单统一化的布局和样式，一定渐渐成为一种附属，并且特别是在小公司。这让我想到一个相似的例子：

曾经，一个qmail邮件系统的大师，可能只是一个熟知如何为老迈的qmail增打各种补丁方法的人。

一样的道理，熟知各种兼容写法和bug解决途径的CSSer，也一定会渐渐丧失其独特的优势。

但我们一样看到了CSS3，承载着新的希望。我们看到了绚丽的各种效果，阴影、渐变、圆角、旋转，甚至是投影、动画。于是，人们惊呼CSS绘制的图标、画像和CSS创造的动画效果，因为那是CSS做的！创想构建的这些新的CSS应用，很多是华丽而不实用的。花费数十倍的时间去绘制这么一个图标是否值得？如果真的到实际应用，那仅仅只代表着一个程序员的执着追求。如果所有的人都把时间花在这种地方，真不知道是福还是祸。

但是，改变影响整个Web发展，CSS3的贡献相当有限。换句话讲，虽然CSS3带来了更多美妙的web效果，但是引领web发展的不是CSS3，而是HTML5。

Flash路向何方？

HTML5和Flash的争论，其实没什么意义。HTML5取代不了Flash，反过来，让Flash取代HTML则更加荒谬。Flash擅长的是图形，要把它做成万能的平台是Adobe一厢情愿的野心。

这次乔布斯和Adobe的争论里，Adobe确实是有些理亏的。且不论Flash作为一个公司的技术，乔布斯自然有抵制的理由。更多的是Adobe Flash没能发挥长处而只是在谋求富互联网应用的霸主地位。虽然Windows平台表现还尚可，但是Flash在其他平台的表现一直平平，甚至能用糟糕来形容。这次Android版的FlashPlayer继承了其在Linux系统上的糟糕表现，狠狠被人抓了一把，甚至很多人开始相信乔布斯。

我写过一段时间AS，我能理解Flash的很多优势。虽然我欣喜地看到了canvas里像素级的控制方法，但是整体上图形能力和flash仍然差的很远。另外拥有成熟的开发环境，这也是完胜当前的JS的。也许我们以后能看到越来越多的JS的游戏，但是flash显然能做的更好，更快。

HTML5和CSS3，只是减少了flash的一些应用。Flash也一定会长期和浏览器共存下去。至少在新的标准里还没有能可以匹敌的替代方案前，并且还没有完整好用的IDE前，flash在游戏和图形方面，仍旧是一颗常青树。

至于JavaScript，HTML5和CSS3的到来，一定会让JavaScript承载的更多。

使用Flash Media Live Encoder ，可以非常方便的录制实时视频(live video)。Flash Media Live Encoder 的选项很多而且很细，品质控制也很不错。如何在AS3中实现这些？

参考FMS的Help，我简单的封装了这样一个类：

package com.swordair.as3
{	
	/**
	 * 
	 * @author iifksp
	 * 
	 */
	import flash.events.NetStatusEvent;
	import flash.media.Camera;
	import flash.media.Microphone;
	import flash.net.NetConnection;
	import flash.net.NetStream;

	public class LiveVideoCapturer
	{
		private var nc:NetConnection; 
		private var ns:NetStream; 
		private var cam:Camera; 
		private var mic:Microphone;

		public function LiveVideoCapturer(address:String = null)
		{
			nc = new NetConnection(); 
			nc.addEventListener(NetStatusEvent.NET_STATUS, onNetStatus); 
			nc.connect(address);
			nc.client = this;
		}
		public function onBWDone():void{
		}
		private function onNetStatus(event:NetStatusEvent):void{ 
			trace(event.info.code); 
				if(event.info.code == "NetConnection.Connect.Success"){ 
					publishCamera();
			}
		}
		private function publishCamera():void{ 
			cam = Camera.getCamera(); 
			cam.setMode(640,480,20);
			cam.setQuality(50000,90);
			mic = Microphone.getMicrophone(); 
			ns = new NetStream(nc); 
			ns.attachCamera(cam); 
			ns.attachAudio(mic); 
			ns.publish("swordair", "live");
		}
	}
}

这个类简单的获取摄像头和麦克风，然后调用NetStream对象ns的attachCamera和attachAudio将其附加，最后通过对象ns的publish()方法发布到Flash Media Server。

FMS会回调ns的client对象的onBWDone()方法，所以指定client并添加onBWDone()。这里将client指向类本身然后添加了一个public的onBWDone()方法供FMS调用。如果缺失onBWDone()方法，可能得到这样的错误：

Error #2044: 未处理的 AsyncErrorEvent:。 text=Error #2095: flash.net.NetConnection 无法调用回调 onBWDone。 error=ReferenceError: Error #1069: 在 flash.net.NetConnection 上找不到属性 onBWDone，且没有默认值。

整个过程就是：获取资源 - 建立连接 - 发布；ns.publish()的两个参数分别是流的标识字符串和发布方式，发布方式可以使live(默认，不录制)、record(录制，覆盖同名)和append(录制，附加同名)。

如果要回放录制的视频，对于flash的Video而言，使用相同的连接nc创建一个NetStream对象，调用其play()方法，最后使用Video对象attachNetStream()播放该流。

var nsPlayer = new NetStream(nc); 
nsPlayer.play("swordair"); 
var vidPlayer = new Video(); 
vidPlayer.attachNetStream(nsPlayer); 
addChild(vidPlayer); 

对于Flex的VideoDisplay，可以简单的设置rtmp地址：

<mx:VideoDisplay 
	id="vd1"
	source="rtmp://localhost/live/swordair" 
	width="100%" 
	height="100%" 
	autoBandWidthDetection="false" 
	live="true" 
	maintainAspectRatio="true"/>

Flex4的VideoPlayer相当出色，可惜至少在我测试的时候(FlashBuilder4 beta 2 SDK Build 4.0.0.10485)，出现了严重的延迟问题。回放实时流的延迟甚至超过15秒钟，这简直无法忍受。最终放弃VideoPlayer而改用mx:VideoDisplay，延迟在2-3秒。也可能只是我的设置问题，但是VideoPlayer的相关参考还相对较少，希望Flex4正式可以解决这些可能存在的问题。

参考资料

Adobe Flash Media Server 3.5 - Capturing live video