famo.us is a 2.5-year-old Silicon Valley startup that claims to have solved the performance challenges of HTML5.
“Performance challenges?” you might ask, but only if you hadn’t yet heard the tales of Facebook and LinkedIn turning an about face from HTML5 in favor of native applications. As I blogged about a year ago, HTML5 has had mixed results in the wild, driving many to adopt native or hybrid native/html5 strategies. As I discussed in describing the event where I first encountered famo.us, the classic example of poor HTML5 performance is the scrollview. Quoting Trunal Bhanse of LinkedIn:
“Mobile devices have less memory and CPU power compared to Desktop computers. If you render a very long list in the HTML, you run the risk of crashing the device. This makes it challenging to build large, interactive HTML5 apps for mobile devices. Native technologies provide UITableViewControllerto build long, infinite scrolling lists. UITableView contains reusable UITableViewCells which are optimized for memory, performance and responsiveness . For HTML5, we did not have any solution. So we set out to build one!”
The article by Bhanse is a great example of the hurdles one has to go through to create an experience with HTML5. Shouldn’t something like this be easy?
The famo.us founders have explained in numerous presentations how they went about creating their own rendering engine, and have showed impressive demos. Latest reports are that the famo.us library has four components: a rendering engine, a physics engine, a gesture engine for input, and an output engine.
famo.us says they plan to open source the entire library under the Mozilla Public License Version 2, some time in 2014.
While the general response to famo.us has been an enthusiastic clamor from developers to join the beta (70,000 have reportedly signed up), and there is certainly rapt attention at developer conferences and meet ups, the way they are going about promoting this technology has rubbed many in the development community the wrong way. There are several things that seem to have triggered skepticism.
Steve Newcomb is a very passionate person. He talks with a style that echoes Steve Jobs: his goals are nothing short of changing the world. A seasoned entrepreneur, Newcomb has written essays about “Cult Creation” as a metaphor for his company- and team-building success. From his LinkedIn profile description of his work at famo.us:
“Microsoft and Apple owned the OS, Oracle owned the database, and Google owned the search engine, but no one has ever owned the UI layer. Whoever does own it for mobile devices will own something insanely valuable – every tap event that exists for each user. Imagine the company that owns the UI layer on top of Facebook, Twitter, LinkedIn and Gmail, that would enable that company to build the first unified social graph.”
Perhaps there is a bit more than saving the world on his agenda…
When I saw Newcomb speak in San Francisco, he told a story of building a computer with his father, and the moment of joy when typing a “k” key on the keyboard made a letter appear on the screen. This was perhaps a perfect metaphor for his mighty framework coming together, but it was also eerily similar to a scene in the movie “Jobs.” It is sometimes hard to tell where the genuine technology passion ends and the hype begins.
Newcomb is a consummate salesperson, and when he describes the technology, he can make statements that are slightly inaccurate technically. One huge example is his oft-repeated claim that famo.us talks to the GPU directly. For example, from a VentureBeat interview:
Technically, the conversation is not so direct (see this presentation or this explanation to see the more granular picture). The “direct to GPU” message may work with investors, but this sort of thing does not work as a sound byte with developers, but instead triggers their BS meters. In Newcomb’s defense, he has provided more detailed grounding in reality in his more in depth presentations.
“16,000 developers have signed up for the beta, but ‘we are not letting any of them touch anything yet.’”
What is the point of a beta? The lack of anything tangible for the development community to test certainly sets famo.us at square zero in terms of developer adoption, whether or not they have done anything meaningful for web development.
So, the “traditional” approaches to standards-based developments were for documents, not apps, and we must then do something different. Newcomb has outlined a vision of a JQuery-like, accessible-to-mere-mortals, approach to such an API.
That sounds absolutely great, once we get past abandoning standards 20 years in the making, but an elegant, human-usable API is a goal orthogonal to the performance work they have demonstrated. It would seem that if famo.us were serious about such a goal, they would engage some of the 70,000 signers-up with some actual code sooner than later.
Funny that Apple, once perceived to have an “underdog” status, has now assumed the stature of its old nemesis, Microsoft, as a champion of delaying and impeding standards (this is the scene in Animal Farm where Napoleon stands up). This can’t last: Apple will be forced, probably quite soon, to support WebGL. It is, after all, a simple flag to switch; the support is there under the hood.
It would be supreme irony if this switch happens before famo.us releases any code. Certainly the “direct to GPU” sort of behavior can be handled in raw WebGL. A “physics engine” is a nice-to-have but WebGL alone, when functional on mobile, may offer performant scrollview and the core capabilities touted by famo.us, especially when open source libraries tested by the development community attain JQuery-like power.
I sincerely hope that famo.us is as great as they imply, and that the code will be available soon. There is simply insufficient data to assess the value of this framework at this time.
I am at the HTML5 Developers’ Conference in San Francisco. One of my friends said “it must feel like Christmas for you over there” and it actually does feel that way, not in the sense of “everything is easy now” but more in the sense of “our path forward is clear.” Like Christmas before a year-long war we know we will win.
Paul Irish spoke this morning about the various tools he’s using these days, or as of 10/16/12 (one gets the impression he’ll be adding a new one tomorrow), so certainly things are more mature in terms of the “tool chain” (in the old days we were waiting for “tools” to simply get plural, as text editors reigned supreme). Now we can say there are ToolS for HTML5. Cool.
Even more interesting to me than Paul’s talk was the talk by James Pearce on “Keeping the Dream Alive” – he had the good news and bad news about HTML5, which can be summarized by two parts of a single quote from Mark Zuckerberg…
“When I’m introspective about the last few years, I think the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native. Because it just wasn’t there.”
When Facebook moved from HTML5 to iOS, they had stunning gains almost overnight.
The good (the part that has received less hype):
“It’s not that HTML5 is bad. I’m actually, long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us…”
Yes it is like Christmas for HTML5 geeks, finally our work is getting somewhere. It will be very interesting to see what happens over the next year. It is not easy to reconcile the formats required of modern devices, yet the range of required approaches is getting more clearly known and the tools keep evolving to make things easier.
Recently we have been working on some very exciting technology with Adobe, bringing together some technologies we’ve been working on for over a decade with one of their most recent technologies, the Digital Publishing Suite. We watched this technology develop over the past few years, and honestly had our reservations about the initial releases and apparent intentions of Adobe at the outset of this offering:
While point 1 remains valid: native apps are not always the ideal way to bring content to devices, it is still true that sometimes a native app is precisely the ideal way to provide content. Native applications may perform better, manage offline content with more power, and access a greater range of device capabilities. Also “app stores” are good and bad: bad in that they make distribution more costly, yet good in that they are often a great way to get users to find and reach your content.
Point 2 is no longer valid: things have changed substantively over the past two years. There have been dramatic improvements in the underpinning technology around DPS, with Adobe investing heavily in every dimension of the DPS solution: the “liquid layout” features of InDesign CS6 were created with DPS specifically in mind, and include technology that makes the content much more efficient than it was with the prototypical wired reader, which one senses had been built in a weekend when Adobe noticed that Flash wasn’t going on the iPad. Adobe has been contributing to CSS specifications and the WebKit project, they have core tech that is unrivaled if they really wish to make text work well on tablet devices, and their power is starting to show as DPS improves over time. As Chris Converse has brilliantly taught and demonstrated, there is now the capability in DPS to add fairly arbitrary HTML5 content. DPS’ value is proven out as devices proliferate and iPad competition looms on the horizon with an even larger distant silhouette each day.
Point 3 is no longer valid, either. While initially Adobe DPS aggressively pursued the magazine market with a fervor that would make Suge Knight proud, after they attained that market they did realize that other markets (particularly the new ones I will mention later) have more partner dependencies and are best built within an ecosystem, and extensibility is essential to the growth of DPS even in the magazine space. There are now fantastic APIs available to developers, which enable publishing workflows never before possible.
We at Silicon Publishing are now building InDesign Server-based DPS solutions of two types, which parallel our main two products:
In the catalog world, so many manufacturers and retailers produce print or print-like (some only distributed as PDF, but retaining the print design paradigm) content with Adobe InDesign Server that rendering a tablet application from the same process makes much sense, and it is easy to do thanks to the automation capability of InDesign (including most interactive features) as well as the packaging and deployment APIs of the Digital Publishing Suite.
In personal publishing, for example creating photobooks online, the process of output is largely identical, yet the possibilities even more stunning. Grandma makes a photobook online, and within an hour, can have iPad and Android versions of the photobook available to her family. Silicon Designer gives us a great platform from which to build out this functionality.
We are looking forward to sharing more about this in the coming months.
We have been automating Adobe InDesign for 12 years, InDesign Server for 7 (since it came out), and it seems that just now we are finally being proven right in our bet long ago that going with the slowest, yet far and away most robust, composition engine would in the long run be the best path. After all, hardware just gets faster and faster. Desktop tools and capabilities do tend to end up on servers.
Now, in 2012, we can finally say that advances in Hardware, RIP software, and InDesign Server itself, have given us many tastes of sufficiently fast performance, and we can see a vision when InDesign Server is the tool of choice for even the most throughput-intensive documents, such as transactional statements.
In the year 2000, it was quite a long-term vision. Having just started Silicon Publishing, we wanted to do exactly what we had done previously at Bertelsmann: compose data-generated documents like catalogs and directories from data sources, flowed through document templates. At Bertelsmann we had primarily used Xyvision, which was an industrial-strength composition tool with powerful automation, robust page composition, and stunning throughput. Yet the cost was prohibitive to our small, new company and we weren’t eager to hire a “xy operator” who knew the esoteric ins and outs of making the thing work. There was something liberating about controlling the complete job from one piece of code, and seeing the output in real time in a desktop application like FrameMaker or InDesign.
Those were the two tools we tried: FrameMaker 6.5 and InDesign 1.0. Frame had MIF, a wonderful language for defining documents, and we got quite adept at generating MIF from code, even from XSLT in some cases. with InDesign it was a matter of using a scripting language: AppleScript or VBScript at the time. We later moved to ExtendScript as our primary language for automation, which we now augment with C++ plugins or Flex-built CS Extensions as appropriate.
Frame was much more robust, especially back then when InDesign didn’t even have tables. But Frame was old, while InDesign was exciting and new: the exposure to automation was unparalleled, and as we saw the momentum of the product we could feel that this was going to be the place Adobe put their best typography and layout capability, and we knew Adobe was uniquely qualified to see this through.
We got work automating catalogs and directories, and when we provided data-generated typesetting as a service, nobody knew that we weren’t using Xyvision or something comparable. We found we could automate InDesign to do pretty much anything we could do in Xyvision. It was sometimes a pain to automate things that really belonged in the product (tables didn’t show up until InDesign 2.0) but the momentum of the product with each release felt wonderful, and the fundamental full exposure to automation was a joy: anything we could imagine, we could do. This could not be said of any previous layout application we had seen, nor any we have seen since.
It was a bit ridiculous, however, when we would deploy automation solutions to our clients. At Bertelsmann we had mainly been a service bureau or ASP-model solution provider (what they call SaaS today… in the 90s we did have SaaS, Cloud, and AJAX, by the way, they had merely not yet been named and hyped by the late-adopters). With a hosted solution we could turn 300-page complex directories in seconds or a few minutes, depending on complexity. Tolerable speed in any case, from a true server.
As a small company, we could have provided hosted services, but (a) at the time we weren’t even perceived as a company, we were seen as consultants because there were so few of us, and (b) the tools we were using weren’t yet licensed for server usage. FrameMaker Server did come out soon after we started, yet InDesign was not licensed to be used as a server nor would it be practical, though we did hear of companies setting up “desktop farms” some of which we know persist to this day.
Yet our client base grew, and many wanted to run automated publishing themselves, in house. In such cases, we had to explain to them that they would need to set up a desktop workstation, and in some cases (i.e. producing 150 100-page directories driven by a business rules table) let a process run overnight: they would literally see the documents compose on the screen. They scratched their heads, but they didn’t complain. Many of these solutions have run for years and we still have clients that run old desktop code.
Still, it was surprising how solid the applications were and how much throughput moved through them. We found InDesign kept getting better and better, and the precision was stunning: for example we automated generation of patient encounter forms, and we could analyze proximity of black ink to the bubbles that users would mark, and we could define proximity rules and copy fitting logic in composition that allowed maximal usage of the limited space on these crowded forms.
It was just a bit silly that this was not on a server. We had been doing work for Adobe since 2000, yet we weren’t deeply connected to the InDesign group. We asked for an InDesign Server from all sorts of groups at Adobe, which seemed to come and go at random. There were server efforts such as “Altercast” and “Document Server” and there was at one point a “Server Tools Group.” We begged anyone who would give us the time of day for an InDesign Server, and it gradually dawned on us that Adobe was a collection of largely un-connected product silos, so whatever emotion we brought to bear on an Acrobat Sales Rep was unlikely to have great impact.
It was probably completely unrelated to our impassioned pleas, but in 2004 we finally got wind of an effort to create an InDesign Server. Based on InDesign CS1, there was an internal project that split out the model from the UI and allowed for server-like usage of the core InDesign engine – notably, this also had XML round trip that was prototyped but never showed up in the product. In 2005 when I got a chance to talk to the people in charge of the InDesign Server project for CS2, I said that we should definitely be in the beta as I was probably the only person in the world who literally dreamed of an InDesign Server. We were included in the first group of solution providers/resellers.
I actually got a bit of work for Adobe writing about the release of InDesign Server, and I wrote an article for InDesign Magazine about our love of this new thing. Yet when I went up to meet the great Whitney McCleary, one of InDesign’s spiritual leaders, I was given the bad news about performance… it was still slow. “We decided to release this technology to developers,” she said, “and we decided not to support it.” There was extremely little server about InDesign server, they had essentially hacked out the parts that didn’t depend on UI and wrapped them in a little bit of a server-esque container so you could send a SOAP message that would tell it what script to run. You could spawn multiple instances, but the rewards were not nearly linear, even a fairly decent server would not stun us with throughput.
So here was the real bet I’m talking about – 5 years had gone by, we weren’t impressed with speed, and were disappointed that the software itself wouldn’t help us much with making it go faster. Yet the quality… by now, there was pretty much every bell and whistle you could imagine: Transparency, tables, text on a path, referenced objects from Illustrator and Photoshop, really high quality PDF output with fine-grained control, I think by CS3 the feature set was at the point you could say it had a far-and-away advantage over any other page layout engine. Yet it was… slow.
At least we had a server, we had a mechanism to add servers, but for transactional documents and even some classes of promotional documents it was prohibitively slow. We used XMPie and built our own plug-ins to do what XMPie did, but even that was slow. And the documents created could often take forever to RIP. We liked XMPie’s export to VIPP, PPML, VPS, etc. yet there was still no comparison to a native VIPP job or old-school AFP.
Why was it so slow? Mainly because it was doing substantial processing: no pain, no gain. Managing layers of transparency has obvious processing cost. When you use the Paragraph Composer, it is not the dumb, brute-force, “slap text on a page” process of most transactional engines, but the artificial intelligence that makes InDesign output look like it was crafted by a seasoned typesetter requires that the content of the entire paragraph and all contained styles are analyzed to determine how characters are placed on the page.
We dabbled in faster, less robust tools but decided fundamentally to stick with InDesign, as by then it had completely differentiated itself from any other composition tool both in terms of quality of output and exposure to automation. Our logic in sticking with InDesign Server was that some day, hardware would reach performance levels where throughput would be acceptable for more and more document types, and that PDF-based RIP software would one day work.
Having been heads down the past 5 years deploying InDesign Server solutions, I look around today and I’m happily surprised that our dream is starting to come true. We are not benefitting from a throughput improvement on quite the scale of Moore’s Law, as processor speed is just one factor in IDS throughput, yet we are finding new multi-core servers are exponentially faster than what we used to see and more and more document types are becoming viable with IDS. And PDF-based RIP software is truly stunning. HP in particular has been fantastic at building out RIP software and Adobe has made some steps towards optimizing InDesign Server for high throughput applications. The beauty of this to us is that the page layout capability is not sacrificed at all; there is less and less need over time for compromise between throughput and output quality.
We have been working hard at Scene7 Web to Print for quite some time now, seeing it come of age and deploying some serious solutions. While we started out with full-blown Silicon Designer on top of Scene7, and that remains our primary form of development, we are getting more and more opportunities for which a simple, html-based interface makes sense.
Don’t get me wrong, we love the robust online design interface of traditional Silicon Designer implementations: it is very cool to work in the browser in real time as you design things, without having to wait for updates from the server, and to work from the web in ways that used to be possible only in desktop applications. Along these lines, we continue to extend our HTML5 work, and are seeing some amazing results. But here are some reasons for simple form-based entry:
It is also true that we can, even with a form-based experience, render HTML5-based imaging on the client… yet there are numerous challenges in making this as robust as what a server-based renderer such as Scene7 can offer. And serious print from HTML5 is still a ways off.
Then when we look at server-based rendition… Scene7 is far ahead of its competition: high-quality print output with very fast composition speed, results returned to the browser fast enough to be very close to direct editing. And the fact that it is coming from the composition server, literally, ensures perfect fidelity between web and print.
To read the PR about the Financial Times, you would have thought they had just invented the Web App. Yet as with so many “new” inventions (“AJAX”, “Cloud”…), the FT is merely leveraging technology that has been around for years. There is some newsworthy relevance to it, as they do represent a minority in the news industry and they apparently did build a decent app; so on balance, just like with AJAX and the Cloud, it is so inspiring to see the technology succeed that the late adopters painting themselves as innovators are forgiven.
Web Apps for devices such as the iPhone have been around since the iPhone itself: all the initial apps available for the iPhone were in fact Web Apps. Part of the initial PR for the iPhone was around just such an approach to applications, and Apple still provides core developer support that help truly innovative companies like Codify Design build such applications.
Apple is in the strange position of advancing both a closed, proprietary system with iOS, while simultaneously advancing web standards by using WebKit and HTML5. When a company like Google or Facebook use the Web App approach, it can look like a fundamental assault on iOS itself (and this was dramatized as such 2 years ago with Google, and last week with Facebook). Yet it would seem that Apple has gone far enough with support for standards that there is no turning back. Web Apps appear to be here to stay.
We at Silicon Publishing have seen great interest in tablet forms of everything we do, and while there are applications where native apps shine, our general philosophy is to use the Web App approach unless a native app has a really compelling benefit.
Certainly Web Apps are very cool in certain cases: a business distributing content to their internal staff, informational content distributed to consumers, etc. Tim Berners-Lee has a point about the pitfalls of the “walled garden” yet we still find ourselves building native iOS apps as well and can’t argue with those who think they need them.
We have two main products at Silicon Publishing: Silicon Paginator, which spews forth content from data sources, and Silicon Designer, which lets users edit documents online. Both are evolving to fully support tablets, with relatively simple extensions of Paginator (leveraging the thoughtful work of Codify Design who help us with this) rendering powerful output to tablets, while it is taking heavy work to define the Designer interface for tablets, and completion of that is a ways off. Editing/authoring is exponentially more involved than publishing.
The problem with tablet UI for editing is pretty much identical whether you are building a Web App or a native app… tablets are a very different UI, and working without a mouse makes, for example, text selection something of a UI challenge, one that even Apple hasn’t solved really well yet. Take editing inline formats, please (making a single word bold). I don’t believe there exists an elegant interface for that, currently. We’re working on it, and we’re poised to steal the best work of whoever gets it right.
It isn’t trivial to make Web Apps work. While there are tools that are improving, they are just starting to evolve, and to make things work is alot like any other new technology, you have to surf around to find nuggets of information to get past the initial obstacles.