Skip to main content
GameDev.net gamedev.net
🔒 Locked

HTML5 vs. Flash vs. Silverlight

Started by Ispiro Sep 2, 2011 at 7:20 PM 15 replies 6.4k views
Original Post
Ispiro
Ispiro
Hello,

Lately I've been interested in trying to create my own social browser game. However, I'm not sure whether to use HTML5, Flash or Silverlight?

I know some C++, Lua, Python, and PHP. Just thought I should put that out there.

So, whats your thoughts?
Sirisian
Sirisian
I personally used to like Actionscript 3.0, but lately I find it easier to just use HTML5 canvas. For a social game it would work well. Just realize that old browsers lack the canvas tag. If you care about supporting pre IE9/Chrome/Firefox etc modern browsers then use Flash. Learn jquery if you go the HTML 5 way. Simple ajax queries to a PHP backend (with database) is very easy to use. Also regarding performance you'll need to test things.
Gamer Gamester
Gamer Gamester
HTML5 looks to be the most forward-thinking choice. Even the newer versions of IE support Canvas! Instead of depending on one vendor (Adobe) for your platform, you'll have multiple (Mozilla, Google, Microsoft, Opera, etc.).

If you do choose to go with HTML5, I highly recommend the book: JavaScript: The Definitive Guide by David Flanagan (6th Edition).
Studying "HTML5" won't really set you up right, what's going to be more important is the browser programming language: JavaScript.
The book I mentioned above also has the best coverage of the browser APIs that I've come across (including HTML5), and is very up to date (published earlier this year).
It's not really geared for people new to programming, but since it looks like you have some experience it might be a good fit.

Personally, I'll never go back to Flash. However, there is one HTML5 downside I should mention: browser support for audio is not quite there yet (Flash still does this better). Chrome and Firefox have new Audio APIs that look very promising, but they're neither an official nor de facto standard yet (they even differ from each other!). You might be able to coerce the HTML5 Audio tag (which is supported across browsers) to work for you, but this has its limits (and currently a few browser inconsistencies in "the details").
Ispiro
Ispiro
Thank you very much for your input, but I have a few more questions I was hoping you can answer.

Are there any limitations to what kind of games I could make? For example, games like the ones created by Zynga(Poker, Farmville, etc.) Would these be possible to create using HTML5? Or would flash be the better choice?

Alright, so let's say I decided on HTML5 instead of Flash. How complicated can browser games be before performance issues kick in and start trouble? And let's assume I allow players to upload their own HTML5 game to my website, are there ways to make it impossible for them to steal cookies, etc.? Or is this risk there even with Flash anyway?

Best Regards,
Ispiro.
WreckSector
WreckSector
I developed my little interactive comics in HTML5/Javascript. There were some frustrating parts (which I'm sure you'd encounter no matter which route you took), but ultimately, I really enjoyed working in this environment. I love that users don't need to have flash installed, or silverlight. For me, I think there's just something really cool about writing some javascript and immediately seeing results in a web browser. Just seems a little more direct than Flash and Silverlight (in my opinion!).
Cornstalks
Cornstalks
Silverlight is going away*, so I wouldn't bother with it.

[edit]

*That is, it will be around for several more years, and microsoft will continue to support silverlight 5 for a few years, but their is a good number of rumors going around that it won't remain a priority at microsoft and that there is a good chance it will get phased out.
Chris_F
Chris_F
Use JavaScript and the Canvas API. Why? Because they are FOSS, and that is worth supporting.
_the_phantom_
_the_phantom_

Instead of depending on one vendor (Adobe) for your platform, you'll have multiple (Mozilla, Google, Microsoft, Opera, etc.).


Yep, there is nothing better than living in a world where implimentation bugs on multiple platforms can cause you problems...

oh wait...
Gamer Gamester
Gamer Gamester

Yep, there is nothing better than living in a world where implimentation bugs on multiple platforms can cause you problems...

oh wait...


In practice, I haven't run into many of these bugs. This is, of course, on modern browsers from within the past year or so. 5 or 10 years ago these sort of bugs were all over the place. They've mostly dissolved away ever since I've had the privilege of dropping support for all versions of IE (including the newer 9, which, though much improved, is still lagging, despite whatever Microsoft marketing might say). Web development is a completely different experience once you drop IE.
Alpha_ProgDes
Alpha_ProgDes
I think the overall benefit of JavaFX, Flash, or SL is that you don't have to worry about whether or not a vendor has implemented a certain feature or if all the vendors implemented said feature the same. Whereas with HTML 4 or 5 that issue still exists. HTML 5 doesn't really solve that issue. It seems to because at this point everyone is playing nice and is actually following the standard.
Beginner in Game Development?  Read here. And read here.  
upqtz
upqtz

I think the overall benefit of JavaFX, Flash, or SL is that you don't have to worry about whether or not a vendor has implemented a certain feature or if all the vendors implemented said feature the same. Whereas with HTML 4 or 5 that issue still exists. HTML 5 doesn't really solve that issue. It seems to because at this point everyone is playing nice and is actually following the standard.



That's definitely a big advantage. Other advantages include getting to work with a strongly typed language, traditional OOP support, more advanced debugging tools, better asset creation tools, and a nice library of free code.
Gamer Gamester
Gamer Gamester

Other advantages include getting to work with a strongly typed language, traditional OOP support, more advanced debugging tools, better asset creation tools, and a nice library of free code.


Except some consider weak typing to be an advantage... though more importantly, JavaScript is dynamically typed. JavaFX and (optionally) Actionscript are statically typed. I consider dynamic typing a huge advantage. People are still arguing between static & dynamic typing, but I tend to think the static typing fans are being a little stubborn (note: I used to be one). Static typing proponents seem to view dynamic typing as reckless and unsafe. I guess that, like me, they were brought up on static typing, and can't imagine programming without it. Since taking the time to gain experience with dynamic typing, I've come to realize that it allows me to spend less time dealing with typing concerns while granting me a wider range of computational expression. A good article by a self-proclaimed "statically typed bigot" is here.

There are people who also consider prototypal inheritance an advantage (over the non-"traditional OOP" classical inheritance that you speak of).

I agree with you on the tool situation, but as far as the programming language is concerned, I think JavaScript has the advantage (if you manage to avoid the hundreds of bad tutorials for it and stick to the few good books on it). Dynamic typing, first-class functions, closures, object literals... it's very expressive.
HappyCoder
HappyCoder

Are there any limitations to what kind of games I could make? For example, games like the ones created by Zynga(Poker, Farmville, etc.) Would these be possible to create using HTML5? Or would flash be the better choice?

Alright, so let's say I decided on HTML5 instead of Flash. How complicated can browser games be before performance issues kick in and start trouble? And let's assume I allow players to upload their own HTML5 game to my website, are there ways to make it impossible for them to steal cookies, etc.? Or is this risk there even with Flash anyway?



I am working on an HTML5 project right now and it is using a port of Box2D physics. It runs pretty smoothly even with a considerable amount of objects in the scene. So visual rich interactive games aren't a problem. So comparing flash and HTML5

Advantages of HTML5
Integrates nicely with the browser. No plug in required.
Can be made to work with on iPhone. Flash can't.

Disadvantages
May need special logic for specific browsers.
Inconsistencies across browsers when drawing. I have run into some small problems with drop shadows and other special drawing features.
Poor sound support, as of now.


Advantages of Flash
Images/code/sounds all wrapped up into a nice swf package.
Consistent across browsers.

Disadvantages
Doesn't work on iPhone.
Disconnected from rest of browser. A flash app or game has a flash "feeling" to it. This is what I feel anyway.


As with cookie stealing. Both javascript and flash can steal cookies on the same domain as the script/swf. So they would only be able to steal cookies from you website hosting the content.

Flash carries many advantages but so does HTML5. They are both well suited for online games.
My current game project Platform RPG
smr
smr

[quote name='upqtz' timestamp='1323369842' post='4891882']
Other advantages include getting to work with a strongly typed language, traditional OOP support, more advanced debugging tools, better asset creation tools, and a nice library of free code.


Except some consider weak typing to be an advantage... though more importantly, JavaScript is dynamically typed. JavaFX and (optionally) Actionscript are statically typed. I consider dynamic typing a huge advantage. People are still arguing between static & dynamic typing, but I tend to think the static typing fans are being a little stubborn (note: I used to be one). Static typing proponents seem to view dynamic typing as reckless and unsafe. I guess that, like me, they were brought up on static typing, and can't imagine programming without it. Since taking the time to gain experience with dynamic typing, I've come to realize that it allows me to spend less time dealing with typing concerns while granting me a wider range of computational expression. A good article by a self-proclaimed "statically typed bigot" is here.

There are people who also consider prototypal inheritance an advantage (over the non-"traditional OOP" classical inheritance that you speak of).

I agree with you on the tool situation, but as far as the programming language is concerned, I think JavaScript has the advantage (if you manage to avoid the hundreds of bad tutorials for it and stick to the few good books on it). Dynamic typing, first-class functions, closures, object literals... it's very expressive.
[/quote]

I like javascript. A lot. Closures are a big win, albeit just a convenience (as you can always just package up any shared state in an object our other data structure and pass it around). But I do prefer static typing. When your app gets big, it gets difficult to remember the names of functions, variables, methods, etc. Not to mention the number of arguments expected, their types, order, and all of that. I have experienced this time after time in my day job.
upqtz
upqtz

[quote name='upqtz' timestamp='1323369842' post='4891882']
Other advantages include getting to work with a strongly typed language, traditional OOP support, more advanced debugging tools, better asset creation tools, and a nice library of free code.


Except some consider weak typing to be an advantage... though more importantly, JavaScript is dynamically typed. JavaFX and (optionally) Actionscript are statically typed. I consider dynamic typing a huge advantage. People are still arguing between static & dynamic typing, but I tend to think the static typing fans are being a little stubborn (note: I used to be one). Static typing proponents seem to view dynamic typing as reckless and unsafe. I guess that, like me, they were brought up on static typing, and can't imagine programming without it. Since taking the time to gain experience with dynamic typing, I've come to realize that it allows me to spend less time dealing with typing concerns while granting me a wider range of computational expression. A good article by a self-proclaimed "statically typed bigot" is here.

There are people who also consider prototypal inheritance an advantage (over the non-"traditional OOP" classical inheritance that you speak of).

I agree with you on the tool situation, but as far as the programming language is concerned, I think JavaScript has the advantage (if you manage to avoid the hundreds of bad tutorials for it and stick to the few good books on it). Dynamic typing, first-class functions, closures, object literals... it's very expressive.
[/quote]

Aside from the debugging and context suggestion functionality that IDE's make available through static typing, there are also performance advantages. For smaller applications, I don't mind dynamic typing. But for bigger applications, I really hate not having it. AS3 is very convenient in that it allows both, and there are occasions where it makes sense and is conventional to make use of dynamically typed objects or dynamically added fields. ActionScript's and JavaScript's shared ECMAScript lineage gives AS3 the handy features that JS has, such as closures and literals. It's nice to be able to use these in the situations where they make sense but still benefit from the advantages afforded to strictly typed languages.
Nypyren
Nypyren
The vast majority of my job involves dealing with existing codebases (maintaining, porting, and interop). With C, C++, C#, Java, the static type system gives a lot of extra information to me (through the IDE) as I'm figuring out what other people's code does. I've recently started working on Actionscript and Javascript projects, and find myself wanting that rich type information back.

To all proponents of dynamically typed languages: How do you deal with this situation? Is it something you encounter on a regular basis? Or is there some holy grail of code maintenance in dynamically typed land as well?

Have any of you guys that strongly enjoy dynamic typed languages tried implicit-but-statically typed languages like C# and F#? If so, have you used them enough to form reasons for the paradigm you like more?
Gamer Gamester
Gamer Gamester

The vast majority of my job involves dealing with existing codebases (maintaining, porting, and interop). With C, C++, C#, Java, the static type system gives a lot of extra information to me (through the IDE) as I'm figuring out what other people's code does. I've recently started working on Actionscript and Javascript projects, and find myself wanting that rich type information back.

To all proponents of dynamically typed languages: How do you deal with this situation? Is it something you encounter on a regular basis? Or is there some holy grail of code maintenance in dynamically typed land as well?

Have any of you guys that strongly enjoy dynamic typed languages tried implicit-but-statically typed languages like C# and F#? If so, have you used them enough to form reasons for the paradigm you like more?


Using a REPL for interactive development can be very helpful. In the case of JavaScript, most browsers have some sort of "Web Console" you can use to interact with your code. You can type console.dir(my_object) to see all its properties and methods. In many dynamic languages, there are interactive REPL shells that support auto-completion, which you can integrate into certain text editors. Some people consider this a disadvantage (would rather have a pre-baked IDE), while others consider it an advantage (because they're going to use vim or emacs anyway).

Really, the only times I've had these sorts of problems (while not using a REPL) is when I've been using code that was ported from a statically-typed language, so I'm guessing a different sort of dynamic programming style or code maintenance emerges. I'm having trouble pinpointing what these differences are at the moment, but perhaps someone who's investigated this issue more deeply has some suggestions for us.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.