日历
<2008年7月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789
标签
心情故事 (42)   博客港工地 (20)   业界咨询 (13)   Web技术 (8)   .Net编程 (5)   启航工具箱 (1)  
搜索
最新评论

Professional Visual Studio Extensibility》的作者Keyvan Nayyeri 在他的博客里头发表了《.NET and Web 3.0》,作为.NET社区的一个名人,他同时是《Professional Community Server》的共同作者,因为文章讨论的不是目前有些过滥的Web 2.0,而是3.0,我不知道是否应该用3.0来指下一代的Web,或者说Web的未来。

         关于Web 3.0的定义,目前还没有定论,Web之父Tim Berners-Lee 认为下一代的Web应该是语义Web,这也是目前被广泛接受的论点,但还是存在诸多争论,有人认为是Web OS,有人认为是人工智能,也有人认为是一个“可执行”的Web抽象层,也有人认为是API组成的世界,更有甚者,认为Web 3.0是一个商业模式。我们姑且不去讨论具体应该如何定义Web 3.0,但是这些纷争之后我们可以看到一个更加清晰的Web未来所具有的属性——语义、数据、人工智能、网络计算、开放标准、分布式数据库。而具备这些属性越多的商业模式,我们姑且认为越加Web 3.0

         Keyvan Nayyeri的原文在这里http://nayyeri.net/blog/net-and-web-3-0/ ,我无意做完整的翻译,为了阅读的方便,我简要地描述出原文的大致观点

        

.NETWeb 2.0的世界里是落后的

         不知道是出于刻意还是偶然,.NET经过几年的发展,逐步成为一个成熟的企业级平台,但是在如火如荼的Web 2.0里头的表现却有些差强人意,不可否认,phpRuby on Rails在这次角逐里头占据上风,keyvan认为主要是三个原因导致的

1.   .NET社区创造力的缺失。Keyvan抱怨当前.NET社区大多开发人员缺乏创意,都是采取尾随的策略。他也批评了微软在这个方面的保守及其对于开源的态度,对于开源项目扼杀的同时也扼杀了开发人员的激情和创造力,.NET社区的开源出于进退两难的境地。因为缺乏创新和无法领导Web潮流,也在情理之中了。

2.  .NET是一个后来者。虽然从2000年微软就抛出了.NET战略到2002年正式推出.NET平台,微软花费了三到四年的时间去说教,包括那些社区领袖也是如此,大多经历耗费在了去说什么是.NET和如何利用哪些功能去做好软件。这个问题到2005/2006年才有所改善。而反观PHP,则是稳步前进,至于RoR,keyvan则认为这是一个例外,但是他认为反倒可以不用太考虑它,因为出现了难以置信的增长,在这个期间很难产生更多新技术。

3.  基于成本角度考虑。虽然微软在这个方面做了很多努力,包括免费提供开发工具,但是这个远远不够的,比如Facebook部署了300MySql,如果部署了300SQL ServerBiztalk,各位可以想象一下成本。免费的平台成本和微软收费的平台自然不能够相提并论,在可靠性不是第一位的Web 2.0里头,企业级并无法真正展现出其优势所在

 

 

Web 3.0里,想法不是主要的,关键是方法,而这正是.NET的机会所在

既然Web的未来是语义的Web,换言之,也就是面向内容的网站,当然这里的内容和以前的内容是有区别的,它应该是更加易于使用人工智能,如果说Web 1.0Web 2.0我们是创造了人可以读懂的内容,那么3.0则是机器可以读懂的内容。Keyvan认为Web 3.0需要想法,但是更加需要方法(尤其是人工智能),抛开技术层面的标准(RSSRESTWeb Services….),更多的工作是分析内容,诸如分析html/xhtml这样的工作在未来的Web就成为了家常便饭,而在今天,这个工作还是专属于搜索引擎专家的事情,那么未来呢,用人工智能的方法来分析Web内容是势不可挡的。Keyvan认为.NET社区应该在这块上有所作为。

既然关键的是方法,如分析内容的方法,也就意味着在未来更加需要一些能够“智能”分析Web内容的工具,也会更多需要图像处理、视频处理和音频处理的工作,而如何能够提供行之有效的工具,也正是一个语言对于一个技术时代的意义,也由此决定了一个语言的位置。如此看来,在Web 2.0里头,.NET不如PHPRoR就不足为怪了。

 

也无意去讨论平台之间的分歧以及Web 3.0到底应该长什么样子,过去几年,一直有坚定的.NET拥护者批评和反思的情况,从.NET概念的推出到现在,也已经走了了八个年头,Visual Studio也演变到第四个主版本,.NETWeb 2.0市场方面的表现确实有些令人沮丧,作为有过多个平台工作经验的我来说,在受到keyvan的启发之后,也有一些自己的理解:

1.  .NET社区缺乏创新和微软一直以来的策略有关

作为最伟大的软件公司,虽然一直以来其商业风格遭人诟病,但是在软件领域是无可争议的霸主,可是微软似乎对互联网一直有些“感冒”,包括.NET战略中的互联网及其现在的Live战略,在这个领域里头,微软似乎很难做到无所不能。

或者真的对于互联网过敏,在开放源代码世界对于互联网应用诸多的思考和创新几乎是由JavaPhpPython来领导的,而.NET是永远的跟随者。另外可能是基于商业版权的考虑,对于.NET下如比较成功的开源项目如NUnitNDocMVC框架(Castle Project)等等,微软无一例外地选择抛弃,然后令立门户。这样做带来的后果是微软浪费了不必要的资源(说实话我就觉得NUnit比微软的Unit Test好使,微软有点吃饱了撑着没事干),另外一个方面严重打击项目作者的积极性。

做开源的天生需要认同感,你选择.NET的时候,还需要去考虑这个东西以后微软会不会做,你只能够去做Visual Studio不愿意做的事情,结果无疑是沮丧的。

另外一个方面.NET Framework太过复杂,大而全,“2003都还没有搞定,就出2008了”,就连基本的类库和语法都还来不及学习,就出新版本了,小弟们忙着学习,社区的大佬们忙着布道,发现一个轮回还没有完,又出新版本了。所以也有很多开发人员抱怨跟着微软走,太累了,而我们看看JavaPHP,在语言级别的更新速度是缓慢许多,也正因为如此,他们有更多的精力去反思现有框架存在的问题,从而提出一些创新的改进。.NET开发人员就没有那么幸运了,大多时候在疲于应付,从.NET 1.1.NET 2.0再到.NET 3.0到现在的.NET 3.5Silverlight,我想没有多少人能够全部了解。

微软在框架上的快速更新一个方面表现为微软在此真的做了很多努力,但是反过来看了,也是框架本身不够成熟的标志,因为下层框架的推陈出新,也就限制了.NET开发人员在上层应用框架的思考深度。

我不知道这样是好事还是坏事,但是作为一个微软技术的开发人员,不管你是否愿意承认,你真的会被微软所左右,最终失却keyvan提到的“Ideas”。

2.  Visual Studio,成也萧何,败也萧何

微软的产品都有一个原则,那就是“模糊复杂性”。任何产品你都可以当着傻瓜一样使用,当然了,也有可能因此真的变成傻瓜。不夸张地说,微软的大多产品都复杂于竞争对手,可能这并不是完全出自微软的本意,但是基于“向下兼容”的需要,最终的产品过渡复杂化,这个问题在.NET Framework的设计上也依旧存在的。

诸位如果有通过反编译阅读过部分.NET Framework源代码的,就会发现.NET CLR并没有我们想象的如此纯洁,看看它对于安全的包装就可以略知一二,可能是受限于底层操作系统的缘故,一些东西还是能够明显看到粗糙的痕迹的。当然了如果有心,你比较Mono Project.NET Framework的实现就知道了。

话说到这里,并不是刻意去批评.NET Framework设计上的“好大喜功”,所以难免华而不实,而是说.NET Framework设计不够精良的问题是存在的,但是我们再看看Visual Studio,这些问题我们可以看见嘛?答案是否定的,Visual Studio真的“很好很强大”,所以可以让我彻底忘记这些缺陷,通过拖拖拽拽,就可以写出一个应用,让我可以不用关心这些问题的存在。

我们再来举个例子,也许有些朋友使用过WebPart,这是ASP.NET 2.0一个非常重要的增强,如果你不用怎么动大脑,按照微软提供的帮助使用它,使用默认的provider,使用默认的aspnet用户数据库,使用默认的数据库存储方式,OK,一切万事大吉。但是作为一个web 2.0网站,你有可能真的希望所有的用户数据字段存储在二进制中嘛?答案是否定的。WebPart还是存在一些性能问题的,你希望有效地提供性能,所以你需要重新编写Provider,你觉得WebPart使用表格布局太老土了,而希望用DIV+CSS来实现WebPart。这个时候,你会发现有的忙了,从新编写WebPart或者ProfileProvider并没有你想象的如此简单,这个时候也许你真的需要花费更多的时间去阅读反编译的代码以帮助你解决问题,阅读之后呢,你会发现这真的是一个无底洞。

从功能层面来讲,ASP.NET提供的那些功能都是有诱惑力的,从可定制的角度来讲,你使用了这些框架可能会得不偿失,或者这就是微软文化。你按照他指引的方向去走,发现是康庄大道,一旦你想走的与众不同,发现并没有那么舒坦。

对于底端开发人员,Visual Studio将复杂的问题极大地简单化,对于有能力给社区做贡献的“领袖”开发人员,情况恰好反过来,简单背后的复杂会让你深陷泥潭。我们在看看对面的开源世界,简单也好,复杂也把,始终是表里如一的。

按照我的理解,微软强调“工具改变世界”,所以会给我们很多假象,而Java或者PHP更加强调“框架实现”,开发工具只是辅助实施的手段罢了。Visual Studio某种程度极大提高了开发效率,反过来也遏制了许多开发人员的创造力,这么去想.NETWeb 2.0上的尴尬就不足为怪了。

3.  开放是微软自我救赎的必要

过去的两年来,微软变得难以置信的开放,包括CodePlex的推出,Visual Studio Shell的发布等等。微软发现开放会赢得更多拥抱,毕竟在互联网领域,微软还是会有微微的失意,不可能找到软件时代的舍我其谁。

但是这种有限度地开放,并无法解决.NETWeb 2.0方面的尴尬程度,从各个方面来讲,.NET都是一个迟到者,花费了好多时间终于讲明白什么是.NET,发现对手已经跑远了许多。而要证明一个开发平台在Web 2.0中的地位,莫过于看有多少App,而app的普及程度也就决定了平台的普及程度。

基于微软产品策略的考虑,.NET平台的高度绑定也是其无法大力发展的一个原因,对于Mono的有限支持,也让跨平台更多的只是天才们的梦想。

4.  华丽的背后必须“纯洁”

上面也提到微软的很多工具和框架都提供了难以置信的方便,背后带来的是对于底层控制的乏力,总体来说,微软的产品底层架构是不够干净的,大多东西无法做到让你随心所欲地修改,反过来看PHP或者Java,各种框架之间的互集成都是相对容易的。

微软希望赢得更多的市场,就必须在这个方面多下功夫,完美、华丽的背后应该更加追求稳定、架构开放。从我个人的经验来说,写好.NET代码真的不容易的。也有人这么评价“同样一个烂的程序员写.NETJavaPHPWeb 2.0程序,执行速度方面的排序是.NETPHP然后Java,从稳定性的角度是JavaPHP然后.NET,从开发效率来看是PHP.NET然后Java”,我们也可以看到.NET真正的软肋所在。

拥抱开放,自我纯洁,或许是.NET真正该做的吧。

5.  .NET在未来Web的位置也就是微软在未来互联网的位置

如果说Web的未来在于数据和语义构建的人工智能,那么是否能够对此提供足够的支持,也就决定了在未来的平台之争是否占据优势。Google梦想将整个互联网变成一个他的操作系统,而微软更加擅长于利用开发人员来统治世界。

多年以前,比尔。盖茨希望全球的每一台电脑都安装微软的操作系统,也正是这样的一个梦想成就了今日的微软帝国,但是仅仅限于传统软件领域,在互联网,Google却是无可争议的霸主。过去微软为了实现“可连接性”,在不同时期推出了DDEOLECOMDCOMCOM+等实现互操作的技术,而在.NET推出之后,又将互操作性更近一步。然后一切无一不是在Windows平台这个框架之内,Web的兴起终于将这个规则改变,人们更加乐于用XmlWeb Services这样跨平台的协议来实现互操作性,而且也正因为如此,实现了跨越语言、操作系统的互操作,微软平台不再成为唯一的选择。加上如keyvan评价的那般.NET的复杂性和社区的“不思进取”,再回首,发现已经落后许多。

Web 3.0时代,微软应该更加专注于将自己的Web平台变成一个可编程的“操作系统”,然后在此基础之上,提供一个更加方便的工具。LINQ在这个方面做出了一些努力,也有人说这是来自RoR社区的创意,但是我们的确可以看到,.NET确实越来越好用,越来越简单。

 各位朋友,在未来的Web,你是否使用.NET?我自己不知道,需要等待。

------------转载自刘如鸿的博客日志

--- 本文章同时发布到论坛
启航  发布于 2008年7月19日 22:16 ┊  [原创] ┊  点击(220) ┊  评论(0) ┊  我要评论  ┊           收藏

Powered by SpaceBuilder v1.1    ©2005-2008 Tunynet Inc.