Vote for our TV Everywhere Session at SXSW 2014

We’ve been saying that 2013 will be the year TV Everywhere really takes off and Adobe is right in the center of this industry transformation with customer and technology partners worldwide. Delivering true broadcast television (live, linear and on demand) across screens at scale, personalizing those viewing experiences, and driving greater revenue for TV programmers and operators are some of the key challenges the industry is facing.

Help us bring the TV Everywhere discussion to South-By-Southwest (SXSW) 2014 in Austin, Texas next March! Jeremy Helfand, our VP of Video Solutions, will be leading an interactive session to discuss the future of TV and the impact of TV Everywhere on the industry. Here’s how to vote:

  1. Go to http://panelpicker.sxsw.com/vote/19367 to vote for our session
  2. Click the “thumbs up” icon on the left under the “Cast Your Vote” header
  3. If this is your first time voting for SXSW sessions, you’ll need to create a quick user profile that allows you to vote. Each registered voter can vote once per proposal.
  4. Login to cast your vote

Below are the details of our session. Cast your vote, spread the word, and we hope to see you at SXSW 2014! Follow @AdobePrimetime on Twitter for news and updates.

SXSW PanelPicker_Vote_14-blog

Haters Beware: TV is Everywhere

Here’s a bold prediction: By 2018, Internet TV consumption by consumers will match that of TV broadcasts and pay TV networks. Welcome to the world of TV Everywhere. Given the deluge of mobile devices and increasing adoption, consumers expect any screen anywhere to act as a TV screen. TV is no longer the device; it’s the content. Fortunately, as TV Everywhere evolves, new technologies and features are set to deliver: 

  • Broad availability across any screen
  • Synchronized viewing experiences for TV/devices
  • Greater audience engagement/personalization
  • Higher revenue for TV programmers/operators
  • Seamless and customized ad insertion into live, linear and VOD video content

Data from TV Everywhere services will drive more personalized programming and targeted ads that capture the viewers’ attention. It’s a win for advertisers, but also consumers, who tune out ads that disrupt their viewing experience or lack appeal.

Are Mobile Web Apps Slow?

A recent blog post from Drew Crawford has generated many comments and tweets about the relative performance of web and native apps. Drew’s well-written post is notable for its thorough documentation.

So should we all pack our mobile web app work and go native? Well, no.

Though the article singles out JavaScript, it really dives into the trade-offs between garbage-collected languages – JavaScript, Java – with lower-level alternatives that require the developer to manage memory. For those applications that are extremely sensitive to the kind of unpredictable interruptions caused by garbage collection, Drew argues that they will always lag behind native implementations (or, rather, behind native implementations that manage their memory properly).

First, the performance of JavaScript needs to be put in perspective:  it is only a subset of the performance profile of most web apps. HTML, CSS, SVG and the network also consume CPU/GPU cycles. For some web apps, the layout and rendering of HTML/CSS/SVG consume the majority of CPU cycles (it is even possible to write a game without any JavaScript code albeit a limited one.) Not only does it mean garbage collection only affects a fraction of an application’s overall execution budget, but a large part of the platform can be optimized and improved for all apps. So JavaScript is only one portion of mobile web apps’s code and its strengths and shortcomings alike only affect that portion.

Web Platform

Figure 1: A web application’s CPU budget

One may argue that this does not matter: why would anyone ever want to use a language that is slower than native? Wouldn’t you always want the faster option?

As Drew’s article points out, productivity is also important to developers. Drew uses the example of hashmaps: while managed languages usually build those in, native apps either rely on harder-to-use versions or roll out their own. Thus a big motivation for using a language such as JavaScript is its ease of use and dynamic nature. While not perfect it remains a language that is more accessible to more people than native code. It also is the same language across many platforms and devices, while native code is inherently platform-specific. Trading off some performance (for a fraction of the application, as explained above) for broader reach is appealing for many applications.

In addition, a core motivation for using JavaScript is that it is part of the wider web platform and lets us leverage a very powerful native component: the browser engine. I think of JavaScript as the puppet master of the browser engine: a little bit of code can exercise a variety of powerful native features from CSS layout and restyling to hardware- accelerated animations.

Granted, there exist native libraries that provide similar graphical, animated or layout features to what browser engines offer (and more). However, no solution that I know of has the the flexibility and ubiquitous reach that the web platform brings to the table.

Finally, a web app is not just client code. At the very heart of the web is the concept of distribution, of content as well as code. A web app can leverage the web and distribute its computing needs. The collaborative 3D authoring application Lagoa is a shining example of that possibility, as it distributes computation-intensive work to the cloud, operations that even the most powerful client code could not handle as well. Web apps, by nature, have access to the flexibility of this powerful architecture.

Web apps are way past the hype phase and climbing up the slope of enlightenment. Articles grounded in hard data like Drew’s are certainly useful. But we need to be mindful about decisions we make and consider a web application’s overall context before making the jump to native, and forego the many benefits of the web architecture.

In some cases (e.g., highly computationally intensive game), native code may indeed be the appropriate answer. But in most cases, web apps demonstrate the way of the future, even though the ‘puppet master’ code will run slower than its native counterpart. Remember that this relative slowness is a trade-off for other important benefits, such as higher productivity and unparalleled reach.