A friend of mine is working on a complicated publishing app; the data is XML, perfectly appropriate when your objects are documents. She told me they were thinking about automating some of the work by running XSLT transformations out there in the client with libxslt. I said “Well yeah, as long as the client’s a PC not a tablet”. The category of “things you can do on a PC but not a tablet” is interesting.
Anyone remember AJAX? Now we just talk about Web apps, with towers of JavaScript code (CoffeeScript for the ultra-hip) built on an ever-growing library substrate (yes, there is more than jQuery) making the browser look interesting.
It’s a good architecture! People like using browsers, JavaScript is growing up, the Web Standards Project of yore has sort of won, and REST keeps things nicely decoupled.
I dropped AJAX into that narrative for a reason. The ”X“ stood for XML, which these days feels kind of heavyweight for use in Web apps, unless you’re working with real actual documents. But when AJAX was a bright shiny new idea, we didn’t care, because we had near-infinite power at our disposal.
At the center of our world was a poor overtaxed Web server trying to take care of a kazillion users’ requests. It was usually running in maxed-out mode, while the computers it was serving were, in aggregate, infinitely powerful, had hundreds of meg of lightly-used memory, and typically ran with idle times averaging over 90%.
So all those other architectural advantages aside, the computer-resource macroeconomics weren’t subtle; any piece of work you could offload from server to client was a win.
It might still be. But there are clients and clients and clients. Like I said at the top, you can’t run an XSLT transform on a phone.
In fact, there are lots of things you can’t do on a phone. I’m privileged to work in close contact with platform engineers, and I’ve learned how close mobile frameworks live to the edge of the possible. There’s no spare memory and, since there’s no spare battery, there’s no spare CPU either. I’m not just talking about Android, either.
This sort of sucks. There was a time when every client was a browser running on a PC, and most PCs were in the big picture like most other PCs, and that’s how the world was. But now, we’re in a position where client memory is very nearly as scarce and precious as server memory. Which changes lots of things.
I’m not sure how this plays out. Right now, on Android or iOS, you can get more out of that candybar in your pocket with a native app than with Web code. But who knows how long that will last? We’ve got Chrome on Android now, and some of the phones they’re rolling out at MWC 2012 in Barcelona constitute pretty big iron. On the other hand, you’d maybe like your app to be available on a minimal developing-world phone too.
The one thing in the big picture that I don’t see changing any time soon is the basic JSON-over-HTTP architecture of more or less every interesting business app. That at least insulates the moving target running on the server (NodeJS? Go?) from the moving target running on the client (Dart? B2G?), and that has to be a good thing.
Comment feed for ongoing:
From: Anton (Feb 27 2012, at 23:16)
I'm not sure I follow why it is a problem to run XSLT - because it is resources-heavy?
We both closely follow MWC right now and the quad-core, 1.5 GHz phones are just coming. Yesterday I checked the Great Computer Language Shootout (aka The Computer Language Benchmarks Game) just for fun, and JavaScript is currently as fast (median) as Go and only 4x slower than C(!).
If I had to place a bet whether or not you could run XSLT tomorrow, I would say yes.
PS: To me, the bigger problem of web apps is the inability to access local filesystem, even just as a cache, if nothing else. To transfer 80 MB .tiff is not much fun.
[link]
From: DV (Feb 28 2012, at 02:43)
I must miss something ...
Huh, tablets sporting Safari or Webkit
use libxslt. If it's goo enough for the
browser, I hardly see why it would be
a problem for other documents ...
"you can’t run an XSLT transform on a phone", actually I'm pretty sure you
do, you may just not notice it :) check
with your browser team !
That said not using XSLT because it
has a lot of restrictions as a language
I would perfectly understand, but the
platform issue doesn't make sense to
me, again I must be missing something :-)
Daniel
[link]
From: Paul Morriss (Feb 28 2012, at 03:02)
I normally finish your articles quite satisfied. However in this case I'm curious what it is about XSLT that is so resource-intensive. Can you give a bit more info please?
[link]
From: Chris Adams (Feb 28 2012, at 06:10)
In some quick testing, I haven't found a client side XSLT demo which doesn't run well on my iPhone so this is probably more of an Android browser problem which Chrome can address.
That said, the reason XSLT failed on the browser was performance and incompatibility issues which are particularly noxious given the combination of strict error handling, poor tools and documentation, and client variations which plague the XML world. Phones tend to have more consistent platform versions but they don't change much else.
[link]
From: Rob (Feb 28 2012, at 07:21)
Current tablets can run fully rendered 3D multiplayer combat games but can't translate XML to HTML? Really?
[link]
From: ben (Feb 28 2012, at 07:25)
From a UX perspective, I'm reminded of 56kbps, 800x600 when the subject of mobile comes up. JSON and frameworks and local storage and (gasp!) CSS that actually works do make it a lot more interesting, thought.
[link]
From: Avi Flax (Feb 28 2012, at 08:16)
A quick search of Stack Overflow reveals a few relevant questions:
http://stackoverflow.com/q/3640901
http://stackoverflow.com/q/462440
wherein it’s made clear that one *can* use libxslt in an iOS app — you just have to import the actual source code, to work around some asinine Apple rule which prohibits dynamic lib linking. Annoying, but workable.
[link]
From: Anton McConville (Feb 28 2012, at 08:44)
I guess it depends on the volume of XML and the complexity of the transform, on whether or not the XSLT works well on the phone.
On the subject of using XML in mobile apps, I've been building my first native iPhone app.
While I've been using JSON as a preference for my web apps for a long time now, I ended up using XML as my data choice on the iPhone - mostly because my research didn't yield a convincing candidate for an iOS JSON library. That could be completely down to poor research on my part, but that's how it played out for me.
I liked the Google library for XML on the iPhone and have been satisfied with it's use and performance so far.
My data is used to drive a map, and some news lists. I use the same appengine backend to drive a web app map - offering both JSON and XML presentations for web and mobile respectively - not a lot of extra work for me to program. The native mobile map is definitely faster and nicer to use.
[link]
From: len (Feb 28 2012, at 13:38)
I concur that something isn't quite finished here. What Rob Said.
A decade ago sitting at Intergraph, I was repeatedly told that XML would be too slow for our super-modern applications particularly in mapping.
Turned out to be wrong but they fought the future as long as they could. In at least one case, I'd inquire and find out they were relying on the DOM almost exclusively.
So maybe some case data would be useful here. I suspect it "depends" and sometimes the diaper overflows.
At least in System.XML (not a topic here but..), the problem children are still character entities and the fact that by dissing the DTD early on, the XML Core made a mess of what required careful thinking on the part of the implementors and that got passed along the food chain to the application developers all of whom turned their noses up and left the customers in a bad place and not sure who to blame.
In the mil-pubs doc publishing world, we blame the programmers. I find myself writing my own tools as a result to do what the XML Modern Tools should do better and maybe some do. ;)
[link]
From: Meower68 (Feb 28 2012, at 14:07)
The problem with so much XML and XSLT is that it is very heavy and verbose and you have to parse ALL of it before you can do anything with it.
Let's say you want to use XSLT to transform an XML document. You must:
* parse the template using the DOM model, building a data structure inside the XSL engine
* parse the entire XML document using the DOM model, creating yet another data structure within the XSL engine
* actually do the transformation, creating a transformed data structure in the XSL engine
* render the data structure back to a stream of XML text and send it out.
All of this requires loads of CPU and RAM resources which are ramping up on mobile devices but still are far behind sited, server- or workstation-class machines.
If you could make an XSL engine which consumed the XML document in SAX fashion instead of DOM, that would reduce the requirements. I don't know of any which do and, indeed, there are some indexing and sorting capabilities in XSL which would appear to make that impossible. Still, it's worth thinking about.
If you could use partial evaluation with the XSL template and create a method/function, at runtime, which transformed the document, the separation of the first two stages, with some optimization in between, might reduce the requirements.
Until then, every call to transform an XML document with XSL is essentially running an interpreter, where you have to load the interpreted language's grammar at runtime.
[link]
From: Chris Jaynes (Feb 28 2012, at 19:06)
I think some folks are missing the point, here. The way I read this, the idea is that, given the choice, you don't want to do long-running CPU- and memory-intensive operations on the client when the client is a phone, whether you're doing XSL transforms or anything else that hogs the phone's minimal resources. This is especially true if you're dealing with the additional overhead of the browser environment.
With that said, there are a lot of things that you CAN do in the browser on the phone, and there are a lot of native apps out there that simply don't need to exist (you heard me IMDB and Chipotle Labs). I'd much prefer to use simple, clean lightweight web interfaces than have to worry about juggling dozens of applications for the various websites that I use.
If you're not crunching numbers, the browser fits that JSON-over-HTTP architecture pretty nicely indeed.
[link]
From: Tim (but not THE Tim) (Mar 06 2012, at 19:45)
It's a tiny bit dated, but it's worth it to find the PalmOS (yes PalmOS not WebOS) developer documents, where they have a good discussion about developing for a device on which you need to conserve battery power and memory. The philosophy for the Palm devices, which had fewer resources than just about any phone, is still useful.
[link]
From: Ken Meltsner (Mar 15 2012, at 17:33)
I think XSLT runs fine on tablets and handhelds, even current hardware (see http://ambrosoft.com/content/gregorxslt ), but I'd certainly vote for an XML 1.0--, some sort of backward-compatible, restricted dialect of XML, if that would help.
The same trend is happening at the server level as well -- for a while, I figured we'd never need to worry about CPU, storage, or RAM for most of our applications given that a single socket system was usually fast enough, but with virtualized servers and SANs, you can, in fact, buy just a slice of CPU.
[link]