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

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

We’re using Markdown parsers for Reviews, Blog Posts, and Stack Description (the text you’re reading right now). We’re using Bootstrap Markdown for content input (except for reviews) and RedCarpet for rendering in certain places.

Markdown represents a highly portable and lightweight text formatting. I had converted all of my Wordpress posts to Markdown prior to migrating over to Jekyll and eventually to Hugo. The fact that many generators support Markdown means that my content remains portable regardless of the platform/engine I use.

What you see is not what you get, never it is.

Documentation is better in Markdown format. You don’t need anything special to read it.

It is compact, portable, comparable.

Markdown is my text file format of choice.

Because it is almost an effortless markup language without ever having to write an HTML tag. Of course, you'll want to use it in environments that make it look pretty (GitHub, etc.)

Using StackEdit to edit markdown files for blog roll and about sections. MD files are stored in Google Drive and pushed to GH pages through StackEdit.