HTML5 Is Ready – Rebuttal to Facebook’s native app

Here’s a great “HTML5 Love Story” about the team at Sencha, who is passionate about using proper technologies for the one open web, who knew better than to trust that the failure of Facebook to create a reliable HTML5 app for users was because HTML5 wasn’t ready (as Facebook claimed). They built this demo to prove that HTML5 can do all that the now gone native FB app does and faster. The trick is you have to know what you are doing. Something it seems, FB doesn’t. Ready the full story and watch the comparison video: The Making of Fastbook: An HTML5 Love Story | Blog | Sencha. Or go try it yourself. Visit http://fb.html5isready.com on your favorite mobile browser.

When we started what became Sencha, we made a bet on the web: a bet that modern application development didn’t need anything except the browser, a great set of frameworks and a great set of tools. With those three weapons in hand, we knew developers could build applications that would delight users. The advent of HTML5 upped the game and it gave developers even more tools to let them treat the browser as an application development platform and not a page rendering engine. Developers sprang at the opportunity and unleashed a torrent of apps — on both desktop and mobile — that leveraged the new HTML5 capabilities to build amazing applications using web standards.

So, when Mark Zuckerberg said HTML5 wasn’t ready, we took a little offense to the comment.

We thought to ourselves: HTML5 can’t really be the reason that Facebook’s mobile application was slow. We knew what the browser on modern smart phones was capable of and what kind of rich capabilities HTML5 offered. We saw the latest generation of mobile devices — running at least iOS 5 or Android 4.1 — push ever increasing performance and HTML5 implementation scores. But perhaps most importantly, we’d seen what our customers were building and the amazing things they were creating using HTML5.

I totally agree with this sentiment and believe that native apps are the new flash to the web. They are fun and seem to be the way, but give it a few years and these native apps will quickly give way to web based apps that are browser based and offer speed and flexibility and consistence to the web experience. Sure, flash can do things that html still can’t. But I’m pretty sure no one would want to build their whole site in flash today. They would put the parts that need to be or the parts that belong in flash in flash and let the rest be standards compliant open web. Facebook has essentially built a flash based website for phones to access their website content. They will have to maintain and update this separate from their “real” version.

Our smart phones are helping us converge our devices, as in we no longer need a phone a camera a gps a notepad a … But it is not helping us converge our internet or content. We currently need to use a website in one way at our desk and another way on the go. Websites and the internet should have the same capabilities and the same uses no matter where we decide to use it. Sencha is showing us that, built correctly, HTML5 truly is ready to handle many things that belong in the browser rather than in a native app. We should never need to download a native app to access website data that we normally would just login at our desk. That’s inefficient, divergent and complicated. It’s against the openness and standards everyone preached and pined for and indeed “won” when flash-haters succeeded in ousting flash from mobile browsers. I actually respect Adobe for finally pulling the plug there because they too, believe in the web (and at the time, I was a full-time flash developer). I believe in the web too and that’s why I call it the one open web.

Apple "support" with fixed position layouts

This really echo's the reasons why I still have trouble with the 'thoughts on flash' mentality (although, I know flash is irrelevant here). It's similar in that there is this self proclaimed 'support' for html5 (making needing flash irrelevant)… but in real life the devices are far from supporting HTML5. Support to apple and support to developers is a totally different story. Even many simple things that are HTML5 become very difficult in developing for iPhone, iPad or other iOS devices. Here's an example of many issues that result in attempting to use features that iOS claims to "support".

Embedded Link

Issues with position fixed & scrolling on iOS
With the release of iOS 5, fixed positioned layout is said to be supported in MobileSafari. The word supported needs to be taken with a pinch of salt, because there's all kinds of issues which I i…

Semantic Chart for HTML5

I'm not going to get into the discussion on whether or not semantics are important, but want to share this flowchart for those who are interested in making a sensible web. It will help determine what HTML5 element is best for elements. Thanks fo the HTML5 doc!

Embedded Link

Let’s Talk about Semantics | HTML5 Doctor
It's time we had “the talk”. I could get you a book or recommend some sites from Dr Mike's special bookmarks folder, but the best way to make sure you get the right idea is to do it myself. I&…

Flash Gaming Technology – Notes from Lee Brimelow’s Adobe Presentation

Here are my notes on the presentation from Lee Brimelow of Adobe at the Atlanta Adobe Users Group Meeting: http://www.meetup.com/Adobe-User-Group-of-Atlanta/events/56200162/

What is flash for? Doing things the browser can’t! If you can use HTML5 then do it. Learn about it and learn the capabilities and know when to use what tool and when they are appropriate. It might not be easy, but it is where the industry is moving, don’t hide from it! If you want to do things that are to advanced for the current standards and browsers, then flash is most likely where you need to be. Adobe will always position Flash to be ahead of what is possible with browsers.

While you can do some gaming in browsers today, flash is now positioned to be the best solution for game development. It even can compile to native apps for ios and many successful apps have done so. Adobe has put in a site to showcase these games at: http://gaming.adobe.com

Adobe has a new partnership with unity. See example game: Angry bots.

Console sales are declining. We have so many other outlets to game: browsers, social, mobile devices… Soon professional games will be via Facebook and browsers.

Facebook angry birds game built in flash using stage 3D.

New gaming features:
Mouse lock.
Right and middle click events.
Concurrency, multi threading for player. Yo will not lock up with intense calculations.
Native extension Burls and extensions.

CS6:
Sprite sheet exporter!
Create js exporter, via Grant Skinner
Html 5 export to canvas a vector art.

Edge

11.3 – latest flash player
full screen keyboard input.
Background auto updates.
Audio streaming via net stream.
Improvements for low latency audio.
Stage 3D progressive texture streaming.
Lzma compression sort door byte array.
Native bitmap encoding to png and jpg.
Bitmap data draw with quality
Frame labels.

Air specific
USB debugging for ios
Native ios simulator support
Enhanced background support for ios
Android 4 stylus support
Mac app store support

Dolores, upcoming updates
As workers
Advanced profiling
Better sort for hardware accelerated video cards

Next
Refactorizing code base
Work on as virtual machine
Many action script language updates: stringent static typing as default, hardware oriented numeric types, type inference…

Link: Responsive Images: How they Almost Worked and What We Need

Mat discusses the options for getting responsive images along with responsive designs. We can use various means (server-side, client-side, mobile-first, html5 data attributes, cookies…), but none are fully satisfactory, especially with new browsers prefetching images before cookies can be set or html is even fully read and parsed. He states that bandwidth sniffing is…

a lot like setting something on fire to see exactly how flammable it is

Great analogy, since the only real way to know a bandwidth speed is to download something and time it… so we can’t effectively rely on that for determining which image file to deliver. A proposal for a new html element to handle multiple image source files, much like the new video and audio elements:

<picture>
<source src="high-res.jpg" media="min-width: 800px" />
<source src="mobile.jpg" />
<!-- Fallback content: -->
<img src="mobile.jpg" />
</picture>

via A List Apart: Articles: Responsive Images: How they Almost Worked and What We Need.