Category Archives: html5

My beautiful web development soup

Summary: Web development is chaotic, overwhelming, and beautiful. How many technologies does it take to build something useful on the web? You might be surprised. Advice for developers getting into web development.



3654636770_3b1a5d470bThis week I was working on my open source startup project, BitShuva Radio. I acquired a new client this week, but this client was unique because he’s a Java developer and wanted to know how to edit the open source code for his new radio station.

As I typed out my answer, it dawned on me that the sheer number of  technologies utilized in building a useful web application is staggering. That they actually work together is a testament of the beautiful soup that is web development today.

How many technologies does it take to build something useful on the web? Here’s my answer:

  • I use TypeScript, rather than plain JavaScript, for all client-side code. A superset of JavaScript with optional types, TypeScript is a well-structured, typed language with excellent tooling. I use it for practical reasons: as the app grew in complexity, the need for a more structured language became apparent. I ported the JS to TypeScript last month, and I’m quite pleased with the results.
  • KnockoutJS is used heavily absolutely relied on. BitShuva is a dynamic single page application, meaning we’re doing lots of dynamic updates to the UI in real time. Knockout lets us make dynamic UIs very easily without resorting to tons of DOM manipulation code. Instead of DOM manipulation, Knockout lets you change your objects, and your UI automatically updates. For example, songsOnScreen.push(new Song()) will automatically show the song in the UI, no jQuery DOM manipulation required. 
  • I use knockout.postbox for decoupled pub/sub communication between client-side code components. For example, when I hit the play button, the click handler doesn’t need to know about HTML5 audio or any infrastructure concerns. Instead, it calls ko.postbox.publish(“Play”). Whoever is in charge of playing audio simply calls ko.postbox.subscribe(“Play”, …). This way, the click handler and the HTML5 audio component don’t need to know about each other. Nice and clean. Bonus: it works with Knockout observables, so you can say currentSong.publishOn(“SongChanged”) to automatically publish messages on a particular topic.
  • UbaPlayer is used for playing HTML5 audio with a Flash fallback. 
  • For styling, we use LESS, the CSS superset. We use LESS because CSS is redundant; LESS lets us use variables and functions for code reuse, but still compiles down to plain CSS.
  • jQuery is still there, but not as much as you might think. Because KnockoutJS handles the DOM <—> code interaction, jQuery is only needed in rare cases where we need special DOM manipulation (e.g. to fade in/out an element). We also use jQuery to do AJAX calls.
  • The site generally uses Twitter Bootstrap UI toolkit for styling and consistency across the UI.
  • We’re using Google Web Fonts for typography. 
  • For images like thumb-up/down, play button, etc. these are actually font characters, from the special Font Awesome web font. Because it’s just a font, they scale infinitely without losing fidelity, and you can change their appearance (size, color, etc.) using plain old CSS stylings. Icon fonts are awesome.
  • We use Asp.NET MVC Razor view engine to actually render our UI. Because of heavy reliance on KnockoutJS, Razor isn’t needed much; it’s mostly just plain HTML that is dynamically swapped in through AJAX and KnockoutJS.
  • The server code is written in C# 5 using Asp.NET MVC 4 + MVC Web API
  • ASP.NET Web Optimization Framework is used for minifying and bundling the scripts and CSS.
  • The database is RavenDB, a modern, 2nd generation document database, easily the best NoSQL database in the .NET world. I use it because it’s blazing fast and simple to just start dumping objects into.
  • ReactiveExtensions (RX)  is used on the C# server end to treat events as observable streams, which can then write LINQ queries on top of. We also use its sister project, Interactive Extensions, for some useful extension methods to IEnumerable objects (such as .Do and .ForEach).
  • To load up the whole shebang and edit the project top-to-bottom, I use Visual Studio 2012 + TypeScript tools plugin (for editing/compiling TypeScript) + Web Essentials (LESS compilation, better tooling for HTML5 web standards, and more).

Holy cow!

Here’s the final tally of languages, frameworks, and tools used:

  • 5 languages – C#, TypeScript, LESS, .cshtml Razor syntax, plus bits of plain JavaScript here and there
  • 5 UI JavaScript frameworks – KnockoutJS, jQuery, UbaPlayer, Knockout.postbox, Twitter Bootstrap.
  • 6 server-side .NET frameworks – RavenDB, MVC 4, MVC Web API, Reactive Extensions, Interactive Extensions, Web Optimization Framework.
  • 3 tools – Visual Studio 2012, TypeScript tools plugin, Web Essentials plugin.

The sheer number of tools required to really build something useful on the web is staggering. You get the sense of why desktop developers — who often work in just a single language + UI framework (e.g. C# + WPF) — are hesitant to embrace the web. It requires massive retooling.

And to be truthful, this is only my beautiful web soup. I chose C# + KnockoutJS + TypeScript + LESS, but other web devs might prefer Ruby + BackboneJS + CoffeeScript + SASS. Or something entirely different.

The great thing is, there is so much evolution going on in web development space today, and this produces unique and specialized toolsets that help move the web forward. For example, languages like CoffeeScript and TypeScript are influencing the future direction of JavaScript.

It’s a fun time to be in web development.

My advice for developers? Learn a few web technologies that pique your interest and cook up your own beautiful web soup.

Tagged

Apple: Please fix HTML5 on iOS

I’ve built an HTML5 audio player, Chavah Messianic Jewish Radio, that “works” on iOS.

By “works“, I mean, it plays the best it can on Apple’s crippled iOS <audio> implementation. At the time of this writing, this includes iOS 5, tested on iPhone 3 and 4, and iPad1 through iPad 3.

How is <audio> broken on iOS? Let me count the ways:

  • Apple does not let you play audio until user interaction. For me, this means detecting iOS, then showing the music as paused until the user clicks play. Their reasoning is that this will consume data and battery; in practice, though, it cripples web apps, forcing us to resort to platform-specific hoop-jumping  to get the web to work on your platform, Apple. It effectively stifles the evolution of the web in the same way IE did in the late 1990s.
  • Apple does not allow you to play concurrent audio files. This is a huge crippler for gaming apps that need to play sound effects, for example.
  • Apple doesn’t support OGG format. Patent-encumbered formats work, of course, but without support for free and open formats like OGG, Apple is effectively creating a long-term thorn in the side of the opened web.
  • Every dynamic <audio> element must receive user interaction. If you want to play successive sounds (one after another) without receiving user interaction for each one, you must use a single <audio> element, then do the iOS <audio> dance: set existingAudio.src, then call existingAudio.load(), then call existingAudio.play().
  • Audio events don’t fire unless Safari is in the fore. While audio will continue playing if the user switches to a different app, the .ended event won’t fire. This means it’s practically impossible to build a music player web app.

Apple, please, please, please give us better support for HTML5 in iOS Safari. Here are your action items, Apple:

  1. Let HTML5 audio work in the background.
  2. Support OGG.
  3. Support pre-loading audio.
  4. Support concurrent audio.
  5. Let us play audio without user interaction.

Do those things, Apple, you’ll be the industry leader in mobile HTML5 audio, everyone will emulate you, you’ll once again be leading the way, and HTML5 web apps will work best on your platforms. Wouldn’t that be good for Apple?

Yes, these features will use data and the battery, but native apps already do this, so why cripple web apps? Stop stifling the evolution of the web, and start being the leader. Make HTML5 <audio> a first-class citizen on iOS.

Follow

Get every new post delivered to your Inbox.