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.
"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)."
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].
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.
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.
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).
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?
>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.
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.
42 comments
[ 3.7 ms ] story [ 125 ms ] threadMore 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.
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).
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.
Lisp interpreters tend to be dead simple to implement.
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...
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
I should have said:
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 :)
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 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.
So it's a bullshit title, basically.
direct link: http://jasonette.com
I pick YAML.
Nothing can beat this:
Absolutely nothing, no matter how you dress it.In general, JavaScript is becoming the new J2EE. Ambitious ideas, clueless implementations, insane complexity.
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.
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.
Like parent said, this project doesn't compile to JS. It's simply a JSON to native mapping.
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).
https://forum.jasonette.com/t/media-in-android-port/79/2
Short answer: Sort of (on iOS) and No, not yet (on Android)