Closed abueide closed 7 years ago
Let's look at it like this.
HTML is not a data format (even if technically it carries data). It is a document markup language. If we wanted to use something similar to HTML, then we would have gone with XML which is a data format. However, the main reasons I believe Json was chosen was for its Human readability and Smaller footprint as well as how easy it is to extend. And no, HTML doesn't serve the same purpose.
To answer your other questions.
i think because it's more convenient. Almost all API's use JSON.(firebase, rest APIS, etc). I think it promotes consistency - JSON for everything data exchange related.
@frostymarvelous My second question was more of asking why jsonette wouldn't have the same security risks as web development having access to the os api. Thanks for your answer
HTML can describe a "document" that can include some UI components (buttons, forms, with text fields, selects menus etc.) but it is not a 1-to-1 mapping with native iOS (or Android) UI components. And HTML can't describe behaviour. You have to use JavaScript for that.
HTML uses a rendering engine to render the text-based HTML into what you see on the screen. This is slower than using native components.
There are frameworks that let you write (cross-platform) mobile apps using HTML, CSS and JavaScript. The most well-known is probably Cordova (ex-PhoneGap). However is does not work the same as Jasonette. It actually embeds a browser window in your app, and includes a small web server and a JavaScript gateway layer to allow you to access the device's APIs. But the whole thing is packages into an app, the HTML is not a remote server.
There is also React Native that allows you to generate native apps from an HTML/JS codebase, bu I am not familiar with it.
@abueide that never actually crossed my mind. But the answer is not so simple. It depends.
The main problem with web apps having access to native apis is an issue of trust. We visit hundreds of sites each day and not knowing what each of them is doing with our device can be an issue.
First, Jasonette as with all other native applications, needs to request for permission before using native apis e.g. Geolocation. It is the same as if you downloaded an app from the app store. You are exposed to similar levels of risk. If the publisher is malicious, your data is used improperly. But then, you chose to trust the app anyway.
Second, Jason doesn't actually contain any scripts, but simply "instructions" to Jasonette to perform certain actions. It doesn't have access to the native api's but to the wrappers that Jasonette provides around these apis. That means you won't be able to say, start the camera if Jasonette doesn't provide an action for that.
Now, why I say it depends is this. As Jasonette is dynamic, a publisher could theoretically get their app into the store masquerading as benign but then later update the endpoint to perform something bad. But that depends however on how powerful the actions that Jasonette exposes are, and the permissions you grant the app. Another thing could be if an exploit was found in Jasonette itself.
I wouldn't worry too much about it as in order to do something really nasty, you would need the native code in the app before publishing. And if that code is detected by the app store to be malicious, your app will be rejected.
Thanks for your answers @frostymarvelous and @HereThereBeMonsters . So a use case i'm imagining for jsonette is an app browser that is crossplatform and essentially lets you bypass the appstore, and bypass the need to have the apple sdk in order to develop apps for ios. I have a few questions 1) Is this one of the intended used cases for jsonette? 2) Would this app browser be able to use the apple permission system for each new app opened, or would it have to develop its own permission system?
Answer to the original question is actually super simple:
It's because Jasonette was extracted out from an actual production mobile app. I didn't start out thinking "Let's see, how do i build an ambitious platform that will change the way we do app development?" Instead, I already had a native app and started switching out its components one by one to make it JSON powered. And when you start that way, it makes 100% sense to use JSON and zero sense to use HTML. I have a lot of thoughts on this philosophy-wise but that's for another day.
As for your other questions:
Hope this answers your question!
@gliechtenstein Thank you :)
Hi I just wanted to start this as discussion about the advantages of JSON over HTML. I didn't see a faq or anything that explains why JSON was chosen over the already standard HTML format which is used for effectively the same purpose, except for web development instead of app development.
This brings up a few questions 1) Does current web development (websites with javascript and html being sent to mobile web browsers) have access to the os api? 2) If not, then why? Is it a security risk? Would this not have the same security risk?
Just to be clear I'm asking these questions, because I'm not informed enough to understand the reason behind the choice of json over html, not because I think json is worse.