In the end, HTML is just a standard for defining view element hierarchies; CSS is just a standard for specifying declarative layout constraints on those element hierarchies; and JavaScript is (supposed to be) just a standard for specifying how interactions with those views are bound to your view-controller. (The view-controller in a browser originally being an NPAPI <object> like a Java or ActiveX applet.)
None of these standard formats has any particular tie to the way web browsers use them. The standards, of course, go beyond syntax, and also specify the HTML elements, CSS properties, and JS DOM that define "the web" as a platform. But it's perfectly possible to use HTML, CSS, and JS syntax—with standard parsers!—to power your own windowing toolkit.
Define your windowing toolkit's view hierarchy format as "HTML syntax, but with these valid elements" (where they map to the controls in the toolkit.) Define your windowing toolkit's layout constraint properties format as "CSS but with these valid properties", where these map to the properties the toolkit exposes on the controls. And finally, drop-in a JS engine, but don't tell it to expose any APIs to the view to control things from Javascript; rather just mirror the API of the view-controller attached to the view as a set of opaque callback functions that can be hooked up to the elements of the view with addEventListener.
XUL or XAML could have just been this. ePub is basically just this (though in some implementations a webview is used.)
And, as a side-benefit, it becomes very easy to, like ePub, define your element and layout-constraint formats as supersets of HTML and CSS, such that people can still use familiar HTML elements and CSS properties for inline rich-text styling inside <label>s et al, while still using your toolkit's controls for everything else.
And I'm trying to build something that's optimized for the future devices, and when you're building something from scratch you have freedom to make a choice, and I think JSON makes a lot of sense going forward, since this is just the beginning of this project.
Hope this makes sense!
And all computers and devices made in the last century have no problem dealing with XML, HTML, JS over the wire - in fact this is exactly what web browsers have been doing. So even though you're dealing with native iOS apps and not webpages, that doesn't mean you can't use a similar XML format(or any other document markup language) along with a proper scripting language. And if you insist on staying close to JSON, you could go an all JS approach and use JS(instead of JSON) to describe your views, and also be able to embed JS computations - this is exactly what React does, and does very well.
And again, JSON is not a document markup language, so optimizing it for displaying documents/interfaces seems futile when you can just use XML and save yourself and the interpreter some pain.
That's not simple. JSON is simple. Yours is two things, JSON is one thing. And a lot of people are responding positively to this, so the author may be on to something. JSON is NOT the best language for full expressiveness, you're absolutely right about that. But it's simple, it's one single syntax (not two), and it feels like "just configuration" even though you're doing the same amount of logic.
> so optimizing it for displaying documents/interfaces seems futile
I mean, this guy did it, didn't he? And it's open source so now you can too.
I'm glad people build new things. This is cool. Maybe it'll catch on, maybe it won't, but I'm glad he used JSON and not XML+JS. We already have phonegap and cocoon for that ;).
It's ugly as hell and always has been. I suspect only Java developers could love such a tedious, verbose thing ;-)
Plus, JSON is really close to YAML/coffeescript/Ruby/python/pug so I can write even less keystrokes and compile to JSON. I'd be really interested to see your interface implemented without the braces and brackets. I bet that would make it extremely approachable to non-programmers.
And then you have the problem that most clients will break with the new HTML structure.
In contrast, a separately designed JSON or XML structure (if you follow some simply sanity rules) can be kept backwards compatible for a long time.
For a simple app, I think this is a good idea - going to play around with it for some simple apps.