3 ms·

The problem with this is that there will always be some sort of disadvantage HTML5/hybrid/etc apps have over real native apps. Things like interaction, calendar

The problem with this is that there will always be some sort of disadvantage HTML5/hybrid/etc apps have over real native apps. Things like interaction, calendar integration, 3D graphics, etc, etc never work as well as they do as for native apps. In addition, if they do work on a technical level, Apple or Google may add an API tomorrow that either breaks, or you'll have to wait on the supplier of your HTML5 magic framework to add support, etc. If you want high quality, responsive UIs and apps, native is the way to go. For a simple app, I think this is a good idea - going to play around with it for some simple apps.

derefr 10y ago
You're assuming that choosing HTML as a format forces you to use all the associated web-platform goop to render it. 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.
- vog 10y ago
  The problem here is backwards compatiblity. As your HTML file evolves, you will want to restructure it. CSS only takes you that far, at some point you need to adjust your HTML structure. 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.
- gliechtenstein 10y ago
  I totally understand where you're coming from. Here's my rationale: Most mobile devices and future devices will already use JSON as main method of data transmission. 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!
  - NMDaniel 10y ago
    This doesn't make sense. JSON is used because it's a handy data interchange format, but it doesn't mean it's the best tool for every job. XML is a document markup language that is much, much better than JSON for describing interfaces and alike. And even then it's not really ideal for describing control flow and computations that are needed for any meaningful app that is not a static page (see XAML, AngularJS, FXML, - they do have some power but they're still tied to real programming languages: C#, Javascript, and Java, respectively.) 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.

derefr 10y ago

You're assuming that choosing HTML as a format forces you to use all the associated web-platform goop to render it. 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.

vog 10y ago
The problem here is backwards compatiblity. As your HTML file evolves, you will want to restructure it. CSS only takes you that far, at some point you need to adjust your HTML structure. 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.
gliechtenstein 10y ago
I totally understand where you're coming from. Here's my rationale: Most mobile devices and future devices will already use JSON as main method of data transmission. 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!
- NMDaniel 10y ago
  This doesn't make sense. JSON is used because it's a handy data interchange format, but it doesn't mean it's the best tool for every job. XML is a document markup language that is much, much better than JSON for describing interfaces and alike. And even then it's not really ideal for describing control flow and computations that are needed for any meaningful app that is not a static page (see XAML, AngularJS, FXML, - they do have some power but they're still tied to real programming languages: C#, Javascript, and Java, respectively.) 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.