Show HN: Create instantly shareable native app with a single JSON markup | Hacker News Reader

Show HN: Create instantly shareable native app with a single JSON markup

jasonclient.org

165 pointsgliechtenstein42 comments

Hi HN, I've worked on several apps in the past couple of years, and found that it takes too much effort going from having an idea to building an app and having the world use it. Also most cool ideas will never turn into an app because building an app is not a simple 5 minute thing.

I wanted a way to have an idea, turn it into a fully functional native app, and share it with the world, all in the next 5 minutes, as quick and easy as writing a blog post. That's why I built Jason.

Basically Jason lets you build a native interface to display and interact with any data format (csv, rss, html, json), any website, any API in any way you want, simply by writing a JSON markup and loading it. There's no need for compiling, building, deploying, or anything like that.

It's like a browser but instead of turning HTML into a web page, Jason turns your JSON into a native app. Everything from defining elements to styling to executing actions is described in a single JSON markup.

Please let me know what you think, or ask any questions. Thanks!

I wrote something similar (simpler) a few months ago. It used Qt but it was supposed to be client agnostic by providing native wrappers. Anyway, it was a fun project but I decided to not publish it because it was a simple prototyping exercise.

I believe something like this will kill the browser.

Neat! I found the name slightly confusing, though. Do you have any concerns about JSON being pronounced the same as "Jason"[1], thus making some conversations slightly confusing?

[1]: https://www.quora.com/How-do-you-pronounce-JSON

Thanks for pointing out. The naming was intentional, but yes you're right it can be confusing sometimes. But I really like the name as it personifies the term. I'll think about it if this becomes a serious problem

Is it open source?

Can it be used to create io forms for a postgres database? Preferably to functions (aka stored procedures) not direct to table. JSON arguments of course would be no problem, since postgres can natively parse such.

Wouldn't you still need a web server? Assuming we still need some sort of web app running on a web server, I think you can expose any DB action you want as an API endpoint and hit it using http://www.jasonclient.org/doc/#2-network-request Please let me know if I misunderstood your question.

Very cool. I wrote a similar framework while I was working at a previous company that translates XML into iOS views. From my experience, this might not take off for regular native-app building, but it's invaluable in usecases where there is a base application and a high amount of configuration between various enterprise clients. Good luck!

Thanks! Can you share why you think it may not be for regular native-app building? Would love to hear your experience, would be extremely helpful for making decisions.

Kudos for this, especially for generalizing from real apps. But I have criticisms.

Declarative approaches are appealing, but lack sufficient flexibility for general use. BTW arguably, browsers are native apps configured by html/css/js.

Html templates in json is unnecessarily confusing. It's unfamiliar and untooled.

Unfortunately, json paths are inadequate for api's in general. They can't extract data from within text, combine, compute, nor use complex sequential api queries to get the data you need. You could add all this, but coding in a data format is awful, compared with a designed syntax like javascript.

Still, it is appealing to have just "one json". Maybe people can live with html in json for that. If you also design the backend (or it's an isomorphic frontend to an existing api), data extraction by path should be OK.

Thanks, can you tell me a specific use case example you think would be hard to implement this way? Hopefully I already have implemented it.

I wouldn't say they're that hard, just awkward for the user. I'm not sure which part you mean, so I'll answer for both.

html templates in json: people accustomed to html have an extra layer between them and the result. It doesn't look like the result, making it that little bit more awkward to use. Tools don't know the json version of the html (e.g. editors with syntax highlighting; previewing the result; authoring tools).

Examples of extracting data: getting part of a date from a date string (or, eg date from date-time string). Also, first name out of a fullname string. Probably solve this class just with a regexp substitute function.

'Joins' are pretty common, where you get data from one part of an api (eg ID of a person), then use this to lookup other data. This could all be in a single json; or require different api calls - even between different api's.

Look, these features aren't hard to implement - and I wouldn't be surprised if you had them already. You could always accrete features as you go, like PHP did - ugly yet useful.

But my objection is that representing code in a data format (json) is very awkward to use. The worst examples are in XML (eg XSLT, ant java build system), but also applies to json.

If you can make it simple enough, for common cases, it's probably workable.

BTW have you seen jq? Gives a taste for features that end up being needed for handling json. And you could possibly just embed it, for arbitrary json processing... https://stedolan.github.io/jq/

BTW1 the role of this is not that different from early PHP - I wonder if embedding code in the template would work here too?

BTW2 Android already specifies UI's declaratively with a data format (XML), though it doesn't read api's etc, and it's IMHO awful to use.

I think you're looking for this http://www.jasonclient.org/doc/#template-reference

you can use javascript expressions inside templates so everything you mentioned is possible using javascript.

Here's an example of javascript usage inside a template http://www.jasonbase.com/things/xLZ/edit

Here's an example usage of a template that iterates through a data fetched from network request http://www.jasonbase.com/things/a8b/edit

Just to be clear, this is not HTML and has nothing to do with WebView. The JSON is used to directly manipulate native elements like UIStackView, UITableView, etc. and that's the whole point. Hope this makes sense...

Thanks for the clarification - I knew that, but somehow forgot. Probably because they look similar, following similar function (i.e. layout).

Yes, escape to javascript addresses my concerns.

Good!

This is awesome. I've been dabbling in a similar concept using CouchDB. Have you thought about using something like CouchDB to enable easy master-master replication of data between users? Also, is any part of this open source? Thanks!

Can you elaborate on what you mean by master-master replication between users?

As for open source it's not open source at the moment but it's one of the options I'm considering. I just wanted to get it in front of more people as quickly as possible so I can make better decisions based on reaction. If you're interested in how this will progress, please join the slack channel to stay in touch http://textethan.us8.list-manage.com/subscribe?u=54e23b3fe61... or you can also follow me www.twitter.com/gliechtenstein to hear about it.

Sorry, I'm getting a bit too buzz wordy. What I meant was that CouchDB is unique in that it can be run as a peer-to-peer database. Master-Master is when a database can have two authoritative sets. Compare that to Master-Slave where one server is the authority and the other is just a redundant set.

CouchDB is a JSON document store so it could easily store these JSON apps. CouchDB has an embedded Javascript runtime that enables you to execute arbitrary Javascript on the server to perform queries (map/reduce) or perform transforms on JSON. For example, I can write a SHOW function that can take one of your JSON apps and invert all the colors. There's a lot of interesting use cases for this type of set up. I would love to explain more to you if you're open to these kinds of ideas.

Wow i haven't used couchdb before but that sounds really cool. By the way Jason has a way to dynamically run actions on the frontend side (for example to change colors http://www.jasonbase.com/things/xLZ/edit) but I think there may be something really interesting there if you can also integrate with backend, I'm interested :)

I subscribed to your slack channel. I'll hit you up in a bit!

Very cool! What lead you down this path? This is not too far from creating a client using the web view container and letting users specify urls to their "apps" with perhaps certain JS hooks or CSS classes being required of apps to be rendered/used correctly in your client. Take one step further and you could just build a browser and user apps are any valid url with no restrictions. You can see where am I going. Just wondering about what led you to your idea?

I just commented below to another question that may answer your question https://news.ycombinator.com/item?id=11884901

I think HTML/JS/CSS have become too powerful which is a good thing, at least on desktops. But when we bring that power onto more specialized devices such as our smartphones it works as weakness instead of strength. For example, people may love super rich interactive websites on desktop but it becomes pretty much useless on our phones, which have small screen. But browsers still need to ship with these features because that's what they're supposed to do--follow the web standards.

I am actually working on a blog post to talk about this in more detail, probably will publish in next couple of days. Please follow me on www.twitter.com/gliechtenstein if you are interested.

As for how this was conceived, I've been working on quite a few apps last couple of years, some I released some I didn't. One of the apps I'm working on is http://www.textethan.com and I got frustrated how I have to rebuild everything whenever I had something to change, so I built everything into a markup. Then when I looked at the end result I saw something that can be potentially very powerful so I decided to extract it out into its own app. Hope this answers the question :)

I understand your complaint but I disagree with your solution. As much as I hate working in html and js I don't think fragmenting the web like is the right solution. My ideals are much more aligned with something like Google's Accelerate Mobile Pages.

I'd be a lot more interested in a project that uses AMP html to build a native app over a custom json spec.

This is pretty cool, I'd love to see a way to save an app to your homescreen somehow (although, I'm not sure how iOS would let that happen) or perhaps a way to produce a pre-bundled jason+app—would that go against your objectives?

See the Workflows app. Would the way they do it in that app work?

Looks neat but what about security? Can the json be configured in a way that compromises the data stored on the device. Aren't you basically allowing Jason agent to run any custom code?

Each page is sandboxed and it displays an intro page describing which device features the next page will access when you run it for the first time (or when there's a code change even if you had it favorited earlier). Also you can look at the raw JSON to see what's inside before opening. But yes I think security is important and will be one of my top priorities going forward.

Cool, you made Ext.js

It doesn't compile or build and there's no deployment because it loads like a web browser and renders the app instantly. It's not javascript. Finally it's not even based on webkit. It's all based on UIStackViews/UITableViews/UILael/UIImage/etc. You're basically remote controlling native elements and calling native functions just by scripting in JSON. So I guess it's not really Ext.js

I thought dynamic loading of functionality like this was against the App Store rules? Or did they ease up on that particular limit over the years?

Loading JavaScript (of which JSON is a subset, of course) has been explicitly permitted for a long time now, as long as it's downloaded and interpreted by the built-in WebKit engine.

Phonegap/Cordova has a developer app that works similarly, allowing you to hot-load code updates without forcing you to reinstall the entire app.

You're right, to be clear, in case of Jason it's not even "downloading code" because all the native code is already there on the app itself. Instead what gets downloaded is a flat JSON text, which then gets interpreted into calling the APIs available on Jason.

Thanks for bringing up Phonegap/Cordova so I can describe the difference. In case of Jason it directly accesses native elements like UIStackView, UITableView, UILabel, UIImage, etc. because I manually built everything from parser to renderer to do exactly that. You are basically remote controlling these native elements and calling native functions by scripting with JSON instead of writing objective-c code.

I feel like a lot of people on this thread thinks it's based on webkit, which is understandable since a lot of people claim to be native when they're just a native wrapper for HTML5. I think I need to clarify this point in future pitch.

Yes, that would be worth some clarification. I made that assumption myself. It's my fault for not having read carefully, of course, but if I did it, others probably will too. :-)

Really cool, how is it unique in terms of what it can do, compared to a regular web browser?

1. It's native. Doesn't matter how you package a website, it still uses an HTML/JS/CSS engine to let you interact with it. Jason lets you effectively build a native app without actually building an app. The JSON markup is just an instruction to remote control native elements and native functions directly.

2. it's JSON based, it's meant for interacting with APIs, not a website. Websites don't work well because html/js/css have evolved to become something of monstrosity--which is both good and bad.

3. It assumes session. It assumes that you will be the sole user of the app, which browsers can't do for many reasons. So it has authentication/key management system built in.

4. More coming soon: This is just a first version, I intentionally cut down on many features I could have implemented because I wanted to see what people think first. I have a couple of production apps from which I extracted Jason. For an example check out www.ethan.fm It's running on Jason.

By native, do you mean uses native elements, or simply loads things in a webview? I don't know how many people consider that truly native if that's the case.

It's completely native and does not even touch any webview. Here's a related answer I posted elsewhere on this thread https://news.ycombinator.com/item?id=11888516

Reminds me of Coldfusion (XML as programming language)

Is there an Android version too?

I've started out with iOS as a minimum viable product but my goal is to expand to all kinds of other platforms, and android is of course the top priority, I made all design decisions assuming that I will build an android version.

If you are interested in staying in the loop about the android version please follow me on twitter www.twitter.com/gliechtenstein (I didn't get a chance to set up any mailing list or anything yet) Thanks!

Awesome, would love an Android version.

Great to hear! I honestly wanted to get the first version out there as soon as possible because you never know if people would want something like this, I know now!

Isn't your Slack channel link going to a Mailchimp list subscribe form?

Reply on news.ycombinator.com