ClickCease
JavaScript Bangkok 1.0.0

JavaScript Bangkok 1.0.0

By
Chris Vibert
August 13, 2020

Here's a look at some of the highlights during the JavaScript Bangkok 1.0.0 conference, as shared by one of Amity's software engineers.

The JavaScript Bangkok 1.0.0 conference was my first look into a JavaScript community outside of Europe. Combining all of Bangkok’s JavaScript communities (React, Angular, Vue, NodeJS), this was the largest conference in Bangkok to date. Fortunately for me, it was also their most international conference, meaning that most of the talks were in English, and those spoken in Thai had (nearly) real-time subtitles for us foreigners in the audience.

Here’s a quick summary of what I took from the day.


Building your first malicious chrome extension

Chrome extensions — small, powerful, and sometimes evil. Alon Kiriati demonstrated an example Chrome extension built from just a few small JavaScript files. The extension changed the displayed currency of an item’s price on Amazon while also adding his referral tag to the URL, helping him to earn some money — pretty clever!

{% c-block language="javascript" %}
chrome.webRequest.onBeforeRequest.addListener(
request => {
  const url = new URL (request.url)
  url.searchParams.set('tag', 'MY_REFERRAL_TAG')
  return {
    redirectUrl: url.toString()
  }
},
{ urls: ['https://amazon.co.uk/*] }, ['blocking']
)
{% c-block-end %}

Alon’s frighteningly simple ‘malicious’ code

Rajasegar Chandran spoke about using codemods — code to rewrite code — to make sweeping changes across a codebase safely and consistently. Something a little more intelligent than a sed command to find and replace.

He showed how this was possible using tools such as AST Explorer and Facebook’s jscodeshift. I’d never heard of AST Explorer, but it looks pretty cool — you simply drop in some code and can view the abstract syntax tree (AST) that it generates. To his audience of JavaScript enthusiasts, Rajasegar cleverly described an AST as “DOM for your code”.

Exploring my AST

What happens when you cancel an HTTP request?

This one was a lot of fun — probably the highlight of the day. Younes Jaaidi showed that canceling an HTTP request on the frontend doesn’t necessarily reduce the workload for the backend.

Younes demonstrated a solution where HTTP cancellation did, in fact, happen end-to-end. He did so by ‘adopting a reactive approach and using observables everywhere’ with RxJS and NextJS, which I have to admit, is now a very tempting combination. Younes’ himself has written a great article about the topic.

Younes thinking reactive in his ‘coding apron’


Yonatan Kra spoke about how utilizing techniques that are heavily used in gaming  — where seamless user experience is crucial — can improve your app’s performance.  He called out JavaScript developers as thinking only about the browser, and not the underlying machine, which is probably true for most (myself included).

There were several topics covered, but my favourite was the Flyweight Design Pattern which is a method to minimise memory usage. The pattern achieves this by sharing as much data as possible between similar objects. Yonatan spoke about this in the context of sending data over a network — the flyweight pattern suggests that you extract the shared data and send only a single instance of this along with the rest of the now-thinned-out data. The receiver then needs to know how to piece it back together.
It sounds relatively abstract, but Yonatan gives a simple example using an Express server: the second route sends fewer data overall, but notice how it also carries an additional piece of static (shared) data.

{% c-block language="javascript" %}
app.post('/getData', (req, res) => {
res.send(generateData(User));
});
app.post('/getFlyWeightData', (req, res) => {
res.send({ data: generateData(FlyWeightUser), EXTRA_STATIC_DATA })
});
{% c-block-end %}

A journey of building large-scale reusable web components

Varayut Lerdkanlayanawat spoke about building a reusable component library for the AWS console. If you’ve ever taken a look at AWS console, I’m sure you’ll agree that it’s definitely in need of some consistency.

Many teams build the console, not all of whom are using React. Not wanting to build two libraries (one for React, one of Vue etc.), they first considered using web components but ruled this out due to IE issues even with polyfills. And so, vanilla JavaScript was chosen one. It’s great to hear that not everything needs a fancy library or framework. Talking of which though, Varayut did speak about percy.io, which is a tool used for automated screenshot testing to help catch ‘visual bugs’.