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).

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

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).

Personally, I really like HAML. Not having to use open and close tags is a huge time saver. As a result, writing markup with HAML is much more pleasant. HAML essentially forces you to be very strict about spacing, organization, and structure. It also makes the markup easier to read. Protip: I use this pretty frequently: htmltohaml.com

To me, this is by far the best programming language. Why? Because it’s the only language that really got me going after trying to get into programming with Java for a while. Python is powerful, easy to learn, and gets you to unsderstand other languages more once you understand it. Did I state I love the python language? Well, I do..

Backend server for analysis of image samples from iPhone microscope lens. Chose this because of familiarity. The number one thing that I've learned at hackathons is that work exclusively with what you're 100% comfortable with. I use Python extensively at my day job at Wit.ai, so it was the obvious choice for the bulk of my coding.

been a pythoner for around 7 years, maybe longer. quite adept at it, and love using the higher constructs like decorators. was my goto scripting language until i fell in love with clojure. python's also the goto for most vfx studios and great for the machine learning. numpy and pyqt for the win.

Large swaths of resources built for python to achieve natural language processing. (We are in the process of deprecating the services written in python and porting them over to Javascript and node)