How to build cross-platform mobile apps with JSON | Hacker News Reader

How to build cross-platform mobile apps with JSON

medium.freecodecamp.com

65 pointsquincyla41 comments

JSON is the new XML. Except XML was actually designed to have semantics, while similar attempts in JSON are just hacks.

In general, JavaScript is becoming the new J2EE. Ambitious ideas, clueless implementations, insane complexity.

1. OP article has nothing to do with JavaScript.

2. It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering.

3. The JS community is vast and diverse - generalisations around 'clueless implementations, insane complexity' don't make a lot of sense.

>It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering.

Its pretty anti-XML outside of node. Pure-js solutions for xml are not as great as built in features other languages provide, while JS only natively does JSON.

>generalisations around 'clueless implementations, insane complexity' don't make a lot of sense.

When you are creating languages that compile to JS and adding entire markup ontop of it along with literally hundreds of dependencies in any average project, JS has plenty of insane complexity.

> When you are creating languages that compile to JS and adding entire markup ontop of it along with literally hundreds of dependencies in any average project, JS has plenty of insane complexity.

Like parent said, this project doesn't compile to JS. It's simply a JSON to native mapping.

>1. OP article has nothing to do with JavaScript.

JSON is a format directly derived from JavaScript. The affinity for using JSON for things that have nothing to do with object serialization or simple data structures is characteristic of JS mentality.

>2. It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering.

Of course JS community is anti-XML. They don't use XML even when it makes sense to do so. And they use HTML only as a rendering layer, completely ignoring its other use (e.g. semantic document format).

Except XML has no evaluation rules and no semantics. It allows you to build languages that can be processed by third-party tools, which then give a precise meaning: for example, SVG expressions are written in XML, but the meaning is not expressed in XML.

Typo in title. Should read "How to build mobile apps in JSON." And drop the "Yes, JSON" bit.

Not sure why this was downvoted. The click-baity "Yes, JSON" is really annoying and should be removed.

More generally, the title should be corrected to the actual title, which is almost fine:

"How to build cross-platform mobile apps using nothing more than a JSON markup"

Maybe remove the click-baity "nothing more than" part, but other than that, the original title is much better than the submission title.

So why JSON of all things? When I reached the "write a full declarative program in JSON" section I was internally screaming "but s-expressions!"

can you elaborate on s-expressions?

About four paragraphs in https://en.wikipedia.org/wiki/Lisp_(programming_language)

    "The interchangeability of code and data gives Lisp its instantly recognizable syntax. All program code is written as s-expressions, or parenthesized lists. A function call or syntactic form is written as a list with the function or operator's name first, and the arguments following; for instance, a function f that takes three arguments would be called as (f arg1 arg2 arg3)."

Oh yeah, I understand that part. I was just wondering what OP meant in his sentence.

Meaning it's going far out of it's way to half-write a programming language in json rather than actually just using a lisp.

But why would you use lisp? I don't get it. No API returns data in a list format.

Lisps aren't limited to lists as data types, you can have anything you want.

Lisp interpreters tend to be dead simple to implement.

EDN (s-expressions + Clojure's reader)[1] got a lot of attention when it was announced. It looks like it's garnered some use [2]. I was hoping to find a registered mime type "application/s-expr", but there are some uses out in the wild[3].

1 - https://news.ycombinator.com/item?id=4487462

2 - https://github.com/search?utf8=%E2%9C%93&q=%22application%2F...

3 - https://github.com/search?utf8=%E2%9C%93&q=%22application%2F...

Sure. S-expressions[1] are a notation for nested data structures. They can be used to spell out data as well as code. In fact both code and data look the same when expressed using s-expressions.[2]

When the article's author describes both code and data using JSON, it sounds a little strange to me. While JSON is capable to describing nested data structures, JSON's syntax is much more verbose than s-expressions. I feel that since s-expressions have been around for about 60 years that the author should be familiar with them and address why a JSON encoding is superior to s-expressions for this use case.

1 - https://en.wikipedia.org/wiki/S-expression

2 - http://wiki.c2.com/?DataAndCodeAreTheSameThing

Although I'm also skeptical of coding in JSON, s-expressions are pretty close to a JSON subset (with the caveat that everything needs to be quoted).

  (x . (y . (z . NIL))) <=> ['x', ['y' , ['z', null]]]

The first one is the flat list (x y z); the JSON one seems to be equivalent to (x (y (z nil))).

You're right! My scheme is rusty I guess.

I should have said:

  (x . (y . (z . NIL))) <=> ['x', 'y', 'z']

In Lisp, (x x x) denotes a list which contains three elements which are pointers to the same symbol object.

Same thinking, I expect, that gave us XSLT.

Using JSON seems far more pragmatic than the mindset that gave birth to XSLT, so I don't really see the connection.

JSON is widely used and understood, easy to parse and serialise to, and fundamentally simpler than most alternatives.

You could argue that S-expressions are 'simpler' than JSON, but they didn't take off, for whatever reason - I'm not going to go into opinions on why I think that is, because that never tends to go well on HN :)

XSLT was proposed as a limited transformation language, and actually (still) does a very good job of that. And since we're doomed to repeat the past we now see various XSLT-ish languages being developed for JSON/YAML/etc, relearning all the edge cases that drove XSLT into its current form.

On the other hand, students of the past will notice that Jsonette looks awfully similar to Ant build files, which sucked. JSON/XML/YAML is a horrible way to construct general-purpose programs. Computing languages exist for a reason.

I spent a lot of time with Ant and was pretty good at it because I understood the tragically backward 'first writer wins' decision they made and had an elaborate set of techniques to work around it. That decision and the attempt to keep all conditional behavior entirely out of the build process wounded it gravely. The fact that they kept making compatibility breaking changes in minor version numbers was the genesis of my dim view of Jakarta projects. Once I started noticing the pattern I couldn't stop.

I think we are finally starting to accept that Turing-complete data is a bug, despite what the Lisp people have been saying for 50 years, and is not a feature on the Internet. Microsoft served as the poster child in the 90's.

The tension, I strongly believe, comes during debugging. When you are trying to figure out why the data doesn't look right, the less the code resembles the data being emitted, the harder it is to locate the source of the error. Templating engines get pretty close to addressing that concern, in ways that transforms or generators don't. So we keep trying to invent a better one. But once you let a little logic in, everybody wants all the logic.

Ant found the Uncanny Valley, in a way that few other tools have managed. I think I'm okay with your implication that it was actually worse than XSLT, which is saying a lot.

[edit] Ant is also the reason I shift uncomfortably whenever someone announces proudly that a tool was 'designed and implemented on a plane trip'. I'd rather have code you wrote when drunk than code you made while stuffed in a sardine can, subjected to noise levels that OSHA would have issues with, and suffering from altitude sickness. You literally designed this while your brain wasn't getting enough oxygen.

http://thedailywtf.com/articles/the-inner-json-effect

That's nothing. I can write a chess engine using nothing more than the Latin alphabet, Arabic numerals, and a couple punctuation characters. All you have to do is compose these building blocks in the right way, and gcc will take care of the rest.

I've seen so many projects like this over the years that claim that they're the one that will allow for true cross platform app development, and they've developed a simple abstraction for doing so.

I've never seen any succeed at anything more than the most basic apps.

I put more stock in projects like Xamarin or MOE (and even they aren't perfect).

I understand the sentiment, which is why I approached Jasonette with some curiosity mixed with scepticism... which I quickly turned into obsession!

The platform is incredible and I've been able to build a complex app in no time at all. Give it a try, you'll be surprised. I'm in the Slack room too if you need trouble shooting.

It is made by the guy who made TextEthan.

direct link: http://jasonette.com

A heads up for anyone wondering if this can do anything "real" on the phone (such as, you know, take a picture or access the memory card):

https://forum.jasonette.com/t/media-in-android-port/79/2

Short answer: Sort of (on iOS) and No, not yet (on Android)

The framework and approach described might be useful in some cases, but... you still need to understand CSS, HTML, and... pretty much everything about webfrontendism to meaningfully design and "build" such an app, of course (even if you do manage to cram all that metadata into a single JSON file).

So it's a bullshit title, basically.

If it can be done in JSON it can also be done in YAML.

I pick YAML.

If the idea is to reduce verbosity, I'd much prefer CSON. YAML just has way too much "magic" parsing behavior.

Not bad, a second close just behind YAML in my picks.

Nothing can beat this:

    name: Taylor Swift

Absolutely nothing, no matter how you dress it.

I prefer

    name "Taylor Swift"

which is how JSONY works (which was an experiment ingy and I put together)

Right, but the problem is YAML parsers are crazy hard to implement correctly/safely. Its spec is an order-of-magnitude more complex than JSON.

Have you read the specs for both? You should read the JSON spec. It will take you ten minutes. The YAML spec (http://yaml.org/spec/1.2/spec.html) may take you a little longer. . .

S-expressions will take you ten seconds still nobody uses them. YAML is made to simplify the lives of the reader and the writer, not the parser. Let the parser suffer, let the coder rejoice. You pick your own level of suffering, I pick mine. Deal?

What language you use doesn't really matter much when you can easily transform one into another. I think that's exactly the case with JSON and YAML.

But why ? What does it solve ? This is xml xslt alk over again.

Reply on news.ycombinator.com