1) it uses templating (in our case, HTML, Android XML, and XIB) 2) it is cross platform, runs everywhere, even server 3) it produces native apps
It's different in this sense:
1) it doesn't do DOM diffing, it does two-way data-binding 2) it's statically compiled to native code, it doesn't try to run JS in native platforms, and doesn't require any async seems between between the native platform (it's all static linkage)
There may be other differences. The audience is Java and people who want no-compromise native integration. We target 70% code sharing between platforms, but expect the UI to be rebuilt for each platform.
The core engineers behind J2ObjC were those who built Swing at Sun. We're pretty sour on the idea that write-once run-anywhere UIs are possible. Best experience dictates custom design for each frontend IMHO, and shared UI widgets may get you into an 'uncanny valley' state where you're composing the native widgets in ways that are alien to platform specific style guidelines.
The guy in the video said a similar thing. It sounds like they want people to be able to use the same tools for each platform, not necessarily share all the code.
That's an odd conclusion. They're clearly possible, perhaps you mean they don't provide some notion of excellent UI. But even then, web apps are rather a big counter-example ... web apps have never looked native, never been consistent with each other, they don't even try, yet many of them are very popular.
The nativeness of UI is something that seems to matter to developers more than end users. Users react strongly to polish and strong design, but if that is totally inconsistent with the platform only a vocal minority seem to care.
The point about Swing is that, it's good, so long as we're talking about custom LAF, not the Windows/Motif/OSX PLAF, which look/act sort of like the OS UX, but not quite.