{"id":460,"date":"2016-11-01T12:41:31","date_gmt":"2016-11-01T12:41:31","guid":{"rendered":"https:\/\/mtwoblog.com\/?p=460"},"modified":"2016-11-01T12:41:31","modified_gmt":"2016-11-01T12:41:31","slug":"javascript-promises-meetup-example","status":"publish","type":"post","link":"https:\/\/muhammad.dev\/javascript-promises-meetup-example\/","title":{"rendered":"JavaScript Promises – a meetup and an example"},"content":{"rendered":"

The Colombo JavaScript Meetup group organised an event titled ‘JavaScript Promises’<\/a>\u00a0on 20 October, 2016 at WSO2, Colombo 3.<\/p>\n

\"JavaScript<\/p>\n

The two speakers – Isuru and Raathigeshan were both from Zone 24×7. Below are some of the notes I took from\u00a0the two talks.<\/p>\n

The\u00a0old school way<\/h4>\n

Synchronous programming is when the code runs\u00a0statement by statement, only running the following statement when the current one is completed.<\/p>\n

Isuru began the talk\u00a0introducing the Synchronous (old school) way of\u00a0coding – when receiving data from an API endpoint for example. The solution was to\u00a0google and go to stackoverflow only to come back and write a setTimeout().<\/p>\n

The\u00a0problem with this approach is that when the synchronous function is huge, this would freeze the application.<\/p>\n

The\u00a0(traditional) Asynchronous way<\/h4>\n

Asynchronous JavaScript essentially is when a code is not blocked by something that is to be completed. The page can load and wait for whatever is to\u00a0be received – maybe some data through an API call. After the return is successful, a callback is made which would typically build the HTML based on the returned data.<\/p>\n

Yes, you have achieved non blocking calls. Awesome!<\/p>\n

Or is it? While this does ensure an async way of doing things, this way also has a couple of drawbacks:<\/p>\n