Almost the entire app was written in Javascript, with JSON-based configuration and data storage. The following components were written and/or configured with Javascript:

• Most server-side scripts, all unit tests, all build tools, etc. were driven by NodeJS.
• ExpressJS served as the 'backend' server framework.
• MongoDB (which stores essential JSON) was the main database.
• MongooseJS was used as the main ORM for communicating with the database, with KnexJS used for certain edge cases.
• MochaJS, ChaiJS, and ExpectJS were used for unit testing.
• Frontend builds were done with Gulp and Webpack.
• Package management was done primarily with npm - with a few exceptions that required the use of Bower (also configured with JSON).
• "Templating" was done with Javascript dialect JSX.
• The frontend was build primarily with ReactJS (as the View) and Redux (as the Controller / Store / frontend model).
• Configuration was done with json files.

The only notable exceptions were the use of SCSS (augmented by Compass) for styling, Bash for a few basic 'system chores' and CLI utilities required for development of the app (most notably git and heroku's CLI interface), and a bit of custom SQL for locations where the ORM extractions leaked (the app is DB-agnostic, but a bit of SQL was required to fill gaps in the ORMs when interfacing with Postgres).

Basically, the trajectory was we had our iOS app, which started out native, right? It started as a native app, and then we realized you have to go through a review process and it’s slow, and at a very early stage, it made sense for us to make it a wrapped web view. Basically, the app would open, and it would be a web view inside of it that we could iterate on quickly and change very rapidly and not have to wait for app store view process to change it. It wasn’t totally a native experience, but it was as actually a pretty good experience and lasted for a very long time and was up until recently the foundation of our current mobile web experience, which is different from our app situation. So for a long time, basically, our app store iOS Instacart app was a wrapped web view of just our store, a condensed version of our store, which meant that we could add things. We could change sales. We could change the formatting. We could change the UI really fast and not have to worry about the app store review process.

This all changed about a year ago, I would like to say, at which point it became a totally native app. We felt comfortable enough with the product and all the features that we made it a native experience and made it a fully featured app.

Read more on how to extend the OutSystems UI with Javascript here.

OutSystems provides a very simple to use AJAX mechanism. However, developers can also use JavaScript extensively to customize how users interact with their applications, to create client side custom validations and dynamic behaviors, or even to create custom, very specific, AJAX interactions. For example, each application can have an application-wide defined JavaScript file or set of files included in resources. Page-specific JavaScript can also be defined.

This GNU/GPL licensed Javascript library allows you to draw complex organizational charts that can't be drawn using Google's tool or equivalents. Orgchart structures are specified with JSON and can be generated on-the-fly by server-side scripts and databases. Events can be attached to clicks over the boxes. Multiple options can be defined; look at the repo for examples. This 1300-code-lines software component with contributors from 8 countries (and others for which I have to integrate their works) appears in the first page of Google Search results when searching for "Javascript Organizational Chart Library".

JavaScript gets a bad rep, quite undeservedly so in my opinion. Today, JS is closer to functional languages than to the traditional-OO languages, and when used as such provides a great development experience. The pace of development is just picking up with transpilers like Babel making future advanced language features available to the masses today. At Cloudcraft.co, we write 100% of both the front-end (with React) and the backend (with Node.js) in Javascript, using the latest ES6 and even some ES7 features. This is not your grandfather's Javascript!

The application front-end is written in JavaScript (ES6). We originally selected it over TypeScript because many library typings at the time were still flaky and the transpilation time was slow.

We are now re-considering TypeScript because 1) the tooling has improved significantly, and 2) and the root cause of the majority of our front-end bugs are related to typing (despite having PropTypes).

While the majority of our stack is now using Swift, we still love Objective-C in many cases, especially low-level software manipulation, where it's just easier. It doesn't hurt that a lot of iOS/OS X Libraries out there are written in it either.

We like to go native with iOS development, and Objective-C has been the only game in town until recent introduction of Swift. We're keeping an eye on Swift, but we aren't giving up on the [old way:to do:things]!

Attitude Quotes Whatsapp from the DailySMSCollection

PrometheanTV provides SDKs for IOS devices including support for the Objective-C language.

The central business logic and ETL engine is written in Erlang.

Very nice programming language, used for backend integration.

foundation VM for phoenix framework

Cowboy web server serves content

Custom plugins for ejabberd