Silverlight与微软技术:微软抛弃Silverlight了么?

摘要:话说,在最近的PDC上,微软的副总裁Bob Muglia说了类似的话“我们对Silverlight的策略改变了,我们要用HTML5来实现跨平台的应用程序”,于是乎,社区铺天盖地响起了“微软要抛弃Silverlight”的调调。出现这个说法并不奇怪,媒体转述一遍,再给社区理解一下,很正常。但是我觉得奇怪甚至有些恶心的是,当事实愈发明朗化的时候,冒出的一些莫名其 ...

话说,在最近的PDC上,微软的副总裁Bob Muglia说了类似的话“我们对Silverlight的策略改变了,我们要用HTML5来实现跨平台的应用程序”,于是乎,社区铺天盖地响起了“微软要抛弃Silverlight”的调调。出现这个说法并不奇怪,媒体转述一遍,再给社区理解一下,很正常。但是我觉得奇怪甚至有些恶心的是,当事实愈发明朗化的时候,冒出的一些莫名其妙,兴灾乐祸,事后诸葛还在愈演愈烈。这两天我在社区里看的很多说法,某些“评论家”连一些基本概念,如“Silverlight是Windows Phone 7的开发平台”都不清楚,就来捕风捉影,实在让我难以继续旁观。

其实Bob Muglia的原话是这样的:

“Silverlight will continue to be a cross-platform solution, working on a variety of operating system/browser platforms, but HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform.

Silverlight将继续是一个跨平台的解决方案,未来Silverlight将持续工作在各种操作系统/浏览器平台上,但是HTML才是目前一切运用真正跨平台解决方案,包括苹果的iOS平台。

这句话的问题在哪里?我看不出任何要放弃Silverlight的意思。微软从一开始就说Silverlight将会跨操作系统及浏览器运行,目前是,将来也是,包括Windows,Mac OS及这些平台上的各种浏览器。但是,对于移动设备又能怎么办呢?苹果的iOS上已经拒绝Flash进入,因此拒绝Silverlight也是可以预料的,因此Silverlight方面就算尽再大努力也无法实现这点。而苹果是支持HTML 5的,因此微软为了发展,将HTML作为“跨所有平台”的手段,在我看来十分顺理成章。可能Silverlight以后不会进入iOS,但并不表示它不会进入Android等其他手机平台,而就目前来说,Silverlight本身已经是Windows Phone 7的开发平台了。

Silverlight之于Windows Phone 7,WPF之于Windows,就好比CocoaTouch之于iOS及Cocoa之于Mac OS,它们都是十分正常的产品及开发平台策略。就拿苹果来做例子吧,CocoaTouch只能工作在iOS系统上,您担心CocoaTouch被苹果抛弃吗?诚然,微软的手机才刚刚起步,平板电脑更是没有踪影,从商业上来说远不如iOS设备成功,但是人人都能看到微软对Windows Phone 7的重视,WP7是微软不断强调的“三屏一云”战略的重要组成部分,而Silverlight就是WP7上的开发环境,那么您为什么会担心它会被微软抛弃?我看到有些文章的标题类似于:“Silverlight失败,未来属于移动互联网”,于是我就转不过脑子了,Silverlight对于微软来说,就几乎等同于“移动互联网”,您一边看好移动互联网,一边觉得Silverlight挂了,你让微软情何以堪?

有人说,这次的PDC 2010都没有Silverlight的内容了,可以看出微软不要Silverlight了,否则怎么没有Silverlight 5的消息?我也觉得很奇怪,PDC是有主题的,这次的主题是Azure,IE 9和WP 7,因此强调的是云计算,HTML 5和移动互联网开发,最后一个其实就是Silverlight。事实上Silverlight的内容本就没少,只是换了个名字叫做WP 7。我不知道嚷嚷着PDC没有了Silverlight的同学有没有真正看过PDC,不过我在看,看了很多,感觉很爽。我看到了PDC的Keynote演讲上ScottGu就在现场操练Silverlight开发,分会场里也在大谈“基于Silverlight开发面向Azure平台的WP7应用程序”、“优化WP7中Silverlight程序性能”,“早该知道的WP7开发注意事项”,还有与WP7几乎无关的“使用Silverlight 4开发商业应用”,“如何在WPF和Silverlight中共享代码”等等太多内容。半年前的Mix 10大会上微软还在大谈Silverlight和WP7,只不过打得是Silverlight的旗号,而仅过了半年,微软打着自己正在全力推广的WP7的旗号来谈几乎相同的话题,您怎么就突然崩溃了呢?

PDC是微软专业会议,议程及其有限,而微软的技术实在太多,没有登上PDC讲台的话题实在太多太多了。去年的PDC还有关于CLR、虚拟化、Windows Server的话题呢,这次都看不到了,莫非微软要抛弃这些了?如果像某些同学希望的这样,微软发布了Silverlight 5的消息,我估计对于微软铺天盖地的谴责之声就要变成“技术发展太快”了。

如果说CocoaTouch只是在iOS设备上运行,而Silverlight除了Windows Phone 7以外,之前Windows和Mac OS上该有的还有,已经在的还在。Silverlight对于微软的重要性,不会比CocoaTouch对于苹果的重要性来的差。作为一个Silverlight开发人员原本该干什么,现在还是干什么,除此之外,退可开发WPF,进可出手WP7。ScottGu在PDC上接受Scott Hanselman采访时说,微软将开发语言、框架、工具进行统一,让开发人员可以很自如地进入WP7的开发领域。我对WPF和Silverlight一窍不通,但我从没像现在这么羡慕您已经掌握了这部分技术(当然其实也没那么羡慕啦,我相信自己会学得很快),因为在移动互联网的大潮下,我可能以后还真要去学习WP7上的Silverlight开发,而您已经可以顺利过渡了。

如果您还是对Bob的那段话表示纠结的话,其实也可以继续看看他的说法了。他和微软Silverlight团队估计也没想到,当然现在也意识到事态的严重性,于是连续发表了两篇声明,一是微软对Silverlight未来的担保,二是关于PDC上关于Silverlight那些表态的后续解释,其中写到:

I said, “Our Silverlight strategy and focus going forward has shifted.” This isn’t a negative statement, but rather, it’s a comment on how the industry has changed and how we’re adapting our Silverlight strategy to take advantage of that.

我之前说到:“我们的Silverlight策略和前进的重心转移了”,这不是一个负面的说法,它只表示业界的现状改变了,我们调整Silverlight的策略希望可以利用这种改变。

在我看来,业界现状的表现之一,就是之前我所说的苹果不会接受Silverlight和Flash,但它对HTML 5友好。微软不强求Silverlight进入iOS——这是Bob之前所特地强调的设备——而是让Silverlight去迎合HTML 5大潮。例如,Adobe在刚刚结束的MAX 2010大会上展示了一款Flash至HTML 5的转化工具,那么我猜想,微软今后也会这么做吗?利用Flash和Silverlight所配备的高度生产力与HTML 5相抗衡也不失为一种竞争手段。当然,谁知道呢。此外,文章里还谈到过几个月就有下一代Silverlight的消息了,不知道这能否让某些朋友松一口气。

讨论和争议是好事,但是在这个过程中出现了一些声音让我很不满。例如某些同学连Silverlight与WP7的关系都不知道就来指点江山。Ivony写到过类似的意思:社区里有一些人,看着某个事物不断发展却无力接触,一遇任何风吹草动却跳出来幸灾乐祸,正如这次Silverlight事件,还有上次微软于LINQ to SQL等等。我不知道上次的那些认为微软放弃LINQ的同学,看到.NET 4.0中LINQ to SQL的更新,LINQ to Entity在最近两届PDC中的表现,以及本次PDC上随Azure出现的“LINQ to Azure,LINQ to Everything”的演讲是什么感觉。

微软的技术一定是有问题的,但是我们完全可以用合适的方式来对待,受用无穷。当然,这方面内容就下次再展开了。

经常听到有人说微软的技术变化太快,持续性不好,让程序员追得很累。这种观点在微软技术社区内部和外部都有出现,似乎是一个不争的事实。但从我追随.NET平台这近十年的时间里,我并没有明显的感觉。微软的技术的确很多,但至少在.NET领域过渡性做的非常好,我没有任何疲惫之感。微软技术开拓了我的眼界,让我在微软内外许多技术方面越来越少有“新奇”的感觉,一切都是那么自然和稳妥。我现在就来仔细谈谈我在学习微软技术方面的经验与感受。

我一直对编程有浓厚的兴趣,上大学前在编程方面的经验主要来自于信息学竞赛,此外就是用一些VB或是Delphi写一些小程序,拿去参加高中的一些名不见经传的小比赛,那点小名次,小打小闹,仅此而已。到了大学里,学习(或自学)了Java,少许LISP,数据结构与算法,操作系统,计算机体系结构,计算机网络,编译原理等最传统的科班课程,但似乎学的不太好,现在想来颇是后悔。此外学过几次C++,但智商有限,几次下来都没有坚持到底,现在也忘得差不多了。可以这么说,我的专业程序员生涯的成长离不开微软与.NET。当然,我热爱各种技术,各方面也学习了很多。我接下来也会说到,技术本就不应该分为“微软”与“非微软”两个部分。

我在大学的时候学习和使用的是Java,也用Java参与了一些奇怪的“企业项目”——如上海海关进出口检疫局的什么什么系统(不过那时候我也已经开始接触C# 1.0和.NET了)。后来由于去了微软,自然全面转向.NET。我在微软只待了一年半,但这一年半给我最大的帮助就是让我开阔了眼界,知道技术领域有多么广阔,知道学校里了解的一些东西是多么的不靠谱。可以说在微软的这段时间对我来说是个突破,从那时起我就对各种技术都抱有强烈的兴趣。

有人说微软技术发展太快,且时常淘汰很多东西,对此我并不赞同太多。我接触到的说微软技术变化太快的同学,大都是老程序员,他们因为微软将重心放在了.NET上,导致了COM等技术运用场景减少,于是颇为不满。他们时不时“预言”微软以后会抛下.NET,虽然.NET已经发展了近10年,且力度越来越大,所以我称这种“预言”是一种FUD。我是从.NET 1.x/C# 1.0学起的,一直到现在,无论是语言还是基础类库,一切都良好过渡。您在C# 1.0里学到的东西,有哪些在C# 4.0里消失了么?您写的ASP.NET 2.0程序,直接无痛升级到ASP.NET 3.5——这是大众点评网的架构师在分享会上提到的,它的应用规模及复杂度不低于您的项目吧?微软是个对企业应用有许多投入的公司,在过渡和兼容性方面必须做到几乎百分百的保证,这些经验也总结成册,例如获得Jolt大奖的《Framework Design Guildline》,其中不断强调的一点,就是在设计时对兼容性方面的考虑。

在兼容性方面,某些技术领域的程序员就有更高的“觉悟”。例如Python 3.0成为了一门不兼容Python 2.x的语言,Rails 3.0也不兼容Rails 2.x。我咨询过几个Rails程序员对此的看法,他们观点十分一致,那就是对Rails 3.0很有好感,至于以前的项目,“没有必要从2.x升级到3.0啊!”。我也支持他们的看法,如果您不喜欢C#里的新特性,那就不用那些特性。如果您不喜欢新框架的功能,那就继续用原来的方式做事情,新的框架也不会对您有影响。我支持Python和Rails项目发展的决定,他们为了前进抛下一些历史包袱,我可以理解。这并不会影响我对Python和Rails的喜爱,它们依然是十分优秀的语言和框架。

有人说,微软会淘汰技术,那么对这些技术的投资不就失效了吗?这方面我认为自己有很好的发言权。我之前也提到过,我在社区里的“声望”是靠ASP.NET AJAX积累起来的。但是现在ASP.NET AJAX似乎慢慢地淡出了人们的视线,那么我的投资失败了吗?完全没有,确切地说简直太成功了。ASP.NET AJAX覆盖了浏览器端的JavaScript开发,以及后台对ASP.NET WebForms页面模型的扩展,当然,还包括两者的交互。我一直认为UpdatePanel是前后端交互的经典之作,它通过在前端页面的hook,以及对后端WebForm模型输出的捕获,做到了非常透明的AJAX效果,只可惜由于项目分工,前端开发人员大都喜欢手写的纯客户端模型,因此UpdatePanel不太受人待见。我读过了ASP.NET AJAX的前台代码,由此全方面了解了JavaScript语言和许多前端开发的技术和技巧。我读过了ASP.NET AJAX的后端代码,由此我了解了一个JSON序列化框架可以如何实现出来,体会到了ASP.NET及其WebForms模型丰富灵活的内涵。从ASP.NET AJAX开始,我可以自豪地认为自己“精通”了ASP.NET,对它各方面的扩展可谓如鱼得水。例如,我可以轻易写出一个UpdatePanel上传文件,或是ASP.NET MVC中UpdatePanel的原型,虽不至于成为一个通用的组件及解决方案,但是对于自己项目本身已完全够用(我几乎没有纯“玩闹”而写的扩展,都是源自于项目本身)。后来微软出了ASP.NET MVC,我花两天时间扫视一遍它的源代码,也已经基本掌握了它的原理,使用方式,扩展也罢,一切都那么顺其自然。例如Rails是个优秀的Web框架,包含许多对实际生产非常有效率的特性,但是我在看了这些特性的使用方式之后,几乎都可以立即想象出它在ASP.NET里的实现方式,就例如表现层的片段缓存那样。

我一直强调,我并不了解所有的.NET相关的框架,但就我所了解的.NET技术而言,它们都有这样的特征:过渡性很好,自然地,有底蕴的发展。就拿C#来说,C# 1.0中创造了“委托”这个函数的一等公民类型,而在C# 2.0里引入了匿名方法,C# 3.0里强化了函数式编程的理念,成就了这一到目前为止最为经典的C#语言。C# 3.0中引入了Monadic的LINQ语法,几年下来基于LINQ发展了太多太多,如PDC 09中的LINQ to Observable,PDC 10上的LINQ to Azure。社区里如围绕NHiberante的贡献更是数不胜数。微软技术在我看来是十分领先的,这个领先并不一定指它在计算机科学上的创新和突破,而是指它对于这些经典理念与工业生产相结合方面的超前。可能它不如某些朋友心目中LISP那般博大精深,但可以说更直接地在让我在实际生产中体会到了经典的魅力。

这样的“领先”给我带来了许多乐趣,也让我慢慢难以从其他技术上感到“惊喜”。例如,一个Java程序员转到Python以后,会感觉生产力有了显著的提高,但就我来说,相当部分的生产力在C#中都有体现,我不会以为生产力低下是“静态语言”的关系。同样,我最近在关注iOS及Mac OS方面的应用程序开发,接触了一些Objective-C,发现它的block就相当于.NET中的委托,而在09年随Snow Leopard引入的block的支持语法早在C# 2.0中就由“匿名方法”特性实现了,更不说C# 3.0在这方面有更进一步的发展。同样,我阅读了GCD(Grand Central Dispatch)的文档之后,发现它和.NET 4.0中的TPL(Task Parallel Library,任务并行库)解决的是相同的问题,其实现思路也有许多相同之处,例如都是主要通过描述“任务”(如任务内容及依赖关系)来避免程序员直接使用线程,避免复杂的同步问题,并由系统来负责对任务的调度。有时在推特上,我时常可以看到一些Cocoa的开发者津津乐道于block及GCD对于并行开发所带来的诸多便利——于是我想,这个早已不该是新闻了嘛。我现在还知道未来C#还会在这方面有更多便利,它在Anders Hejlsberg的带领下再一次走到了领先的位置。

微软的技术大都容易入门,但这并不影响这些技术深厚的底蕴,您在学习时应该了解这种底蕴。例如,您在学习C#时,不应该只关注它的表面特性,而要知道“为什么Anders会设计这样的特性”。我认为,一个优秀的C#程序员应该对函数式编程有一定程度的理解。当您学习Reacive Framework时,应该顺便去了解一下响应式编程。同样,我看到社区里有一些关于TPL的文章,但认为它们还是没有把握到精髓。事实上这些精髓都不是秘密,微软对各种原理几乎都不做保留。例如微软免费提供了《Patterns for Parallel Programming》等资料,详细解释了并行编程中的诸多模式,以及它们在TPL(C#与VB)或是F#中的实现方式,这些都体现了微软在设计这些语言或类库时的思路。微软在构建这些技术的时候并非无中生有,都是事先设计好使用场景的。例如用Task应对任务并行,用PLINQ应对数据并行,毫不草率,堪称经典。此外,TPL的设计者Joe Duffy是业界大牛,他写过一本《Concurrent Programming on Windows》,描述了大量关于TPL的实现细节,例如无锁数据结构的编写方式,Work Stealing,如何改善局部性等等。您了解了这些内容以后,我想GCD对您来说可能也只是换套API而已,应该也不算是件难事儿。我一直认为,就算微软明天给外星人一锅端了,我也能很快进入其他技术领域,并很快达到较高级的程度。但是,如果您每次都只了解一些表面,自然很容易觉得天崩地裂。盲目追赶,那也只是恶性循环而已。

我一直强调“眼界”,微软技术不断为我打开新视野,这些技术的设计者都在各种场合提到其他技术对他们的影响。因此,学习了C#和F#,我对于Python,Ruby,Scala,Haskell都产生了浓厚的兴趣,我不会像许多Java程序员认为Java语言已经足够了,或是像许多Ruby程序员那样认为自己领先于其他程序员,我能时刻保持Keep Stupid,Keep Hungry。我时常不解一些技术人员在我看来莫名其妙的轻视(不是“敌视”)微软技术,我认为技术的大千世界何其美好。因此,即便我再是厌恶Java语言,也对JVM和其生态环境敬爱有加。于是,我通过《CLR via C#》对.NET运行时浅尝辄止之后,又通过《Oracle JRockit: The Definitive Guide》深入了解JVM的虚拟机世界。我看过了《Concurrent Programming on Windows》之后,又去阅读了作者推荐的《Java Concurrency in Practice》。

如果眼界没有打开,即便您学习的是业界“最先进”的技术,也可能产生偏差。例如时常看到Rails开发人员自豪地说,他们可以从Rails里学习RESTful。由于前段时间我刚巧看了《RESTful in Practice》一书,再结合我对Rails的了解,我实在没有感到这个Web框架在RESTful方法的独到之处。于是他们让我去看Rails 3.0里强大的Routing功能。我看后,才意识到其实他们似乎对于REST的理解有所偏差——REST的精髓在于由Hypermedia驱动的State Transfer,而形如“/article/20”这样的URL,以及映射一些HTTP方法等等,其实远非RESTful架构设计里的关键。RESTful只是要求“每个资源对于一个URI”,但并没有规定URI的形式,而且如果客户端直接了解服务器端的URL规格并直接访问,就与REST的“解耦”目标渐行渐远了。事实上,《RESTful in Pratice》一书甚至有建议对URL做些混淆。总体而言,Rails只是对REST架构中的一小部分提供了较好的支持而已,还远不能“从Rails学习REST”。昨天晚上我和REST专家李琨老师谈了我在这方面的理解,他基本赞同我的看法。我庆幸不已,要知道在此之前我还看过《RESTful .NET》一书,但我走向《RESTful in Practice》之后,才意识到前者给我带来了不少错误的观念。幸好,我并没有良好的自我感觉,也没有满足于现状。

如果您学习的是.NET,那么打开眼界的一个有效工具便是Mono。Mono及Miguel de Icaza已经不再拘泥于跨平台的.NET这个目标,而是努力在其之上实现大量的开源或商业产品。其中的典型便是MonoTouch和MonoDriod让.NET及C#进入iOS和Android平台广受喜爱,也已经有越来越多的成功案例。此外,Mono对于开发原生Mac OS应用程序的支持也步入了正轨。我作为一个.NET开发人员,从没有过如此兴奋的感觉。

如果您正确地学习了.NET技术,您会发现自己走上了一条良性发展的道路。从另一方面来讲,微软的技术固然多,但作为开发人员我们并不需要了解每项技术。微软在创建一门新的技术的时候,都会讲清楚这门技术所解决的问题是什么,如果与您无关,完全可以不去学习。例如.NET 2.0与3.5之间还有一个3.0,其中提供了WPF,WF和WCF三个框架。我可以坦率地讲,我对它们没有任何了解,但这丝毫不影响我自称是一个优秀.NET技术人员的自信。很多时候,如“疲于追赶”这种事情,我觉得太多程度上都是自寻烦恼了。这样“无中生有”的烦恼还有很多,例如微软给出F#以后,就有人说微软要抛弃C#了。您为什么就不能认为这是一种互补,或者说,给您多了一种选择呢?微软同时发展VB.NET和C#语言好多年了,您一直没有学习VB.NET的烦恼,为什么现在多了一个F#,您又动摇了呢?还有例如近日的Silverlight问题,前篇文章已有详述,不提。

许多人会持有这样的观念:整个技术领域分割为“微软”和“非微软”两部分,然后指责“微软”技术不如“非微软”来的丰富。在我看来这种分割方式是十分可笑的,怎么没有人将技术分为“Ruby”和“非Ruby”,然后指责“Ruby”技术不够丰富呢?正如我之前说的,微软技术对我的重要价值之一,便是促进了我对各方面技术的浓厚兴趣。无论您是专攻哪种技术的开发人员,如果只是停留在自己这一亩三分地上,这都是不甚可取的。没有人限制微软系的技术人员从其他领域吸取经验,正如一个优秀Ruby程序员肯定也从Ruby外的技术领域吸收了大量精华。说实话,除了政治需要,我实在找不到将微软和开源社区(或是其他社区)对立起来的理由。

就写到这里吧。希望对您了解微软技术,以及如何学习微软技术能够有所帮助。

原文首发:Silverlight与微软技术(下):微软技术与技术学习



微信公众号:alibuy

无觅评论,优化体验,加强品牌价值

无觅相关文章插件,快速提升流量