Jasonelle v3 - QA, Ideas and Comments

[coderofsalvation]

Hi,

I read the ideas for jasonelle v3, especially the idea of tightcoupling javascript.
These are just some thoughts, based on my memories & perception of jasonette and talks with Ethan.
You can disagree or agree, both is fine.

And no, I'm not Ethan ;)

I remember Ethan introducing me to the rule of least power.
In that spirit, jasonette was designed as an app dataformat (json) with some additional template-utilities to map over data, and transform it.
I remember that proposing javascript was one of my first suggestions, because it felt much easier to just write some javascript instead of learning a json templating logic.
However, this would make the dataformat much less portable, and would force jasonette (and its apps) to play catch-up forever with the ongoing javascript updates (ES3..ES10 and so on).
Also, it turned out to be already possible by writing a jasonette app which runs in an JS-runtime like cell (http://www.celljs.org/) inside a webview.
Cell was an example, and likewise anyone can write a jasonnette renderer in react within an hour.

Make no mistake, adding javascript to the spec, also forces all jasonelle runtimes to include a fullfledged ES runtime, which introduces ES version-issues, and rules out the possibility of running it on limited devices.
Anyways, I guess my point/request is: javascript doesn't really belong in the v3 dataformat, just like javascript does not belong to HTML (eventhough it defaults to javascript, the script-tag is a generic scripting tag which also supports other languages).
If javascript is an itching topic, I would opt for an highlevel successor of celljs in the form of an batteries included HTML5 runtime (jasonelleJS e.g., which could use https://framework7.io under the hood).
Restricting the dataformat to data & transformation-hints would make the dataformat last longer.

[clsource]

Thanks @coderofsalvation for your thoughts.

Let me share some ideas and clarifications.

1 - Will this change ditch the spec? : No.
2 - Will this add Javascript to the Spec?: No.
3 - ES runtime would be required ? At least in iOS ES runtime is mandatory for executing non native Objective-C, Swift Code. The current implementation in both Android and iOS use ES to execute complex login inside templates {{ }}.

My current idea is that the spec should not be coupled with a specific language. It can be implemented in JSON or ES or Python or any other language as long as you follow the designated components and structure it would be fine. You can use any execution environment like ES3, ES5, ES6 and the spec implementation can be followed.

What @gliechtenstein did was to implement the spec in a JSON like DSL templating language.

The current direction is making experiments to test if the same Spec can be applied without JSON restrictions.

I´m open to ideas and suggestions though, nothing is sealed and final.

[vini-brito]

Perhaps if we stick to fundamental JS then it will remain easier to write. Just throwing an idea.

[vini-brito]

Or we could create a visual interface builder for it. I mean, the same way Bubble.io works. I'm very proficient with Bubble too, and also am developing a visual interface for Jasonelle as a plugin in there, however Bubble is proprietary. Everyone can make visual connections, think of MIT Appinventor, Node red, Bubble.io, Thunkable, Adalo, Scratch (for kids!) and the likes.

Even kids connects blocks.
JSON is already "blocky", so it won't be a huge leap in the logic behind it.

I'm already writing Javascript functions that will map visual blocks inside Bubble to Jasonelle's JSON structure, so we'll likely be able to reuse that in the form of a JS library that can be coupled to any interface able to call Javascript functions.

Not saying that this should replace everything else, but if we want a non corporative language to write native apps, visual is a certain shot. We could even prototype this end-user interface as an app in Bubble to learn from that and then set to build our own interface.

I say corporative in the sense that a language requires lots of effort to make something and is essentially a product for teams of specialized developers, for example React, which is contrary to the train of thought we have here.

[coderofsalvation]

Hm, that is a very interesting idea. That would definitely increase adoption for non-programmers / multidisciplinary teams, while the whole stack remains fully open. Potentially it could commoditize bubble's / Google's appmaker's underlying (closed) dataformat. I have to go now, but I'm definitely going to share more thoughts on this.

…

On Mon, Jun 22, 2020 at 9:44 PM Vinicius Brito ***@***.***> wrote: Or we could create a visual interface builder for it. I mean, the same way Bubble.io works. I'm very proficient with Bubble too, and also am developing a visual interface for it as a plugin in there, however Bubble is proprietary. Everyone can make visual connections, think of MIT Appinventor, Node red, Bubble.io, Thunkable, Adalo, Scratch (for kids!) and the likes. Even kids connect blocks. JSON is already "blocky", so it won't be a huge leap in the logic behind it. I'm already writing Javascript functions that will map visual blocks inside Bubble to Jasonelle's JSON structure, so maybe we'll be able to reuse that. Not saying that this should replace everything else, but if we want a non corporative language to write native apps, *visual* is a certain shot. We could even prototype this end-user interface as an app in Bubble to learn from that and then set to build our own interface. I say corporative in the sense that a language requires lots of effort to make something and is essentially a product for teams of specialized developers, for example React. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/jasonelle/jasonelle/issues/88#issuecomment-647733517>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABL6ZEC434DI256S5XK7F3RX6YABANCNFSM4OEKUPLA> .

-- Léon /COMPANY /WEBSITE /MOBILE /LOCATION /COMPANYNR. /TAGS van Kammen 2WA Labs & Consultancy 2wa.isvery.ninja/hello +31 20 3699836 Holland, EU, Galaxy 12B 08124656 Creative Technologist, New Media consultancy, Tech concept design, driven by open source & lots of coffee. <https://www.linkedin.com/in/leonvankammen> <https://github.com/coderofsalvation>

[clsource]

Ok. So here are some thoughts for future versions.

• Keep the JSON format. But mainly as a "low-level API". Implement https://github.com/mudgen/webscript to have a more user-friendly declarative way of creating the apps.

• Define the standard as a slim core. Only the bare minimum. All the other components (buttons, labels, text, etc) would be "extensions". Jasonette then would be an example project with common extensions, but the core would only be focused on Fetching, Parsing and Executing the JSON. The idea of this core is that could be used in any new platform in the future. iOS and Android will use this core.

• Improve the codebase by using Clean Architecture, Desing Patterns, TDD, DDD, and other good quality software techniques. Use Kotlin for Android and Swift for iOS.