随着乔布斯所培育的大苹果越发清香诱人后，安卓、谷歌等也难耐不住寂寞，纷纷推出自己的智能手机或平板电脑。随着这股潮流，涌现出一批又一批的开发者，有开发游戏的、有开发应用的，也有开发企业软件的。而选择的语言和技术也多种多样，HTML5、Silverlight、Java、 Objective-C等，尤其是当HTML5推出后，整个开发世界好像地震了一般。以上这些，说明什么呢?移动软件开发商和开发人员们又如何在这场扑朔迷离的大变革中选择出一条最稳妥的路呢?
观点一：HTML5是趋势，但不是你的优势
HTML5是趋势，但它绝对不是最佳选择，现阶段它无法给你银弹。那为什么它会如此之热，而火热的背后又会给你带来什么?微软、谷歌、苹果等各大厂商纷纷瞄准HTML5，这将是他们瓜分Web的最佳武器，谁利用的好，谁就会赢得最终的胜利。在这惊心动魄的战役中，谁也不服谁，你“创新”了HTML5 这个特性，嗯，很好，我也实现它，实现的比你更好，那朋友们可能会疑问了这不是很好的良性竞争么，HTML5将会越来越繁荣的啊。可是，朋友们不要忘记，HTML5现阶段只是一份草案。尚未定标准。如果这样话，各种各样的所谓的“创新”，就形成了五花八门的API，好吧，这对开发者来说又是一番兼容苦战。也许你还挺喜欢浪费时间写一些本不应该有的兼容代码，而且你还喜欢用大概一半的时间去调试javascript。在来看中国浏览器用户的生态环境，IE6为什么占的比重那么大?我觉得有几点原因：
1、盗版XP系统太多。
2、网吧基本上全是IE6。
3、国企或大型企业内部都用IE6。
想要干掉IE6，您觉得要多久?在回头看HTML5，手机都要做兼容的，何况应用到PC浏览器?那反过头来看Silverlight，这时候优势就体现出来了，SL开发的软件不仅仅可以运行在手机上，PC上也可以，因为SL显示是基于分辨率的，所以用户体验是一致的，那这算不算一种跨平台?用户对浏览器的版本更替是不敏感的，也别指望在我以上说的三点中找突破口。然后我们看看App Store的盈利模式，然后再想一想，Web App是否也有对应的盈利模式，并且有的开发商已经开始盈利了?如果没有?你是否敢第一个吃螃蟹，并且不怕别人踏着你的尸体走过去?如果想用HTML5跨所有平台，还需要很长一段路要走，首先那几大巨头先达成协议再说。当你从迷雾中，看清楚整个格局后，才会发现Web世界正在被不断被瓜分着，而你所使用的技术(HTML5+CSS3+Javascript)正是他们各自的领地，整个格局被他们打破，重新开始新一轮的麻将中，当然他们打的不是小牌。
观点二：Silverlight要完蛋了?
首先，HTML5标准近几年肯定不会定下来，设计+几万项测试+各大巨头谈判+浏览器厂商实现，这段时间可不太短，那就算这些咱不管他，就当 HTML5标准已经订好了，大家可以用他开发了，而且大部分用户也很自觉的装上了您最新版的浏览器，并且您最新版的浏览器支持XP系统，这些先决条件很完美不是么?用户的需求是无止境的，糟糕，HTML5实现不了，软件厂商抓耳挠腮，只好对用户说，您的需求我们满足不了啊，HTML5不能实现。除非，除非标准在次更改(PS：标准貌似十几年改一次?)，软件厂商无奈的苦笑着。看到这里，您想到什么了?没错，标准一旦制定要更改它简直千难万难，而用户对于标准之上的功能实现可视眼馋的紧，这时候您会怎么抉择?无疑是这些浏览器扩展：插件。所以，放下您的成见，让HTML5和插件友好相处吧，他们未来的作用一定是互补的。
观点三：Flash为什么会占据PC富客户端的大半个江山?
微软擅长生育晚产儿，Silverligh无疑是其中的一个，当各大页游厂商用Flash做出可以赚钱的产品后，Silvelight才被各大厂商熟知，但熟悉就未必会用他，结果导致其默默无闻的成长，首先我们分析一下，这其中的问题所在。
1、Flash成熟作品多，开源社区活跃。
为啥要放弃现在的深厚底蕴，而用你Silverlight，难道你比他多什么亮点?晚产儿的优势在哪里?
2、Silverlight低调，无人所知。
用Silverlight开发的大部分是企业应用，默默无闻，谁也不知道有哪一个软件是用Silverlight做的，这样就产生了一个莫名其妙现象，做的东西比较多，但就是没有知名度，造成推广障碍。
3、职位稀少，工作机会稀少
各大软件开发商提供的职位太少，让开发人员总以为Silverlight没有前途。大家可以去大型招聘网站，搜索一下Silverlight关键字，在北京地区、全职、最近一周，反正我只找到20个。在这样一个大环境里，谁还敢去学习Silverlight?这就是短板所在。
观点四：创新工场
我用三个比喻来说明创新工场的创新之处。
其一：鸡和蛋：
用一个不恰当的说法，创新工场相当于鸡，其孵化的公司相当于蛋。鸡负责鸡蛋的孵化以及后勤工作，她有丰富的渠道、资源、名气供蛋使用，蛋的职责就是破壳而出，然后快速成长，子母连环锁就此产生。鸡生蛋、蛋生鸡依然是永恒不变的话题，互利共生可能就是诠释这句话最佳答案。
其二：娱乐公司和明星：
“想发财，先出名”，不知道这是哪位前辈提出的见解，当真是独具眼光。娱乐公司提供舞台，其他就靠你的手段，是被潜还是作秀，还不是随手沾来。这套也可以用创新工场身上，场子把后勤给你打理的井井有条，你的工作就是：不成功，先出名，出完名，在赚钱。先让大众你知道有你这么号人后，在慢慢出产品。娱乐圈都赶潮流，不管这流是寒流还是暖流，游一遍在说，没准就游出位了呢。创新工场孵化的公司也是同理，啥流行，先游一圈在说。哥们这么做，我也可以理解，传统互联网想出头要几年沉淀，无法短期见成果，而且成本也相对就较大。咱还总结了新词：“流行效应”，解释：用流行的平台更容易做出流行的产品。
其三：主服务器和子服务器
服务器集群之优势在于可以更好的资源利用与负载均衡，随着这种优势的不断突出，云的概念呼之欲出，那么当这团“集团云”以创新工场为中心服务器，其孵化公司为子服务器全面运作的时候，高负载，高效率，高资源利用率仿佛就不是那么遥不可及了。当创新工场转身为“商战黑客”，试问谁能抵挡住其DDOS攻击?没有疑问。
总结一下吧：
母凭子贵、子凭母贵、子母连环锁，一条互利共生的链条就被巧妙地连接起来了，子母公司共享资源、产品、财富、经验等等，假以时日“集团云”就会脱颖而出，不得不赞叹这种模式的巧妙之处。
观点五：太子 —》 HTML5
说一下HTML5带给移动互联网产业的变化。
其一：那么多的平台，移植起来真的很悲剧
粗略算一下：目前移动设备大概有一下几种平台：Symbian、Windows Phone、Android、iPhone、iOS以及未来的Windows 8等，移植的代价可想而知。反观HTML5，基本上已经可以实现跨平台开发了，而且各大手机浏览器对HTML5的支持也都是“争先恐后”，生怕晚了一步，而且开发web app也有一些开源框架非常不错，例如PhoneGap、QT、JQuery Mobile 等等。
其二：趋势、趋势
Windows平台似乎也经历过C/S向B/S转变的过程，当然一些C/S软件是不可替代的，但B/S后的软件优势也非常明显，那么手机开发似乎也正在踏上这条路，版本更新更容易、自由性更高等优势。
其三：被腐蚀的应用商店
移动应用开发者对软件商店的“黑卡”也许不会陌生，当然更加黑的手段刷排名也许还未曝光，但是这块神圣地正逐渐被黑暗吞没。
其四：我想要自由
应用商店越来越高的门槛与审核制度让许多开发商望店兴叹。一些好的应用也许会被讨厌你软件的审核员所淘汰，我想这种情况你可能接受不了，但这就是事实。
观点六：JavaScript不是很给力
说实话，我是JS的坚决拥护者，她编程方式灵活多变，写程序简直是一种享受，但是一些问题总该需要提出来。
其一：缺少一款强大的IDE
只要JS文件上了2000+行，调试和开发就非常的不方便，加一个空格都要等待一段时间，期待一款可以加快代码解析与智能感知自定义属性和方法的IDE，不知道谁有好的可以推荐给我。我目前用的是VS2010 SP1。
其二：坑爹的兼容性
无尽的兼容性测试与调整仿佛占了总开发量的一半时间，对于我这样有“代码洁癖”的人来说，是绝对不能容忍的。总之，这是件浪费时间和精力的事情。不过，事情都有转机，一些第三方类库，例如JQuery，就可以让我们不去关注兼容性问题。但是，一些场景就不适合用这么大的库，例如HTML5游戏开发。另外，吐槽一下，HTML5在各浏览器表现也不一致，而且支持的也不到位，更加大了工作量，太坑爹了。
其三：源码保护
JS混淆 + 加密 + 压缩 = 开源。
任何JS代码，不管如何做手脚，都是表面文章，真正的代码却还是需要在JS引擎中执行的。
而JS引擎执行的代码，永远都是最真实的，而我恰恰就可以得到这些真实的代码。
除非各大浏览器厂商考虑到这个问题，并做出合理的措施，才有可能真正的实现源码保护。
观点七：程序员一定要有的观念
当我们操作那些API开发软件的时候，是否想过自己曾经用过的语言中，有那么多地方是相似的，for、if.。..。.在这些相似的语法中，我们是否发现自己没有了创造力，一切都是以自己掌握多少类，多少个方法而骄傲?浮华下面掩盖的都是本质。而殊不知思想是最重要的。朋友们，放下浮躁的心吧，别在讨论什么技术有前途，什么技术没前途。当我们掌握思想这种原动力的时候，什么武器都是顺手牵来，招招指向要害。HTML5是趋势，是未来的大趋势，Silverlight和Flash是现在的解决方案，也是未来HTML5的有力武器，他们是相辅相成的关系。我昨天开源了一个库《也把咱的小类库拿出来晒晒》，很多朋友下载，我很高兴，希望这些能帮助到你，我也希望你们也可以把自己的库共享出来，因为这不只是简单的分享，而是解放你的思想，让你学会抓住本质，培养思路，丢弃这种API式的编程方法。
作者博客：zjyuan