Tag Archives: html5

development, mobile, professional, software development, web authoring

Native apps vs HTML 5: no consensus over how to choose

2 Comments

Wondering whether to invest in native apps or HTML5 web apps (maybe wrapped as native) for your next mobile development project? Welcome to plenty of confusion about which is the best path to take. Here are a few pieces of evidence from this month:

A Compuware survey of 3,500 consumers showed a preference for mobile apps over mobile websites:

When consumers were asked about the benefits of using a mobile app versus a mobile website (a website that is specifically designed to be viewed on a mobile device), the majority (85 percent) said they preferred mobile apps primarily because apps are more convenient, faster and easier to browse.

Just 1% expressed a preference for mobile websites over apps. Note that consumers cannot be expected to know whether or not a native app is actually written in HTML5 or not; but here is an intriguing report from Xero, which makes accounting software:

Very early on we chose to build Xero Touch using HTML5 technologies. That choice showed that we care about the future of the open web and its continued success as an application delivery platform and we firmly believe that HTML5 is the future of development across any and all platforms. We do not regret this choice – but we’ve found that building a complicated mobile application in HTML5 has been hard. Even with frameworks as amazing as Sencha Touch, we’ve found the ability to iterate as fast as we would like has become harder as our application has become more complex.

… the lesson we’ve learnt over the last 12 months has been that the cost in time, effort and testing to bring an HTML5 application to a native level of performance seems to be far greater than if the application was built with native technologies from the get-go … Maintaining and iterating a web app was becoming a big impediment – so the next release of Xero Touch will be built with native technologies and we’ve already made a lot of progress. It does feel better.

If a company is so unhappy with its development platform that it is willing to endure the pain and expense of switching, that is evidence of deep dissatisfaction.

On the other hand, here is the UK’s Government Digital Service:

Our position is that native apps are rarely justified. Since November 2012, central government departments and agencies have to get approval from Cabinet Office before starting work on apps. For government services, we believe the benefits of developing and maintaining apps will very rarely justify their costs, especially if the underlying service design is sub-optimal. Departments should focus on improving the quality of the core web service.

Is this because the Government Digital Service is spending public money and therefore apps are an unnecessary luxury? That is arguable, though it has not stopped the BBC (also publicly funded) from delivering a ton of apps, to predictable complaints from owners of less favoured platforms like Windows Phone.

This one will run and run. HTML5 will get better, but so also will native platforms, so I doubt this difficult choice will get easier any time soon.

It may be a matter of whether your particular app is a good fit for HTML5 or not. However, I am not aware of any consensus over what characteristics make an app a good or bad fit for an HTML5 solution, except that for broad reach HTML5 cannot be beaten, and for full access to device and OS features there is no substitute for native.

internet

WHATWG to accelerate work on HTML5 “Living Standard”, diverge further from W3C HTML5

Google’s Ian Hickson, who is the editor of HTML5 at the WHATWG group, has announced an “Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification” in a message that seems to express frustration at the slow pace of the W3C standards body.

There have long been two versions of HTML5, one managed by WHATWG, and the other by the W3C. When the W3C embraced HTML5 in 2007 it used the WHATWG work as its starting point. However, rather than folding its work into the W3C, the WHATWG continued to develop a separate specification of its own.

Hickson now says:

More recently, the goals of the W3C and the WHATWG on the HTML front have diverged a bit as well. The WHATWG effort is focused on developing the canonical description of HTML and related technologies, meaning fixing bugs as we find them [1], adding new features as they become necessary and viable, and generally tracking implementations. The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process. This led to the chairs of the W3C HTML working group and myself deciding to split the work into two, with a different person responsible for editing the W3C HTML5, canvas, and microdata specifications than is editing the WHATWG specification (me).

A practical consequence of the split is that there will no longer be a single bugtracking system for bugs that apply to both the WHATWG and W3C specifications. These will now be managed independently.

Hickson adds:

The changes described above are unrelated to the change announced in April regarding the WHATWG’s adoption of the W3C Community Group mechanism, but together they mean we are now independent of the W3C HTML Working Group again, while still maintaining a working relationship with the W3C. [4] My hope is that the net effect of all this will be that work on the HTML Living Standard will accelerate again, resuming the pace it had before we started working with the W3C working group.

The outcome appears to be greater divergence between the two standards, with new specifications drawn up by WHATWG that may not be adopted for a long time, or may never be adopted, by the W3C. There is increasing risk of incompatibility as well, though Hickson says there will still be a “working relationship”.

One of the browser vendors most affected is Microsoft, which supports the W3C but is not a member of WHATWG.

adobe, flash, professional

Adobe’s Flex roadmap: another go at positioning Flex and Flash versus HTML5

2 Comments

Adobe has published a Flex Roadmap which I guess is one of those “Let’s end the speculation” pieces which nevertheless still leaves you with questions.

Flex is the XML-based language for coding applications for the Flash player or runtime. Doubts about Adobe’s long-term strategy for Flex appeared last November when Adobe announced a shift in its business strategy towards digital media and marketing as opposed to enterprise solutions. In addition, Adobe stated that:

In the long-term, we believe HTML5 will be the best technology for enterprise application development. We also know that, currently, Flex has clear benefits for large-scale client projects typically associated with desktop application profiles

I imagine that this has made it difficult for Adobe’s partners to market Flex-based solutions, a problem that this new roadmap tries to address. It begins in forthright style, almost contradicting the earlier statement:

Adobe believes that Flex is the best solution for enterprise and data-centric application development today, and that moving Flex into a community-driven open source project ensures the continued development and success of Flex for years to come.

The paper goes on to iterate the benefits of Flex development, including what is perhaps the most important:

Flex offers complete feature-level consistency across multiple platforms, browsers, and devices

Before you say it, this can include Apple iOS thanks to the packager for iOS which wraps the Flash runtime with your app as a single native app. Mobile support for AIR (but not the Flash player) will continue on “current and future devices and OS updates including iOS 5, iPhone 5, iPad 3, and Android 4.” AIR is the runtime packager which lets you run Flash applications as if they were native apps. As for BlackBerry, Adobe says that RIM plans to continue supporting it, making it sound as if Adobe is not taking responsibility for it.

It gets worse though. What are the implications of Adobe handing over Flex to the Apache Foundation? Fewer Adobe engineers is one:

While under this new model Adobe will provide fewer engineering resources than in the past, we are working with the Flex developer community to increase the total number of active contributors and resources

That said, there will be a team of full-time Flex SDK engineers from Adobe working on the Apache Flex project. Adobe will also contribute BlazeDS (fast messaging and server-side remoting between Flex clients and Java application servers), as well as the forthcoming Falcon 1 compiler and the experimental Falcon JS which compiles ActionScript to JavaScript. Adobe will not contribute LiveCycle Data Services or LiveCycle Collaboration Services, nor will AIR for Linux be revived.

The further down the document you get, the more complications appear. Adobe promises continued support for the current Flex 4.6 SDK in future Flash players for five years, but support for Apache Flex SDKs is not Adobe’s responsibility:

While Adobe will ensure that the Adobe Flex SDK 4.6 and prior will be supported in future versions of Flash Player and AIR, it will be the responsibility of the Apache Flex Project to test future versions of the Apache Flex SDK against released Adobe runtimes to ensure compatibility and proper functioning.

Another little downer is that since Adobe cannot sign Apache-created Flex shared libraries, they will not be cached globally by the Flash player, but only per domain.

Adobe also notes that:

Flash Platform technology will continue to evolve with a focus on gaming and premium video.

which maybe is not what a Flex developer wants to read.

Then there is the tooling, and the paper confirms that Flash Catalyst is discontinued, and that Design View and Data Centric Development tools will be removed from Flash Builder, even including updated 4.x versions. Adobe says this is “In order to better support future Apache-derived Flex SDKs.”

One last point of interest: regarding Flash Player and AIR for Windows 8, Adobe says:

For information on support in future operating systems, please refer to the Flash Player Roadmap White Paper, which will be published shortly.

I guess what we are waiting to hear is whether and when Adobe might support the new Windows Runtime with AIR and the Flash Captive Runtime, since the Flash plug-in will not work on the Metro browser in Windows 8.

So what is Adobe really saying, and what is the future for Flex development? It is all very well saying now, three months after signalling a shift to HTML5, that Flex is still a great platform, but the tangible facts are these. First, Adobe is investing less than before in Flex. Second, Flex will be with Apache and it is up to that nebulous thing the community to determine what happens to it.

The problem is that the future of Flex is wedded to the future of Flash, and the general belief is that Flash is gradually giving way to HTML5, and AIR giving way either to native code or to HTML and JavaScript packaged as an app via PhoneGap or similar.

Kudos to Adobe for spelling out more clearly what is happening to Flex and AIR; but my sense is that the platform will still decline.

adobe, design, development, professional, software development, Web

Adobe: why the big business shift when financial results look so good?

Adobe released its quarterly and full year results last week; I am catching up with this now after a week in China.

The company is doing well. Revenue is up by 11% year on year and it generated $1.5 billion in cash. It is buying back shares, usually a sign that a company has more money than it knows what to do with.

Here is the comparison with the equivalent quarter last year:

  Q4 2010 Q4 2011
Creative and interactive 404.8 437.2
Digital Media 165.9 186.4
Digital Enterprise 273.3 342.4
Omniture 109.0 131.1
Print and publishing 55 55.1

In other words, all business segments grew – impressive in uncertain economic times. See this earlier post for a rough breakdown of the segments.

A couple of observations. First, Adobe is benefiting from the big trend in IT towards web, cloud and device. Many companies regard apps (as in mobile apps) as vehicles for marketing, and Adobe’s tools are a natural fit, with or without Flash. We are in a more design-centric IT world than was the case a few years back, driven by Apple, SEO (Search Engine Optimisation), and just because we can: technology now performs basic computing functions with ease so design becomes the key differentiator.

Adobe is nevertheless remarkable in the way it has managed the transition from print to digital. Few companies manage that kind of fundamental shift in their market successfully.

The other point that interests me is why Adobe announced a major change in its business model in November. Digital media and marketing will be the focus, while it winds down its enterprise development platform, as well as moving away from Flash and focusing on HTML5 for delivery.

Unless the announced figures disguise future problems that are only visible on the inside, this move was driven by bad results. Digital Enterprise, which includes the middleware business, increased revenue by 25% over the same quarter last year.

In 2012 the Digital Enterprise segment is being renamed Digital Marketing Solutions, expressing the company’s intent.

Adobe’s change of direction caught me by surprise, as it was not really flagged at the MAX conference the previous month, though there was evidence of struggle with regard to Flash versus HTML5.

I would describe Adobe’s moves as bold. Taking action ahead of when it becomes inevitable is a good thing, but there are significant risks. Adobe’s platform is all about synergies, and chopping off bits that still have a significant following may have unexpected consequences.

Another curious facet of Adobe’s move is that its normally excellent PR department has done little, as far as I am aware, to brief the press. Major news concerning what will be donated to Apache, or the discontinuation of Flash Catalyst, has emerged from sporadic reports instead. Normally that is a sign of a company under stress, rather than one which is about to deliver excellent results.

I guess this time next year we will have a clearer picture.

mobile, open source, software development, Web, web authoring

Sencha’s Michael Mullany talks about Flash developers “flailing around for an alternative” and the Big App Rewrite

I spoke to Michael Mullany, CEO of Sencha, a company which creates HTML5 frameworks and tools for desktop and mobile browsers. Ext JS is aimed at desktop browser applications, while Sencha Touch is for mobile devices, currently Apple iOS, Google Android and Blackberry 6+. Sencha’s tools include Ext Designer, a visual application builder for Ext JS, and Sencha Animator, a designer for CSS 3 animations. Sencha Touch apps can also be packaged as native apps for iOS or Android.

At its developer conference in Austin USA earlier this month, attended by around 600, the company announced Sencha.io, a cloud service for mobile web apps, as well as presenting Sencha Touch 2.0, a major update.

image

Mullany talks on his blog about “The Big App Rewrite”:

It’s a world where HTML5 powers the client apps, and they’re enriched with local APIs that execute on everything from traditional desktops to Smart TV’s. And cloud services provide the fabric that enables continuous, shared experiences across the diversity of end-devices. We think this is the platform for the web.

Sencha is perfectly in tune with the trends towards cloud, HTML5 and mobile, which is why I was keen to speak to Mullany. I asked him to contrast Ext JS and Sencha Touch with JQuery and JQuery Mobile.

JQuery is a pretty tiny library that helps with Dom abstraction and animations but that’s it. JQuery UI gives you some visual components as well but Ext-JS is the full enchilada. It’s supposed to be the web equivalent of Cocoa or the Microsoft Windows presentation foundation. It’s got an event system, a theming system, a very rich set of user interface controls, its object oriented, and it’s got a complex layout system so you can build nested layouts that have very complex event handling among different parts of the user interface. We’ve seen user interfaces that have several thousand data elements on a page.

It also has a model-view-controller architecture library on the client side so you can structure your code properly for large applications, it’s got a theming system so you can variable-ise your colours, shapes and look and feel very easily. It also has a full data package so you can do very rich data manipulation on the client, bind data in various complex ways across variables, it’s very different than J query.

And just like you’d probably never use Ext-JS on a public web page, you’d never use JQuery to build something like Marketo or Salesforce VisualForce or a Documentum content management system, all of which use Ext-JS. Ext-JS is one of the most popular behind the firewall development libraries for desktop development.

Now on the mobile side the difference is slightly less. JQuery mobile does give you a set of user interface widgets, but the difference is also similar to the desktop … Sencha Touch is designed to let you do anything you could do with Cocoa Touch or an Android SDK or a Windows Mobile SDK. Its intent is to equip you to develop native quality experiences with native style interaction, things like fixed user interface chrome, multiple independent scrollable areas, nested layouts, those kinds of capabilities.

Our performance tends to be better cross-platform, we’ve done more performance work, we have our theming system, we have an MVC library, we have a templating system. With JQuery mobile you tend to want to add multiple things together and you can certainly assemble a collection of things that will look like Sencha Touch, but Sencha Touch is designed to be integrated, everything is designed to work the same, and the general feedback is that even though Sencha Touch is a much richer system that takes some insight to learn, you get better applications out of it.

I also asked about the new cloud service, Sencha.io. A notable feature is that according to Mullany developers do not have to touch the code that runs on the cloud, they just call its API from the client:

We call it the first client-centric HTML5 cloud, which is a set of authentication, data, data synchronisation, and geo-location services that help people build mobile applications without needing to write server side code. So you literally write your client side application in HTML 5 using Sencha SDKs and then you store your user’s data and you store your user’s authentication credentials in our cloud. You don’t have to worry about mucking around with anything from Ruby on Rails to PHP to Java, it’s all abstracted behind these very clean APIs. We think that’s the future of mobile development, that you’ll have these very thin abstracted server-side services, and and these very rich mobile clients that have off-line state and local data storage powered by HTML5. We think that model is the future of mobile web development and we obviously hope that Sencha.io will be the most popular back-end.

Sencha’s frameworks are open source and dual-licenced. You can use both Touch and Ext JS freely under the terms of the GPL v3. There is also free commercial licencing for Sencha Touch, while commercial licences for Ext JS are paid for. Sencha also has commercial tools, and I asked Mullany to describe the tool products:

We really see the three legs of the business being cloud, tools, and SDKs. We just did a preview of the Sencha Designer 2.0 release at our conference. That has support for Sencha Touch in it so you can drag and drop Sencha touch applications together and then actually package them from within the tool. The intent is also to allow you to hook up to cloud APIs from within the tool as well so it is an integrated, easy-to-use visual application builder for both desktop and touch. So that’s targeted at developers.

Sencha Animator is a little bit different. There’s no JavaScript in it really at all. It is a pure CSS 3 animation tool, and it is a traditional visual timeline with keyframe manipulation, and a style visual editor for creating rich animations.

The market we’re targeting for that is people doing interactive brand advertising on mobile. That’s where you have ubiquitous support for CSS 3 animations that are hardware accelerated so they tend to be the best performance. It’s also very web content friendly so you don’t have to write your application in Sencha Touch just to use Animator, it’s pure CSS output that you drop into whatever piece of content that you want to build.

The reason we built it is because we saw people flailing around for an alternative to doing Flash ads on mobile. Because Flash was banned from iOS, it meant that a whole segment of rich advertising that was based on Flash for the desktop had nowhere to go. They weren’t going to build native iOS applications, it had to be web. So the question then was what do you build it in, do you use JavaScript animation, do you use SVG, do you use Canvas, do you use some of the other graphic technologies such as Web GL? The answer is that CSS 3 is really the highest performance and cognitively pretty easy to wrap your head around.

People “flailing around for an alternative to doing Flash ads?” Mullany has his own agenda, but his comments do highlight the problems caused for Adobe by the success of Flash-free iPhone and iPad. I cannot help thinking that Sencha would be an attractive acquisition for Adobe or certain other companies, but I am sure smarter people than myself have thought of that.

Post sponsored by Monster for the best in IT jobs.

apple, development, internet, microsoft, professional, Web, web authoring, windows

HTML5 scorecard: Amazon Kindle Fire weak, iOS 5 great, IE10 preview one of the best

4 Comments

The Sencha blog has a great series of posts on HTML5 support on various devices. This is of direct interest to Sencha because its products are JavaScript and CSS application frameworks, Sencha Touch for mobile and ExtJS for any browser. The latest post is on the Amazon Kindle Fire – and it is weak:

The Amazon Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal. It does a good job of displaying ordinary web pages and its resolution and rendering capabilities meet that need well. But there are too many sharp edges, performance issues, and missing HTML5 features for us to recommend that any developer create web apps primarily for the Kindle Fire. The iPad 2 running iOS 5 continues to be the tablet to beat, with the PlayBook a respectable runner-up in HTML5 capabilities.

Part of the problem is that the Fire runs Android 2.3.4 (Gingerbread) which has a weaker browser than later versions. That is not the only source of disappointment though. According to Sencha’s Michael Mullany, the GPU is not used for hardware acceleration of browser content, the JavaScript timer is laggy, there is no embedded HTML5 video (videos launch in a separate player), and CSS corners are not properly anti-aliased.

But what about the Kindle’s cloud-accelerated browsing that we heard so much about when it was announced? This is the biggest disappointment:

One of the main selling points of the Kindle browser is supposed to be its cloud-caching and pipelined HTTP connection that uses the SPDY protocol. This does seem to speed up normal page browsing a little, but it’s not very noticeable and we didn’t test this rigorously. But for HTML5 web apps, where code is downloaded and executed, there doesn’t seem to be any performance difference when we tested with acceleration on and off. It doesn’t appear as if client JavaScript is executed on the server-side at all, so the Kindle does not seem to have Opera Mini-style server-side execution. And SunSpider scores were essentially the same when accelerated browsing was turned on or off.

Moving on from Kindle, it is interesting but not surprising to see a great report for HTML5 in Apple’s iOS 5. Less expected though is a big thumbs-up for HTML5 in Microsoft’s IE10 preview on Windows 8:

Simply put, (and with the caveat that we were running on the notably overpowered developer preview hardware) the IE10 HTML5 experience is one of the best we’ve seen on any platform to date. After a decade of web neglect, Microsoft is back with a vengeance.

image

The main caveat is the absence of WebGL. Microsoft is supporting its own 3D graphics library.

Another worry for Microsoft is simply the level of hostility towards the company and IE in particular, among the developer and designer community it so much wants to reach. You can get a flavour of this from some of the comments to Mullany’s post, for example:

I never really like Windows and I absolutely despise Internet Explorer. There are so many exceptions in code to be made for Internet Explorer that i stopped trying so hard to make it look the same as other browsers. Hopefully, IE 10 will stop all of these exceptions and weird additions that are made to websites that make everything instantly awful so I can actually go back to trying to make things look nice in IE. It’s really sad though that so many people use Windows and IE that we cannot ditch it for a better system and better browser.

What about Android? The most recent offering covered in the Sencha series is Motorola Xoom which is a disaster:

We were excited about the first true Android operating system for tablets and had high hopes for a mobile browser that was as powerful as the platform. Sadly, the Xoom and Honeycomb are a real disappointment. We found consistent and reproducible issues in CSS3 Animations and CSS3 Transitions among other things. We had issues where the browser either hung or crashed. Regular scrolling was slow or below full framerate. We had issues where media playback failed or performed incorrectly. At times it felt like we were using a preproduction device, but we bought our test device from a Verizon Wireless store.

I have a hunch that the latest Galaxy Tab might fare better. Sencha did like the HTML5 support in the BlackBerry PlayBook though.

With Adobe Flash now in decline on mobile devices (Adobe is no longer working on the mobile Flash player) HTML5 support is all-important for rich browser-hosted apps; I will be watching with interest for future Sencha reports.

adobe, apple, business intelligence, flash, internet, java, microsoft, professional, Web, web authoring

Wolfram announces Computable Document Format for interactive docs

Wolfram has announced the Computable Document Format (CDF), a document format that enables live computation to be embedded within it. “It’s a new way to communicate the world’s quantitative ideas much more richly than we have in the past, and in doing that a new kind of active document,” says  Conrad Wolfram, Strategic Director of Wolfram Research. That said, the technology here is not really new. There is a close relationship between CDF and Mathematica, Wollfram’s tool for creating mathematical calculations and simulations. The authoring tool for CDF is Mathematica:

image 

The announcement then is really about a new player for Mathematica content and applications, to broaden their usage. The CDF player is free, though there are some limitations. If you charge for your document, or want to display it without the player chrome, then a paid licence is needed. A CDF document can also be compiled into a standalone executable, blurring the distinction between document and application.

The CDF player is available for Mac, Windows and Linux. There is also a browser plug-in for embedding CDF documents into web pages.

It is easy to find use cases for CDF. It is for documents where there is value in performing calculations or interacting with data within the page. An example is pension planning:

image

We have all seen those documents with a series of projections based on different assumptions about retirement age, contributions, investment growth and so on. This works better as an interactive chart where you can enter whatever values you like.

Other examples are statistical analysis and business intelligence, textbooks and course books where students can interact with equations and simulations, business proposals where you want to show how financial projections change based on different assumptions, or even general news reports where instead of a static chart you might want to show interactive graphics that let readers drill down into the data that interests them, or see real-time results.

Along with the computation engine, CDF supports a decent range of traditional content formatting features including cascading stylesheets.

Wolfram is correct in assuming that this kind of interactive document is important, and something we will increasingly take for granted in the era of the Web, eBooks and tablets. But can it succeed in establishing its own new document format when we already have HTML, Adobe PDF and Flash, Microsoft Excel and PowerPoint, and other formats which are also capable of embedded interactive content?

That is a key question. Wolfram offers a table which claims to show the benefits of CDF versus competitors such as HTML and PDF, but it is as skewed as these tables usually are. Wolfram says a PDF document cannot be compiled as a standalone executable, for example, but a PDF in an Adobe AIR application comes close. It is also worth noting that you can embed Flash in PDF, which would be an obvious route to something like the pension planning document mentioned above.

Nevertheless, CDF does have advantages. In particular, it has Mathematica, and whereas authoring a Flash applet requires programming and design skills, Mathematica is more approachable presuming you have the necessary mathematical, scientific or financial skills; and if you do not, you should not be authoring the document. Mathematica will construct a user interface automatically. It also has a huge range of built-in algorithms, functions and charts. Wolfram claims that authoring a CDF should be within reach of anyone who can work with an Excel macro.

The challenge Wolfram faces is how to make CDF usable across a broad range of devices and clients. Having to install a player or plug-in is a considerable deterrent. PDF or better still HTML5 has broader reach and works on Google Android and Apple iOS as well as on desktop PCs.

I tried the CDF plugin and player on Windows 7 and encountered several issues. The plug-in does not play nicely with Internet Explorer’s Protected mode and I saw this dialog frequently:

image

I also had some issues with the player. I could not get an example document on Gulf Oil Spill Estimation to work:

image

The player is currently for Windows, Mac and Linux – what about Apple iOS? Wolfram says it is working on this, with a two-pronged approach. One idea is presumably based on some sort of app, I’d guess either a player if Apple allows it, or some way to compile a CDF into an app. The other idea is to render the interactive parts server-side, so you could use them in a web page without a plug-in. This second idea could also remove the need for a plug-in on the desktop. You will get a performance hit because of all those trips back and forth to the server, but this could be mitigated by high performance computing on the server that will perform calculations more quickly than your client.

I can see CDF being popular within its niche, but whether it can transition into being a mass-market format I am not sure. Established plug-ins and runtimes such as Adobe Flash, Microsoft Silverlight, and Java on the client are all under pressure, particularly as Apple’s iOS spreads its reach; it is not a good moment to launch a new format that has a plug-in or runtime dependency. I wonder if Wolfram is exploring the possibility of compilation to HTML5 and JavaScript?

Despite these reservations, the broader vision behind CDF seems to me spot-on. There are many cases where we currently see static charts, that would be better served by an embedded computation engine.

adobe, mobile, professional, software development, visual studio, Web, web authoring

Native apps better than web apps? That’s silly talk says PhoneGap president

1 Comment

When I attended Mobile World Congress in February one of my goals was to explore the merits of the various different approaches to writing cross-platform mobile apps. One of the key ones is PhoneGap, and I got in touch with Nitobi’s president and co-founder André Charland. As it turned out he was not at that particular event, but he kept in touch and I spoke to him last week.

PhoneGap works by using the installed HTML and JavaScript engine on the device as a runtime for apps. That is not as limiting as it may sound, since today’s devices have high performance JavaScript engines, and PhoneGap apps can be extended with native plug-ins if necessary. But aren’t there inconsistencies between all these different browser engines?

Sure, it’s kinda like doing web development today. Just a lot better because it’s just different flavours of WebKit, not WebKit, Gecko, whatever is in IE, and all sorts of other differentiation. So that’s definitely how it is, but that is being overcome rather quickly I’d say with modern mobile JavaScript libraries. There’s JQuery Mobile, there’s Sencha Touch, there’s DoJo Mobile just released, SproutCore, which is backed by Strobe, which is kinda the core of Apple’s MobileMe.

There’s tons of these things, Zepto.js which is from the scriptaculous guy, Jo which is a framework out of a Palm engineer, the list of JavaScript frameworks coming out is getting longer and longer and they’re getting refined and used quite a bit, and those really deal with these platform nuances.

At the same time, phone manufacturers, or iOS, Android, WebOS, and now RIM, they’re competing to have the best WebKit. That means you’re getting more HTML5 features implemented quicker, you’re getting better JavaScript performance, and PhoneGap developers get to take advantage of that.

says Charland. He goes further when I put to him the argument made by native code advocates – Apple CEO Steve Jobs among them – that PhoneGap apps can never achieve the level of integration, the level of performance that they get with native code. Will the gap narrow?

I think it will go away, and people will look back on what they’re saying today and think, that was a silly thing to say.

Today there are definitely performance benefits you can get with native code, and our answer to that is simply that PhoneGap is a bundle made of core libraries, so at any point in your application that you don’t want to use HTML and JavaScript you can write a native plugin, it’s a very flexible, extensible architecture … So you can do it. We don’t necessarily say that’s the best way to go. Really if you’re into good software development practices the web stack will get you 90%, 95% of the way there, so that apps are indistinguishable from native apps.

Some of the native features we see in iOS apps, they’re reminiscent of Flash home pages of ten years ago, sure you can’t do it in HTML and JavaScript but it doesn’t add any value to the end user, and it detracts from the actual purpose of the application.

The other thing is, a lot of these HTML and JavaScript things, are one step away from being as good in a web stack as they are in native. When hardware acceleration gets into WebKit and the browser, then performance is really just as good.

Charland is also enthusiastic about Adobe’s recent announcement, that PhoneGap is integrated into Dreamweaver 5.5:

Two things are exciting from our perspective. It gives us massive reach. Dreamweaver is a widely used product that ties in very nicely to the other parts of the creative suite toolchain, so you can get from a high-level graphic concept to code a lot quicker. Having PhoneGap and JQuery Mobile in there together is nice, JQuery Mobile is definitely one of the more popular frameworks that we see our community latching on to.

The other thing is that Dreamweaver targets a broader level of developer, it’s maybe not super hard core, either Vi or super-enterprise, Eclipse guys, you know, it’s people who are more focused on the UI side of things. Now it gives them access to quickly use PhoneGap and package their applications, test them, prove their concepts, send them out to the marketplace.

He says Adobe should embrace HTML and Flash equally.

I also asked about Windows Phone support, and given that Microsoft shows no sign of implementing WebKit, I was surprised to get a strongly positive response:

We have something like 80% of the APIs in PhoneGap running on Windows Phone already. That’s open and in the public repo. We are just waiting basically for the IE9 functionality to hit the phone. The sooner they get that out in public, the sooner we can support Windows Phone 7. We have customers knocking at our door begging for it, we’ve actually signed contracts to implement it, with some very large customers. Just can’t there soon enough, really. I think it’s an oversight on their part to not get IE9 onto the phone quicker.

PhoneGap is at version 0.94 at the moment; Charland says 0.95 will be out “in a few weeks” and he is hoping to get 1.0 completed by O’Reilly OSCON in July.

I’ve posted nearly the complete transcript of my interview, so if you are interested in Charland’s comments on building a business on open source, and how PhoneGap compares to Appcelerator’s Titanium, and what to do about different implementations of local SQL on devices, be sure to read the longer piece.

.net, microsoft, professional, silverlight, software development, visual studio, windows

Where is Microsoft going with its Rich Client API? Microsoft drops some clues as developers fret

7 Comments

A discussion taking place in a Windows Presentation Foundation (WPF) newsgroup, in a thread called WPF vNext, shows how Microsoft’s confused rich client development strategy is affecting developers, and offers some clues about what is coming.

Developer Rudi Grobler, who posted on his blog some wishes for Windows Phone, Silverlight and WPF, describes his difficulty in discerning Microsoft’s direction:

The strategy for the future is very vague… I daily get questions about should I use WPF or Silverlight? Is WPF dead? Is Silverlight dead? etc…

Jeremiah Morrill describes his frustration with WPF performance:

Microsoft has known of WPF’s performance problems since the first time they wrote a line of code for it.  You will be hard pressed to find a customer that hasn’t complained about perf issues.  And you will not have gone to a PDC in the last few years and not hear folks bring this up to the WPF team. This is 3rd party info by now, but I’ve been told the issues I have noted have been brought up internally, only to be disregarded.

and remarks his frustration with what has happened to Silverlight:

Silverlight’s strategy USED to be about cross-platform, get-the-runtime-on-every-device-out-there, but it’s obvious that is not the strategy any more.  What happened to Silverlight on set-top-boxes?  Android? I read an article that some people saw it on XBox, but nobody has talked about it since.  Cross-platform with OSX has become symbolic at best.

Developer Peter O’Hanlon describes how the uncertainty has affected his business:

I run a small consultancy, and I bet the company on WPF because I could sell the benefits of faster development time for desktop applications. We have spent a lot of time learning the ins and outs of the platform and saw that Silverlight gave us a good fit for developing web apps. In one speech Microsoft caused me months of work repairing the damage when Muglia seemed to suggest that these technologies are dead and Microsoft are betting the farm on Html 5. We hand our code over to the client once we have finished, and they ask us why they need to invest in a dead technology. I don’t care what you say on this thread, Microsoft gave the impression that html 5 was the way to go.

[…] Muglia’s statement about the future being html caused serious issues for my company. We lost two bids because the managers didn’t want to commit to "dead" technology.

Microsoft’s Jaime Rodrigues, WPF Technical Evangelist, offers the following response:

You are telling us to improve perf in WPF. We hear this loudly and we are trying to figure how to solve it. Unfortunately, there are a few pieces to consider:

1)      First of all,  a lot of our customers are telling us to invest more into Silverlight.  Let’s say (again made up) that demand is  4-to 1. How do we justify a revamp of the graphics architecture in WPF.  This is not trivial work; the expertise in this space is limited, we can’t clone our folks to 5x to meet everyone’s needs.

2)      Let’s assume we did take on the work.  My guess (again, I am not engineering) is that it would take two years to implement and thorougly test a release.  At the stage that WPF is at, a rearchitecture or huge changes on the graphics stack would be 80% about testing and 20% about the dev work.    It is not a trivial amount of work.   Would we get the performance you want across myriad of devices? We don’t know. WPF bet on hardware, and there is new devices out  there that are trading hardware for battery, weight, or simply for cost.  it would suck to do that much work, make you wait a long time, and then not get there. Let’s get real on the asks; you say "improve perf" but you are asking us to do a "significant re-write"; these two asks are different.

3)      By the time we get there, what will be a more powerful framework?  Silverlight, WPF, C++, or SuperNew.Next ??  we don’t know today.  We go back to #1 and look at demand We are in agreement that "customers" is the driving principle.

The WPF has looked at the trade-offs, and risk many times.  We are also looking at what customers need. Jer, to you it is all about graphics.  To many others, it is about data.  So, how do we serve all customers??
The strategy is exactly what you have seen/heard:

1)      WPF 4.5 is going to have some significant data binding performance improvements.

2)      We are not redoing the graphics framework, but we are doing a lot of work to let you interoperate with lower level graphics so that if you need more graphics perf you can get it, and still keep the RAD of the rest of the framework.

[…] Hope it helps; apologies if it does not, and again, wait for Rob Relyea or someone else to make it official.  That is just my 2c as a person who bet heavily on WPF but has seen the data that drives the trade-offs the team has to make.

This will be disappointing to former Microsoft evangelist Scott Barnes, who has initiated a Fix WPF campaign.

The problem though is lack of clarity about the strategy. Look at Rodrigue’s third point above. Nobody can predict the future; but what is Microsoft’s current bet? Silverlight, HTML5, or maybe SuperNew.Next – for example, the rumoured new native code UI for Windows 8 or some variant of it?

My own view is that the current difficulties are rooted in what happened with Longhorn and the fact that the Windows team abandoned WPF back in 2004. I’ve written this up in more detail here.

Lest this post be misinterpreted, let me emphasise that Microsoft has a good track record in terms of supporting its Windows APIs long-term, even the ones that become non-strategic. Applications built with the first version of .NET still run; applications built with Visual Basic 6 mostly still run; applications built for ancient versions of Windows often still run or can be coaxed into running. Build an application with WPF or Silverlight today, and it will continue to work and be supported for many years to come.

My guess is that events like the coming 2011 MVP Summit and Mix 2011 in April will bring some clarity about Microsoft’s mobile, tablet, Windows and cross-platform story for rich clients.

Update: Barnes has his own take on this discussion here.

microsoft, mobile, silverlight, software development, vista, visual studio, windows

Microsoft still paying the price for botched Vista with muddled development strategy

2 Comments

Professional Developers Conference 2003. Windows Longhorn is revealed, with three “pillars”:

  • Avalon, later named Windows Presentation Foundation (WPF)
  • Indigo, later named Windows Communication Foundation (WCF)
  • WinFS, the relational file system that was later abandoned

With the benefit of hindsight, Microsoft got many things right with the vision it set out at PDC 2003. The company saw that a revolution in user interface technology was under way, driven by the powerful graphics capabilities of modern hardware, and that the old Win32 graphics API would have to be replaced, much as Windows itself replaced DOS and the command-line. XAML and WPF was its answer, bringing together .NET, DirectX, vector graphics, XML and declarative programming to form a new, rich, presentation framework that was both designer-friendly and programmer-friendly.

Microsoft also had plans to take a cut-down version of WPF cross-platform as a browser plugin. WPF/Everywhere, which became Silverlight, was to take WPF to the Mac and to mobile devices.

I still recall the early demos of Avalon, which greatly impressed me: beautiful, rich designs which made traditional Windows applications look dated.

Unfortunately Microsoft largely failed to execute its vision. The preview of Longhorn handed out at PDC, which used Avalon for its GUI, was desperately slow.

Fast forward to April 2005, and Windows geek Paul Thurrott reports on Longhorn progress:

I’m reflecting a bit on Longhorn 5048. My thoughts are not positive, not positive at all. This is a painful build to have to deal with after a year of waiting, a step back in some ways. I hope Microsoft has surprises up their sleeves. This has the makings of a train wreck.

Thurrott was right. But why did Longhorn go backwards? Well, at some point – and I am not sure of the date, but I think sometime in 2004 – Microsoft decided that the .NET API for Longhorn was not working, performance was too bad, defects too many. The Windows build was rebased on the code for Server 2003 and most of .NET was removed, as documented by Richard Grimes.

Vista as we now know was not a success for Microsoft, though it was by no means all bad and laid the foundation for the well-received Windows 7. My point though is how this impacted Microsoft’s strategy for the client API. WPF was shipped in Longhorn, and also back-ported to Windows XP, but it was there as a runtime for custom applications, not as part of the core operating system.

One way of seeing this is that when Longhorn ran into the ground and had to be reset, the Windows team within Microsoft vowed never again to depend on .NET. While I do not know if this is correct, as a model it makes sense of what has subsequently happened with Silverlight, IE and HTML5, and Windows Phone:

  • Windows team talks up IE9 at PDC 2010 and does not mention Silverlight
  • Microsoft refuses to deliver a tablet version of Windows Phone OS with its .NET application API, favouring some future version of full Windows instead

Note that in 2008 Microsoft advertised for a job vacancy including this in the description:

We will be determining the new Windows user interface guidelines and building a platform that supports it. We’ll eliminate much of the drudgery of Win32 UI development and enable rich, graphical, animated user interface by using markup based UI and a small, high performance, native code runtime.

In other words, the Windows team has possibly been working on its own native code equivalent to XAML and WPF, or perhaps a native code runtime for XAML presentation markup. Maybe this could appear in Windows 8 and support a new touch-oriented user interface.

In the meantime though, Microsoft’s developer division has continued a strong push for .NET, Silverlight and most recently Windows Phone. Look at Visual Studio or talk to the development folk, and you still get the impression that this is the future of Windows client applications.

All this adds up to a muddled development story, which is costly when it comes to evangelising the platform.

In particular, eight years after PDC 2003 there is no clarity about Microsoft’s rich client or RIA (Rich Internet Application) designer and developer story. Is it really WPF, Silverlight and .NET, or is it some new API yet to be revealed, or will IE9 as a runtime play a key role?

There is now a little bit more evidence for this confusion and its cost; but this post is long enough and I have covered it separately.