With the release of our first beta of Wordament on Windows 8, we made a big move. On Windows Phone, your two options for app development are XAML (Silverlight) / C# and XNA (DirectX-like APIs) / C#. So, either way, you are writing in C#—which is a terrific language. On Windows, you have nearly unlimited coding options, but the three primaries during Consumer Preview are: HTML / JS, XAML / C#, and DirectX / C++. We chose HTML / JS. Why? Why on earth would we choose to port a substantial and relatively stable code base? A variety of reasons, some of which we can talk about today:
- Long-term developer efficiency. This one is going to sound a bit backwards. Porting is never faster than a recompile, is it? Well, there was going to be porting either way. The XAML page model is slightly different on Phone than Windows 8, and going from 3.5” to 11.6” is more than a port. It’s a reimagination of the layout. A good app is highly optimized for its environment. The XAML we have on Phone would conceptually port as well to XAML on Windows 8 as would rewriting it in HTML. One of the truly great things about Windows 8 is “tablet-style multitasking” which includes Full, Filled, and Snap layouts and that’s where we spent the bulk of our CSS time—making sure that the app looked right in all the various layouts. We still have bugs, obviously, but for a time-sensitive first stab for Beta, we are pretty proud of how much we got done so quickly. Long-term, it seems logical (at least to me) that across the industry there will be more investment in HTML than in XAML. I’m sure the XAML folks don’t like me saying that, but if you think about it as purely a numbers game, there are more devs in the world working on HTML in every way than there ever will be on XAML. So, if you can’t beat ’em… might as well join ’em.
- Testing out the newest Windows 8 Dev Platform. While our managers in Microsoft Studios don’t care what languages we choose to use, we thought that for the greater benefit of Microsoft, it would be a good experience to try and port a decent-sized mobile app from one set of technologies to the other at which point we could share our findings with the Windows team (which we’ve since done). Having powerful tools like the DOM Explorer in Visual Studio is a game changer for UI devs. Click an element, figure out why it’s wrong… fix it… bug resolved. Wow. Also, building Metro-style Windows apps feels really fast and FUN.
- Closure: The Definitive Guide, Michael Bolin
- The Method Invocation Pattern
- The Function Invocation Pattern
- The Constructor Invocation Pattern
- and the Apply Invocation Pattern
We started with the Method Invocation pattern, but have since abandoned that for the Constructor Invocation Pattern, because that’s what Google’s Closure prefers. We didn’t start with Closure, but have ended up using it as a tool in our build process because it:
- Minifies and obfuscates.
Sadly, I think the biggest problem facing green horn developers today is the sheer number of tech-stack options you have to learn to really get moving: Want to write server stuff? Cool, learn PHP, Python, Java, C#, or Ruby. Want to write client stuff? Cool, learn Objective-C, Java, C#, or C++. Have you noticed something? There’s almost no overlap!
At the end of the day, John and I want to build games. Fun ones that develop a great community like we’ve all discovered together with Wordament. We are developers by training, but UX and project managers by experience. We engineer because we have to—but what we really want to do is just build great games and communities. Any choice that simplifies our future will be one we are willing to take—even if there’s a short term cost to doing that. If we were to do it all over again, we obviously wouldn’t change anything. To get on Windows Phone means XAML and C#. To get on Windows 8 means picking. We are happy with our choices, and we hope this helps folks considering what to learn as they pick their Windows 8 coding option.
— Black Snapper