Jasonette – Native App over HTTP(jasonette.com)
jasonette.com
Jasonette – Native App over HTTP
https://jasonette.com/
57 comments
> What's curious is why there isn't a standard/de-facto standard (like JSON based one maybe?) for UI layouts that has emerged
It hasn't emerged because nobody has done it. Nobody has done it because it's unbelievably hard and involves a lot of painful code of the sort that is not fun and therefore that people must be paid to write. Nobody has been paid to write it because nobody pays for dev tools and it's not in the best interest of any platform vendor to commoditize platforms.
It hasn't emerged because nobody has done it. Nobody has done it because it's unbelievably hard and involves a lot of painful code of the sort that is not fun and therefore that people must be paid to write. Nobody has been paid to write it because nobody pays for dev tools and it's not in the best interest of any platform vendor to commoditize platforms.
You could say all those things about react native or other frameworks.
Like any reason why Airbnb can’t open source their solution? Seems battle tested.
The thing is that many people HAVE solved this.
Like any reason why Airbnb can’t open source their solution? Seems battle tested.
The thing is that many people HAVE solved this.
Your correct this is hard, but I have to disagree that it involves painful code. Declarative UI in all 3 clients is a major enabler for doing this in a nice way.
Some context - https://github.com/MobileNativeFoundation/discussions/discus...
(Edit to add context)
Some context - https://github.com/MobileNativeFoundation/discussions/discus...
(Edit to add context)
I'm one of those people and in my opinion it would be hard to make a solution that fits all. The reason why it works for us is because we control the design system and we know the needs of our app and users. It works because it's somewhat bespoke to our use-cases.
It simply is not possible to represent the realm of all possible native UIs within a common json schema. We can do it because don't need the realm of all possible UIs. We need a 20 different elements recombined and reused across all our screens.
Which is also a strength because now we can leverage our limitations into delivering a consistent experience across our app.
It simply is not possible to represent the realm of all possible native UIs within a common json schema. We can do it because don't need the realm of all possible UIs. We need a 20 different elements recombined and reused across all our screens.
Which is also a strength because now we can leverage our limitations into delivering a consistent experience across our app.
But that’s an argument about style. No reason why an opinionated version couldn’t come out I guess.
If you have a React Native adapter on all platforms, why not just use React as your standard?
That was basically AWT and then SWT in the Java world.
It can work for simple stuff. For anything more complex the underlying widgets are too different, you have to go with the lowest common denominator and the results just aren't good enough.
It can work for simple stuff. For anything more complex the underlying widgets are too different, you have to go with the lowest common denominator and the results just aren't good enough.
I was convinced Apple review guidelines state the core functionality of the app must be in the bundle that is reviewed and they would reject it if it's loaded mostly over http. Can see where they are coming from given they could review the app as a calculator app that then turns into a porn app post review.
Did the author just get lucky with the review process?
This is the guideline I'm referring to: https://developer.apple.com/news/?id=09062019b
Did the author just get lucky with the review process?
This is the guideline I'm referring to: https://developer.apple.com/news/?id=09062019b
I've wondered about this and products like expo 'over the air' updates for React Apps etc. In theory does seem to infringe on these guidelines but are somewhat common in the iOS and Android eco-systems at the same time. I suspect an element of 'Don't ask don't tell' is being played out.
I also recall another guy -- who I think was openly advertising it as way to get around app store guidelines got taken down. JSONRoller or something my memory escapes me.
I also recall another guy -- who I think was openly advertising it as way to get around app store guidelines got taken down. JSONRoller or something my memory escapes me.
Wouldn't be too hard to include package the JSON with the final product or generate code though.
You can pack the JSON into the renderer if you want. The real meat of the app is the renderer itself, though. For example, you could put the menus and controls in an embedded JSON and then have the app fetch the data view from a server. It's not like your average Twitter or Facebook can show a whole lot without Internet access, so I don't think Apple will reject any apps that don't work without internet access. Add some certificate pinning for good measure and Apple will have to test on rooted iPhone to get access to the data being exchanged, and I don't think the testers really care enough about that stuff anyway. They'll much rather complaintthat you link to your website in a way that angers the Apple gods and other such low hanging fruit.
There are plenty of apps out there that are basically this but with custom logic. Lots of other apps are not much more than a webview with a custom "can't contact the servers" screen.
There are plenty of apps out there that are basically this but with custom logic. Lots of other apps are not much more than a webview with a custom "can't contact the servers" screen.
I suppose it's technically user-generated content, so it's fine? i.e. the app developer couldn't possibly know at review-time what it would be, and that run-time stuff is only distributed (in theory) to the person(s) that generated it; it isn't 'the core functionality of the app'.
They are eventually taking it down, for sure, just a matter of time…
Every reviewer is different
I wouldn't be so sure. Ionic has a commercial product, AppFlow, which is their "update over http" solution. It allows for running arbitrary code without app approval, and they claim it is compliant. AirBNB and I'm sure plenty of other companies use "server driven UI" which is similar to this. Almost every app will also use feature flags in some way. Or could even just check if the account is "[email protected]" and show different content, theres not a good way to prevent it.
> Or could even just check if the account is "[email protected]" and show different content, theres not a good way to prevent it.
One would hope they'd do their app testing with regular user accounts designed to blend in and not anything tied directly to Apple. Likewise for other well-known forms of obfuscation like changing behavior based on the system date so that it appears fine until the review period is over—though the app could simply refuse to work when the date doesn't match the server, if there is a server component, and that wouldn't be particularly suspicious.
The main deterrent to trying any of that, of course, is that it will get not just the offending app but the entire developer account banned. Those accounts aren't free. Moreover, uploading an identical or even substantially similar app under another account would be recognized immediately, so you'd have to start over from scratch.
One would hope they'd do their app testing with regular user accounts designed to blend in and not anything tied directly to Apple. Likewise for other well-known forms of obfuscation like changing behavior based on the system date so that it appears fine until the review period is over—though the app could simply refuse to work when the date doesn't match the server, if there is a server component, and that wouldn't be particularly suspicious.
The main deterrent to trying any of that, of course, is that it will get not just the offending app but the entire developer account banned. Those accounts aren't free. Moreover, uploading an identical or even substantially similar app under another account would be recognized immediately, so you'd have to start over from scratch.
Creator Ethan vanished a couple years ago. Replaced with:
https://jasonelle.com/
https://jasonelle.com/
Interesting. This has some _why vibes.
Looking at this announcement: https://github.com/jasonelle/jasonelle/discussions/120 I don't think that's much of a replacement either. It's a cool concept, but it seems like a bad system to use for a new app.
This is really interesting to me.
At my job I maintain a very similar iOS render. Our app is built on the exact same principles, we have 3 native renderers (iOS, web app and Android) that consume the same JSON and generate native UI at runtime.
The schema even looks similar and as far as I know no one was aware of this project when this was built.
There are major disadvantages to this approach of course but there are also many many advantages.
The schema even looks similar and as far as I know no one was aware of this project when this was built.
There are major disadvantages to this approach of course but there are also many many advantages.
This is precisely how our product works too.
We've been using the same UI data contract for the last 7 years, which has allowed us to survive several different platforms without adjusting a single line of business logic or UI code.
We've been using the same UI data contract for the last 7 years, which has allowed us to survive several different platforms without adjusting a single line of business logic or UI code.
That's awesome. If you ever want to bounce ideas you can reach me at joao@$myusername.me
What are the major disadvantages?
This looks really cool, nice! Neat that it’s already used in App Store apps too. And I like that it exposes native things like camera, will be interesting to see how that sort of thing works.
I noticed a couple of issues on the home page, in case the author is here:
- when I click documentation it says I’m viewing an old version, if I click OK to view the new version it’s a 404 (https://jasonelle.com/docs)
- Try Now links to an empty Heroku page, there’s a button to “build something amazing” but it just links to the Heroku home page
- the YouTube video near the top is private
I noticed a couple of issues on the home page, in case the author is here:
- when I click documentation it says I’m viewing an old version, if I click OK to view the new version it’s a 404 (https://jasonelle.com/docs)
- Try Now links to an empty Heroku page, there’s a button to “build something amazing” but it just links to the Heroku home page
- the YouTube video near the top is private
See also https://hyperview.org/
Interesting their last blog post was the month before Apple clamped down on this type of app, see https://news.ycombinator.com/item?id=31502241
Oh yeah, if there was a way to send markup to the browser and have the browser render a UI for that. I wonder why nobody thought of that as of now ... oh. wait. ... ah we want "native" components. Yea. html only had "native components" for a long time, too ...
so - html as json without css and a richer component palette?
so - html as json without css and a richer component palette?
I think that’s a very understandable reaction, and I had the same initially. But, there are upsides to using a proprietary format over HTML:
1. Encoding behavior in custom components without resorting to Turing complete languages (JS), such that custom components (eg DatePicker)
2. Dependencies between components, like rules, become possible: If textfield A is empty, disable button B.
3. Access to native APIs that are not (yet) implemented in browsers.
1. Encoding behavior in custom components without resorting to Turing complete languages (JS), such that custom components (eg DatePicker)
2. Dependencies between components, like rules, become possible: If textfield A is empty, disable button B.
3. Access to native APIs that are not (yet) implemented in browsers.
There is already Jsonnet the data templating language: https://jsonnet.org/
My first thought when I saw the title too.
I thought jsonnet was pronounced “J sonnet” like poetry, but a friend of mine has always pronounced it like the title of this new tool. He’s an excellent English speaker but it’s not his first language, so I assumed that was related to the different pronunciation. It sounded nice and I never misunderstood the subject, plus he’s excellent at dissecting complex jsonnet templates, so I never felt the need to point out the difference.
Now your comment had me wondering if the alternative pronunciation is more widespread than I realized, and perhaps even the “correct” way, so I looked it up… must be a common question because it’s right there on the bottom of their home page, haha
> The name Jsonnet is a portmanteau of JSON and sonnet, pronounced "jay sonnet".
I thought jsonnet was pronounced “J sonnet” like poetry, but a friend of mine has always pronounced it like the title of this new tool. He’s an excellent English speaker but it’s not his first language, so I assumed that was related to the different pronunciation. It sounded nice and I never misunderstood the subject, plus he’s excellent at dissecting complex jsonnet templates, so I never felt the need to point out the difference.
Now your comment had me wondering if the alternative pronunciation is more widespread than I realized, and perhaps even the “correct” way, so I looked it up… must be a common question because it’s right there on the bottom of their home page, haha
> The name Jsonnet is a portmanteau of JSON and sonnet, pronounced "jay sonnet".
that's quite interesting... it is like a naive lisp on json grammar and syntax
Facebook Lite used/uses? a similar architecture and brings the Facebook experience to mobile in under 1MB app (at the time it was released).
* https://engineering.fb.com/2016/03/09/android/how-we-built-f...
* https://www.facebook.com/MetaforDevelopers/videos/facebook-l...
* https://engineering.fb.com/2016/03/09/android/how-we-built-f...
* https://www.facebook.com/MetaforDevelopers/videos/facebook-l...
I built my last mobile app with Ionic, every time I created a new page, new endpoint sending JSON i was wondering why I wasn't sending just Ionic html from the server, or that the JSON contains the UI.
Now even to a small UI change I need to redeploy the app to app stores, which is ...tiresome.
A pity I didn't know this way before.
Now even to a small UI change I need to redeploy the app to app stores, which is ...tiresome.
A pity I didn't know this way before.
I recall this from years ago, and had the Jason app on my phone for a while. The author[0] doesn't seem to have been active on HN or Github for 4 years or so, but a few interesting things came up over the course of a year, year and half. Some of the URLs from then now seem stale, but the code is still available. I'm a BE dev but was very taken by cell.js[1] and managed to throw something together really easily with it, which I enjoyed.
[0] https://news.ycombinator.com/user?id=gliechtenstein [1] https://github.com/intercellular/cell - celljs.org from the Show HN no longer works
[0] https://news.ycombinator.com/user?id=gliechtenstein [1] https://github.com/intercellular/cell - celljs.org from the Show HN no longer works
This looks similar to what I'm doing with DocUI, which sends JSON over HTTP to a Flutter engine. https://nexusdev.tools
I'm working on getting a release out in the next month or two (Open Source).
I'm working on getting a release out in the next month or two (Open Source).
Which licenses will DocUI have? Is your code published anywhere?
Verily, JSON by 2020 is what XML was by 2000: the posh way to describe any structure at all.
Isn't this a dead project?
Yes. Successor is https://jasonelle.com/
Last commits are quite old. Guess it’s also not maintained
This is really weird, I haven't thought about Jasonette in years. I used to speak to Ethan quite a lot, and because I said he wanted to contribute (I was quite young at the time), he had me start building a "registry"[0] for "extensions" to Jasonette (which IIRC were essentially non-core native modules for the framework)
[0] https://github.com/Jasonette/jr
[0] https://github.com/Jasonette/jr
Another option that it is worth exploring: https://hyperview.org/
I feel I have seen something like this in GTK-land.
I don't mean X11, maybe I'm thinking of the way to GTK-ify bash scripts.
I don't mean X11, maybe I'm thinking of the way to GTK-ify bash scripts.
The idea is very interesting, I wish this (and its successor) wasn't dead :( I want to get into iOS for personal projects but don't want to touch macOS / xcode with a ten foot pole.
Having JavaScript support as well would be amazing (but I presume that's breaking some app store rules).
Having JavaScript support as well would be amazing (but I presume that's breaking some app store rules).
Quick note: the video on the homepage is private and can't be viewed.
> When not to use: ... You have a team of native android and ios developers who can build something with other frameworks like react native
So this will be even less native of an experience than React Native.
So this will be even less native of an experience than React Native.
I wonder if they made any thought on security. Things like Turing completeness, data stealing, privacy violations etc.
I think it is however a good thing for prototypes and internal company tools.
I think it is however a good thing for prototypes and internal company tools.
Interesting concept, I can see a lot of projects that would benefit a lot by migrating to an approach like this one
Broken video and images on the page doesn’t give me “peace of mind” about using this software.
Not sure how viable or practical this is in real life, but the idea is really cool
I don't know about this exact implementation, but Airbnb does use server-driven UI for parts of their mobile apps.
https://medium.com/airbnb-engineering/a-deep-dive-into-airbn...
https://medium.com/airbnb-engineering/a-deep-dive-into-airbn...
It's practical. We have 3 client apps serving tens of thousands of daily users based on a very similar engine (built in-house).
I want to see this for Desktop OSs IE Windows and Linux
is this just a throwback or has someone found Ethan?
It's clear that in general, we are all sick of writing a bunch of bespoke code and maintaining multiple platforms, and are seeking smart layers of abstractions over native widgets. It's a tale as old as time.
What's curious is why there isn't a standard/de-facto standard (like JSON based one maybe?) for UI layouts that has emerged, with a React Native adapter for it.
We are trying to solve this problem too with the same approach (the framework isn't the product, it's just because we don't want to spend too much time building custom Mobile components for our product).
It's not like people haven't tried. Just Microsoft has probably a half dozen of these. MAUI, WPF, etc.
Again, just curious that at least one format hasn't emerged for it.