HTML5 vs FLASH vs SILVERLIGHT

Introduction

HTML5 kills off flash; HTML5 kills off Silverlight; HTML5 makes the dinner and does the ironing too. HTML5 is going to save the (tech) world. I’ve heard it all in the last year or two. Very rarely have I seen a balanced article or a writer that understands the concepts involved. Even worse are the (non technical) tech journalists who write an article on this subject purely to boost their own exposure.

This article attempts to provide a bit of history on the subject. It also attempts to pacify the situation and explain why it doesn’t really matter.

This article focuses more on Silverlight than other technologies but the principles are the same for these too.

Background

FLASH and FLEX

Flash arrived on the scene many, many moons ago to add some pizzazz to the web, largely because HTML was limited and hence the experience was pretty mundane and boring.

Flash is a plug-in that needs to be installed on the CLIENT machine running the browser. Notice the word CLIENT here as this will become important as we go along.

As the years went on, people tried to push Flash to act more like business applications that you would normally build in .NET or similar. ADOBE (Macromedia) realised this and also realised Flash wasn’t up to the job. FLASH was useful for animations and small scale web stuff but not Enterprise level applications.

Most people don’t know ADOBE brought out FLEX for this purpose. FLEX was used as the front end for business applications and charting type stuff. This would be as an alternative to Java server pages (JSP) or ASP.NET.

SILVERLIGHT (SL)

Around about the same time as FLEX was gaining momentum and maturing (around 2006), MICROSOFT was building SL.

SL was released in 2007 but the first mature version arrived in 2008 with SL 2. SL was a direct competitor to not only FLASH but ALSO FLEX. This is an important point that most people don’t get and hence don’t understand why the current chatter about HTML5 vs. FLASH vs. SL is not as important as they think.

HTLM and Javascript (JS)

HTML and JS have been around forever and have always been popular web tools because they are free and cross-browser compatible. It is only in the last couple of years with the hype around HTML5\JS that the HTML5 vs. FLASH vs. SL chatter began.

There was a slight precursor to this which was the browser video playback chatter that everyone and their donkey had an opinion on too.

It is worth noting that HTML5 can only run in a supported browser that is installed on the user’s CLIENT (PC, laptop, tablet, mobile, etc.). Effectively, this is the same thing as a plug-in. If it isn’t on the client, then HTML5 won’t work. FACT!

To date, around 40% of web browsers are nowhere near HTML5 compliant. This seems to be a fact ignored by the current band of HTML5 evangelists.

APPLE

Apple effectively banned plug-ins from its products. This is when this discussion really kicked off. While annoying all of their users by doing this, i.e., they couldn’t run flash websites or video, users still bought their products. There aren’t many companies that can do that.

Back to the Present

This brings us up-to-date and back to the HTML5 vs. FLASH vs. SL argument.

The fact is that you cannot control the web if you need a plug-in to run your product. This has always been the case and anyone who thought otherwise is naïve at best.

‘Oh but Flash was on 95% of clients so that’s not true’, I hear you shout. Yes FLASH was on 95% of clients but which version did you have installed?

In a previous life, I was a FLASH developer and you would always have to wait around 1-2 years before you could develop a Flash website in the latest FLASH version. Why? This is how long it would take for a large enough percentage of web users to install that version of the FLASH runtime on their clients. We always developed in a version behind the latest version, unless we could control what was on the user’s CLIENTS. There was no point developing something, no matter how cool, if only 20% of your target audience are able to view it.

The writing was in the sand, some might say?

Where are we now?

  • FLASH and SL are dead for the web.
  • HTML\JS have won the battle for the web.

That’s it then? No. This is only (less than) half the story. While the next few paragraphs focus on Silverlight, you could quite easily make similar arguments for other technologies that are ‘dead‘.

The Enterprise

One big factor in this is the Enterprise. An Enterprise is a company or business, usually, but not necessarily, of a large size. An Enterprise will have thousands of employees, working at different locations, sometimes around the world.

Enterprises like Intranets – internal browser based communication systems. Enterprises like browser based applications that run on these Intranets because they are easy to distribute and maintain.

Employees of Enterprises work on clients (PCs, laptops, etc.). These clients are owned and maintained by the Enterprise, i.e., Enterprises can install whatever they want on their client machines – see I told you we’d come back to the client thing – and have the processes in place to do this regularly and en-masse.

The take of up SL, and FLEX to a much lesser degree, within these types of organisation is massive, especially in the banking sector who rely on rich, interactive applications (my version of RIA). Other technologies just do not cut the mustard. This is a FACT!

SL has a great advantage in these types of organisations who are mainly .NET based organisations – there are a lot of JAVA based ones too, who would probably have used FLEX rather than SL: SL sits nicely in their application stack.

These Enterprises build applications in an N-Tier fashion. This would involve a Presentation (UI) layer, service layer, business layer and data layer for example. This means their skill-sets are lean and advanced, having great cost benefits for development, testing, deployment and maintenance.

JS just can’t touch JAVA or .NET in terms of being a mature, deep, high quality programming language. JS has a small set of base classes and can’t stand alone needing to be interpreted by a browser, for example.

SL uses its own subset of the .NET framework so works within a managed environment. People who are used to .NET are already (partly) used to SL.

Enterprises have big sacks of cash, and, usually, money talks.

Windows Phone

Windows phones are gaining great momentum as we speak and SL can be used to build apps for these phones.

This adds weight to SL as a product.

Of course you may, and should, question whether it is appropriate to use HTML5\JS if you are developing the same app for Android and the iPhone.

Who knows, if apps become more complex (likely), then SL might be back in there. The more complexity, the more likely JS is to be problematic as a solution.

XBOX

It is also worth noting that Microsoft may give SL a new lease of life within the Xbox and Kinect environment:http://tinyurl.com/3v3lsyw.One to look out for and again adds more weight to SL as a product.

Summary

What’s the common thread between all this?

  • You can control the client you can control what you develop in. It doesn’t matter what Apple or anyone else say.

As with any development, you should always ask ‘What is the best tool(s) for the job?’

In the Enterprise, this is regularly Silverlight. SL 5 will pack a whole lot of weight compared to SL4. All the gaps and missing functionality will now be there. SL 5 is a mature product and will be good for a couple of years on this release alone. If the answer to the question above is Silverlight, then use Silverlight. If it is something else, use something else. Simple!

Will Microsoft produce a SL6 or SL7? It would be nice, but it doesn’t really matter at this point in time. Things change. Being a good developer means keeping on top of your skills and moving with the times. None of us were Silverlight developers five years ago.

XAML and C# will definitely be skills that will be usable in the Windows 8 environment and your SL apps will run fine there too (http://tinyurl.com/7n8pp62) so stop worrying.

As 37signals say ‘Planning is guessing’. This is so true. Concentrate on the next few months as this is hard enough to do well. What you think will happen in 2 years time probably won’t and something completely different will.

This is the paradox of the world we work in: we love the fact that technology changes so fast, we hate the fact that technology changes so fast.

from:http://www.codeproject.com/Articles/288193/HTML5-vs-FLASH-vs-SILVERLIGHT

时间: 2024-10-18 02:34:24

HTML5 vs FLASH vs SILVERLIGHT的相关文章

html5结合flash实现视频文件在所有主流浏览器兼容播放

由于html5的出现,让网页中的视频.音频有了更加便捷的实现方式.但是video.audio标签只在IE 9+.Safari 3+.FireFox 4+.Opera 10+.Chrome 3+的浏览器版本得到了支持,并且各浏览器对于视频编码格式的支持不一致,这就需要我们考虑一个综合的实现方案,使得视频在不同浏览器中都能顺利播放,而且在老版本的浏览器中也能得到支持. 以下是结合项目经验,总结出的几种方案,与大家分享. 方案1.使用VideoJS插件实现兼容 插件下载http://videojs.c

librtmp推流使用aac编码音频的html5和flash播放问题

公司项目中使用rtmp推流,音频编码aac.视频编码H264.windows和android平台都没有发现问题.然而在IOS版本的APP中发现几个问题:1. 推流后flash播放异常2. IOS平台微信分享后html5播放异常但是在PC上播放正常,android平台上html5播放正常. 经过两天的钻研,发现问题如下:1. rtmp建立连接的时候先发送音视频相关参数.或者第一帧发送的数据应该如下: 1 m_pPacketAudio->m_nChannel = 0x04; 2 m_pPacketA

工作中碰到uploadify插件两个版本:HTML5和Flash

最近工作中碰到上传文件插件使用问题:在工作中碰到app嵌套html5页面中使用上传文件问题,因为之前使用的是stream上传插件(http://www.twinkling.cn/),但是该插件跨域传输出现问题,无法传输成功,经过几次调试都无法解决跨域,然后我就换了个插件uploadify,一开始用的flash版本,但是此版本不支持在app中使用,于是就想到了用html5版本的,感觉笨死了,这个问题整了时间有点长了,下面开始说html版本的使用 首先,页面代码: 后台代码: @SuppressWa

HTML5关于上传API的一些使用(下)

通过前面两篇的分享,我们已经搞定了单个文件的普通的上传,包括文件预览,图片预览,上传速度等前端界面的显示,这次我们来谈谈关于>XMLHttpRequest2.0在界面之后假如才用分片上传能做到一些什么功能 关于分片上传 为什么要使用分片上传? 考虑如下场景,假如用户需要在一个视频分享社区上传一部.avi的视频文件进行分享,大小在2G以上,这个时候用户假如在上传的过程当中,发生了宽带掉线,不小心关闭了浏览器等这种意外的事情,用户这个时候除了重传整个文件以外,没有其他更好的选择,可能用户就不会考虑再

HTML5学习笔记(1):HTML5介绍与语法

HTML5介绍 HTML5是继HTML4以后的下一代HTML标准规范,它提供了一些新的元素和属性(例如<nav>网站导航块和<footer>).新型的标签有利于搜索引擎和语义分析,同时更好地帮助小屏幕装置和视障人士使用,除此之外,也提供了一些新的功能,比如视频音频用的<video>和<audio>,总结而言,有如下几大特点: 取消了一些HTML4里过时的元素和属性标记 其中包括纯粹显示效果的标记,如<font>和<center>,它们

Flash上传组件之SWFUpload文件上传

一.什么是SWFUpload? SWFUpload是一个客户端文件上传工具,最初由Vinterwebb.se开发,它通过整合Flash与JavaScript技术为WEB开发者提供了一个具有丰富功能继而超越传统<input type="file" />标签的文件上传模式. 目前此项目放在:https://code.google.com/p/swfupload/ 对应的中文API:http://leeon.me/upload/other/swfupload.html 由于SWF

HTML5学习笔记简明版(1):HTML5介绍与语法

HTML5介绍 HTML5是继HTML4以后的下一代HTML标准规范,它提供了一些新的元素和属性(比如<nav>站点导航块和<footer>).新型的标签有利于搜索引擎和语义分析,同一时候更好地帮助小屏幕装置和视障人士使用.除此之外,也提供了一些新的功能,比方视频音频用的<video>和<audio>,总结而言.有例如以下几大特点: 取消了一些HTML4里过时的元素和属性标记 当中包含纯粹显示效果的标记,如<font>和<center>

Plupload使用API

Plupload有以下功能和特点: 1.拥有多种上传方式:HTML5.flash.silverlight以及传统的<input type=”file” />.Plupload会自动侦测当前的环境,选择最合适的上传方式,并且会优先使用HTML5的方式.所以你完全不用去操心当前的浏览器支持哪些上传方式,Plupload会自动为你选择最合适的方式. 2.支持以拖拽的方式来选取要上传的文件 3.支持在前端压缩图片,即在图片文件还未上传之前就对它进行压缩 4.可以直接读取原生的文件数据,这样的好处就是例

PHP上传视频

https://github.com/chaping/plupload_docs 这下载 lupload有以下功能和特点: 1.拥有多种上传方式:HTML5.flash.silverlight以及传统的<input type=”file” />.Plupload会自动侦测当前的环境,选择最合适的上传方式,并且会优先使用HTML5的方式.所以你完全不用去操心当前的浏览器支持哪些上传方式,Plupload会自动为你选择最合适的方式. 2.支持以拖拽的方式来选取要上传的文件 3.支持在前端压缩图片,