I am currently half-decided to use Kohana + Zend as needed for the PHP part. What I would need next is an excellent base for JavaScript code. There are a bazillion of contenders here and choosing isn't exactly as easy as with PHP.
I would need practically everything from form posting and retrieving results to skinnable widgets and animations. For this reason using multiple libraries will probably be a must, as no one framework can do it all. The requirements I have would be this (initial list):
Good browser support. WebKit-based is hardly an issue and Firefox 3+ is good. However, I'm looking at you Internet Explorer. IE 6 can be ditched, seriously, but 7+ support is needed.
Good performance. While WebKit has had a stupidly fast JS implementation for quite a while (and Chrome even before), Firefox has only recently got TraceMonkey and don't even get me started on Internet Explorer. While it is true that you can't do much about IE as anything will be slow, I don't want to try running Chrome Experiments in the others either.
Excellent support. This is a total must. The better the support, the more inclined will I be towards a library.
I am currently looking into jQuery as it is a very neat library, but the quality of plugins is questioned by some. Processing.js looks extremely promising, but IE does not support canvas, thus something has to be done about that and I am not sure how it could be replaced.
Go with a known library that is used by many sites. This will ensure all 3 of the points you have mentioned.
Personally, I would go with jQuery for these above reasons:
Great cross browser support
Good performance, as it is a thin api layer
Excellent support. Good documentation, loads of other devs
Although jQuery seems to be the most used library these days, there are other very good candidates as well.
One of them are YUI Library.
YUI has excellent documentation, and support. And the source code is really good.
YUI is developed by Yahoo!, where Douglas Crocford is architect (the author of JavaScript: The Good Parts, and the man behind JSON). Yahoo! is well known for their focus on JavaScript development.
YUI has good browser support and is fast and robust.
If it's war simulation and you have custom objects that you want to animate beyond the simple CSS effects and animations, then canvas tag is your best bet. It's as close as you can get to Flash but much more smoother. Processing.js looks really good for manipulating the canvas.
If that's the core component of your game, then I see the other libraries as adjunct to Processing.js that can be scrapped out without any deep commitments. That said, jQuery is great if you're dealing heavily with the DOM. It has really good support and community. MooTools is highly modular and has been traditionally strong with animations. YUI is a great library too, but a little verbose for my taste. Thought, Yahoo has made heavy changes with v3 to fix that. And a bunch of other libraries, that I don't use at all.
Dojo is a great library for writing web applications; however, never having written a game, I'm not sure if it is well suited for that sort of application. I must warn you though that the Dojo documentation is crap. Absolute crap. On the other hand, things like dojo.hitch, dojo.require, and dojo.partial are absolute joys.
I would try to avoid using cross-cutting libraries (like Dojo+jQuery) as much as possible. There's not really a good reason to do it and will create bloat and confusion in your application from day one.
That said, using multiple, non-overlapping libraries does make sense for a project like this. You might want to look into using Processing.js for visual needs and either Dojo or jQuery for your core.
Some other things to consider. Targeting IE, even IE8, for JavaScript game development is a bit ridiculous because of its slow performance and lack of canvas support. Also, according to John Resig, developing games in JavaScript is hard.
Have you considered being a pioneer (wink) and trying something out in 03D?
Related
I'm using pretty recent CSS features such as viewport units and flex-boxes. These are great for making fluid layouts, and to get rid of extra-markup and dirty CSS hacks.
I'm using prefix-free to handle some vendor-prefix issues, but that got me thinking, is there any sort of script that can detect the use of recent CSS features and somehow make calculations in order to render the elements that use that feature correctly? (if the browser doesn't support those features, of course)
The site I'm making makes use of Bitcoins and WebSockets (and to my knowledge, socket.io falls back to long-polling), so I guess maybe many of the users will be somewhat "tech-savvy" and have recent browsers, but I don't really know what to expect, honestly. And it'd suck if the site looked completely broken for some people.
I'm the sole developer of this and the idea of making a bunch of the layout compatible with older browsers is... well, daunting. I just got started so I might as well use old CSS techniques, but I'd really like to use the latest stuff.
It really sucks that there is a lot of new, cool stuff, but old browsers are holding everyone back...
Thank you.
What you're looking for is commonly called a "polyfill".
There are many polyfills available... usually several for each feature. You can find packages like Webshim which come with many out of the box: http://afarkas.github.io/webshim/demos/
Use http://caniuse.com/ to check for browser compatibility. It often links to polyfills in the comments section.
I'm creating a web-based online game and am trying to find the best fit in terms of a framework for the front end of the game. The back end of the game is currently using asp.net mvc 2. Given that I could take the controller actions and turn them into WCF service actions the choice in the back end should not affect my options of a front end.
One thing that is certain, it does need to play in a browser. I have done some research on an HTML 5-only front end as part of this process and am probably leaning in this direction but I have a few concerns:
Assuming this game is completed this time next year, what kinds of difficulties will I have with current HTML 5 adoption levels? Specifically I'm worried about Firefox 3.6 and IE 7/8 still having a large install base. I have looked at Chrome Frame to solve the IE problem but am not sure if there are drawbacks to that I am unaware of either (other than the installation requirement).
I'm used to doing C# with a nice IDE complete with realtime information about whether the code compiles and intellisense reminding me of symbol names. Am I going to run into a problem with Javascript where my code becomes big and difficult to manage? The accessibility problem that a Javascript only engine solves for my users is more important than convenience for me but it of course can't be unmanageable either.
Are the HTML 5 engines on the market right now mature enough to trust with my time investment? Am I at high risk of adopting a framework that will fall into disrepair in a year from now? Of the engines I have looked at, none seem to have really great community support, am I wrong? Are there others out there that do?
here are those I have found thus far:
CraftyJS (http://craftyjs.com/api/Sprite.html)
ImpactJS (http://impactjs.com/)
PropulsionJS (http://www.propulsionjs.com/)
The Render Engine (http://www.renderengine.com/demos.php)
RPG JS (http://rpgjs.com/)
EaselJS (http://easeljs.com/)
Does anyone know anything of the community with these or have any reason to trust that any of these will be well maintained or available for at least the next several years? Does anyone know of another framework that's out there? ImpatJS has the most impressive demo of them all and it's also the only one that isn't free.
Thanks for any help / advice. I'm just worried I'll choose a front-end that I regret and I don't want to have to start from scratch 4 or 5 months down the road.
This is a 2D browser-game. It's not targeting mobile now, but it will be moving to mobile immediately after first launch. One hope is that it will work on mobile fine if I do HTML 5. I may have to tweak it for display size but if I don't have to port it to mobile that would be a definite plus.
This is my two cents having just been through the same decision making process for my company.
Our goal was to create as broad a game as possible that means it needs to run on as many browsers as possible. I ruled out html5 right away because the adoption is not there and seems to be at least a couple years until it reaches more than 60% penetration.
This left me with Flash vs. Silverlight. Flash's installed base is huge and there are many game engines available for it. Flash is a safe bet unless you have specific requirements for video or 3d.
I choose Silverlight because I wanted a good installed base (60%) and I wanted to leverage my companies’ in-house .Net expertise. I also wanted to use WCF for the backend and did not want to mix environments.
Keep in mind that SL5 is going to support most of XNA which is a big deal. There are a ton of XNA engines and source code that you can use to start with.
Here's a great site for looking at html5 browser support:
http://caniuse.com/
I can't speak with expertise on the particulars of HTML5 and Canvas, but...
As far as support goes, you'll still have probably a large bunch of IE7-8 users. IE is a little different than other browsers because you have to DO something to install updates. (i.e, go to the Install Updates in Control Panel or visit ie.microsoft.com). Other browsers (like firefox) just tell you and make the update easy. So your FF 3.6 users should be gone, but IE will still probably be a problem. Keep in mind, though, that much of the old IE browser share is due to IT depts. keeping their users on older versions - something you won't need to worry about.
This could be a problem. However, developing JS in Visual Studio or a similar IDE isn't so bad - there's still IntelliSense and other helpful things, as well as realtime debugging. It's definitely going to be a bit more difficult than C#, especially as many of the new JS api's haven't been implemented into the Autocomplete's of many IDE's.
I don't think you need be afraid of this. At this point, HTML5 and Canvas have gotten far enough that they won't be revoked, only improved. There may be a few modifications of the APIS and such, but not enough to keep you from using it.
Is HTML5 going to replace Flash? No, because games and RIA that require more out of javascript cannot be done until enough of the world is using IE 15 (which is about 5 10 years). Safari, Chrome, FF (maybe), will be up to par here soon but their js engines are going to require good hardware and that's not always going to be there.
Silverlight is a good option but it's not as well supported as Flash. This is why flash will still be around. The next version will support video controllers. It' called Project Mole hill and you can check out my SO question here.
If you want to make super simple games without good graphics try out one of those services you suggested. impact.js is $100, the others look free. In the future we will be able to use node.js to handle request with servers, but in the meantime Flash is certaily the way to go!.
I would much much much rather use javascript but after you start coding and realize the limitations compared flash will make your application standout.
Then for mobile devise, iPad, iPhone, Android, etc.. If you really think your audience is there build the game in the their language. It's more epensive and and harder, but Objective C, Java, they are much faster than HTML, JS, CSS etc...
I did some trial runs with YUI3, Burst engine & Raphael for SVG animation - everything seemed to run well; YUI's dragdrop module even detects the same drag operations on Mobile without adding a single line of code.
I can only imagine that if I had the time, a YUI3 instance available on a Node.js server with Raphael SVG animation would be my choice. You could drop the SVG aspect and use more standard graphic techniques, or perhaps serve up alternate quality graphics for those User Agents with fewer testes. Maybe it could be that your alternate quality version is just another implementation of your game engine - and you might choose to develop games using non-SVG anyway.
Just thoughts mostly, that doesn't help with your real-time IDE debugging...
impact.js has a great community and documentation. It is well worth checking out. I believe iosimpact.js is part of the package (although beta???) allowing for the development of native games for the iphone/ipad.
Yes, indeed you will lose a large user base. But how relevant that user base will be to you will depend on what your target is. Every-day-RPG players are much more likely to have the latest browser than Sunday-Morning-Sudoku users.
Give Eclipse + Web Tools + Aptana a try. It worked really nice for me.
No experience there.
There are certainly people out there who think that HTML5 is going to replace flash in online games. Here is an HTML/Javascript based engine that I heard about few days ago
http://www.youtube.com/watch?v=_RRnyChxijA
I haven't actually used it but it looks really promising and It's designed for similar set of requirements that you've put. It lets you design 2D / 2.5D ( isometric projections ) games. And it does look promising.
Is there a set of open standards technologies that I can use to achieve the same way of development as in Flex and Sivlerlight? I am talking about componentization, separation of concerns, rich graphics, states and effects . Please point out some tutorials and other resources if possible.
P.S. I KNOW that this is technically possible, so please do not respond by sending google search results or general JQuery tutorials. I've seen those already. I need to know how a Flex / Silverlight developer could design and implement an application in roughly the same way (imagine a rich HTML tag set, much like XAML/MXML, behind which stands JavaScript responsible for handling events and business logic. Think also about binding)
You can also check ExtJS and their newly released Designer is it "standards based" RIA JavaScript framework.
Here is a list of examples showing what it is capable of.
For vector graphics you can use great JavaScript library for SVG: Raphaël
For raster graphics you have Canvas API and explorercanvas library from Google for IE compatibility
If ExtJS charts are not enough for you, you can try HighCharts which uses Canvas SVG or VML for rendering.
Stick to Flex for now !
Html 5 still Supports less active Browsers. Flex is Rich and As3 is a lot cleaner than js. Flex has a few very Advanced Frameworks.
bidirectional binding, dependency injection, all Kinds of fast mv* Frameworks.
So all in all Web development is far Away from Enterprise Development standards.
Guess its like in Adobe Days we complained that Designers try to develop Language Not understanding the Concept of Enterprise Software and architectures. Its the Same now we have Web and Ajax devs at Hand :) it feels like they have less/no experience with Enterprise Standards ( Some maybe Even Architecture) . So ! We will have to wait for js Frameworks to improve A Lot , ext js feels like as2 and flex 2 - Pseudo Object orientation and clumsy getter/setter. Gwt is pretty strong .. Knockout brings nice ideas. Angular js looks really promising. Jquery of course makes js bearable ... Yet it's just a small pill for a huge pita
A lot has to happen tho.
GWT (http://code.google.com/webtoolkit/) comes to mind. Or maybe OpenLaszlo (http://www.openlaszlo.org/).
OpenLaszlo is quite close to Flex in phylosophy, but can target either the Flash VM or just plain Javascript. So it seems to fulfil the "web standard based" requirement.
I havent used OpenLaszlo since 2005, and at that time it definitly was not ready for a serious application. But things might have changed since then ...
There is an upcoming project that brings Silverlight to all platforms. It is built using HTML5 and Javascript. This project is still in an alpha phase, but promises a lot. Check it out # http://fayde.wsick.com.
DISCLOSURE: I am affiliated with this project.
Have you considered using all the new technology under the HTML5 umbrella, such as SVG, Canvas, HTML5 tags, CSS3, Transforms, Geolocation, Web Workers, Offline Storage etc. You can make some pretty amazing RIAs with that, and it's all open standards. Of course you'll be limiting yourself browser wise, at least initially.
Check out this HTML5 presentation written in HTML5 http://apirocks.com/html5/html5.html#slide1 (warning needs upto date browser such as Opera, Chrome or Safari).
what basic tips should we observe in design web pages(html/css/javascript) for having highest compatibility with most browsers(IE-firefox-opera-chrome-safari)?
thanks
Validate often and squash all validation errors by the time you make a public release. The purpose of validation, after all, is to parse the html as a standards-compliant browser would and then avoid the errors that a browser's parser would find.
Apply progressive-enhancement techniques. Often that means moving some of the complexity of dynamic pages to the back-end (e.g. php, django, what have you) so that you can have complex functionality that doesn't break in one of the thousands of different client environments in which a page's javascript will run. jQuery is excellent for narrowing the focus of your javascript development towards feature enhancement instead of open-ended features-in-javascript, and it'll help with cross-browser compatibility as well.
IE - Test in at least one live version of IE 7 or 8. Unfortunately, there really isn't any way around this, because even IE8 misbehaves like no other browser. If possible, limit your goal of support for IE6 to html/css (i.e. don't promise support for user-enhancement-features via javascript in ie6). If possible, drop support for IE 5.5 and below.
For Javascript, use libraries that are intended on being platform-independent (ie: JQuery, Prototype). Not everything will be, but it'll make your life much easier.
For CSS, I'd say follow standards, but IE tends to cause problems across the board.
Which means, you need to test, and test often. Selenium is awesome for automated functional testing, and it works with pretty much every browser. We use a Selenium RC server on a Windows machine to test IE and Firefox, which are then controlled from our standard Java JUnit tests.
Keep things simple.
The simpler your markup, CSS, and JavaScript, the easier it will be to track down incompatibilities. Try to limit yourself to CSS1 for as much as possible. Only use more modern CSS2/3 features when there is no easier way to accomplish your task.
Don't use tables, they just add extra complexity. Using semantic markup not only makes things maintainable, but also gets you the best cross browser support if done properly.
Keep in mind that floats are evil, but are also very powerful. Use them generously, but avoid trying to clear floats. Use overflow instead.
Use a JavaScript framework. Framework developers have smoothed out most of the cross-browser bugs for you. I recommend jQuery, but you can choose any framework your developers feel comfortable with. My advice is to:
Use a JavaScript framework that doesn't alter the prototypes of native objects (like Prototype JS does)
Doesn't introduce many global variables. Most frameworks follow this rule.
Aside from those 2 rules for JavaScript, try using closures to encapsulate code so you don't introduce your own global variables.
One strategy I use is to start my CSS with a set of rules that blank everything out. Each browser may have different values for element attributes so ensuring that everything is consistent from the get-go can be handy. Here is an example reset.css
http://meyerweb.com/eric/tools/css/reset/
Take a look at this great article: Browser Compatibility Tutorial
Remember: something won't just work for a specific browser (mayble a left dotted border won't show in Chrome). Do not be upset about that if you can! :) Cross-compatibility is an art that takes a lot of time.
Given the iPhone's 25k limit for caching of files, I'm wondering if there's interest in an iPhone optimized javascript library that makes caching a top level goal. Since it'd be iPhone only it could get rid of most cross-browser cruft and rely on safari specific capabilities, hopefully cutting down some of the girth and staying with 25k.
John Resig discusses this briefly, although mostly to dismiss it, it seems. He does mention:
if you're particularly excited about
breaking jQuery down into little
chunks you can grab the individual
pieces from SVN and build a custom
copy.
Anyone tried that?
Dojo implements a 6k version that seems to rely on deferred loading. I'm mostly a jQuery user so I haven't given it a try, but it looks interesting.
Overall: what do you think about a safari/iphone specific javascript library that implements, say, the top 90% most used APIs in jQuery (or your other favorite library)?
Newer update: looks like Zepto is the way to go these days.
Found XUI, looks like what I was looking for, although I haven't given it a try yet.
You should check out QuickConnectiPhone. It may do what you want. It can be found at https://sourceforge.net/projects/quickconnect/. It also lets you write your app in JavaScript, CSS, and HTML and yet install it on a device.
There is an API that will allow you to make calls down to the Objective-C layer as well for phone vibration, GPS locations, accelerometer information, and some more. You can even extend this to other native phone behaviors as well.
The development blog for the framework is found at http://tetontech.wordpress.com
I'm experimenting with XUI as well, looks promising, seems to follow JQuery-way of doing things.
The same people also created 'lawnchair' for persistant storage of data in json format, XUI+lawnchair looks like a great combination for cross-platform (as in at least iphone+android, maybe webos, symbian, blackberry and ms as well) mobile development.
I think it would be fantastic, but it would be hard to match the testing and reliability of jquery unless someone really picks it up and runs with it. If there was a lightweight, safari only version of jquery that was completely compatible with the plugins and documented methods, it would be a godsend.
Given the increasing popularity of the iphone, I think it would be a really useful thing, it might be possible to remove the cross browser stuff and get it down to size.... however, it would be even more useful if the iphone had a more realistic cache limit.
It does make me wonder if the cache limit in the iphone was determined by the capacity of the hardware or the business needs of the carriers. A 50K cache limit would reduce a lot more carrier usage...