Apple has restrictions on downloading executable code, which downloading a Lua script would likely fall afoul of.
It's also a potential security risk - the downloaded script could perform things other than logic and so would require sandboxing/whitelisting of commands.
Putting logic in JSON avoids both of these issues since the actual handling of the logic is performed by a client-side library.
I don't think it is at all same. You can clone a Gradle-based project anywhere (e.g. /projects), cd into that directory and run `gradle build` and it will work. There is no `GRADLE_PATH` or similar environment variable determining where all your Gradle-based projects must live.
The `src` folder you are talking about is a sub-directory inside a Gradle based project. This is entirely configurable within the Gradle build script, you can use multiple sub-directories for your source code or even the same directory as the build script if you wish. The reason Gradle uses a single `src` sub-directory by default is that it follows the Maven Standard Directory Layout.
I think most people don't understand Xamarin. Up until pretty recently Xamarin had no cross platform UI components. That is although all logic was shared, views had to be written separately for the different platforms - just like React Native.
With Xamarin Forms this has changed - you can add a Xamarin Form component and this will work adapt itself across the different platforms. The key word there is adapt - it is not like an HTML page, a Xamarin form input will look different on Android and iOS by default.
So I think your point, while valid, does not apply in any way to Xamarin!
You could this for your own libraries, but I would strongly recommend against doing this for a public lib if you want traction (e.g. if you are making a bunch of SDKs for your APIs) - in this case you should publish your lib in the most popular language(s) for the platform(s) you are targeting.
Lenio's core product lets you micro-donate as you spend through your bank or credit card provider. You choose the charities you're interested in, a monthly limit and how donations should be triggered. We calculate and take donations in micro-amounts as you spend.
Some of the challenges involve: rich transaction processing and analytics at the largest scales (we work with financial service providers that serve multiple banks), top-grade security, data-mining and analytics for key spending and donation insights and rich content delivery.
We're looking for a lead developer (Java/Scala, front end experience), a dev/sys-ops lead (PCI experience a major plus), a number of senior backend/full-stack developers and a senior front-end developer (NodeJS, Angular or React experience a plus).
We use Java (and a little Scala), NodeJS, ES 6, Docker, Kubernetes, Elasticsearch, AWS & Heroku for internal infrastructure, HipChat and Hubot for ChatOps all linked up with NewRelic, PagerDuty and StatusPage.io. We believe strongly in clean code, automation, continuous delivery, and infrastructure-as-code.
We offer competitive salaries, options, full private health-care, £1000 annual training budget for conferences and courses and from January an employer matched pension scheme.