HolyJS 2018: Moscow ❤️ JavaScript

Riyani Mardikaningrum
Inside Bukalapak
Published in
11 min readJul 22, 2019

Last November, we made an unexpected trip to Moscow at the beginning of winter. It’s one long overdue post, finally, we will share what went on and what we experienced in HolyJS Moscow 2018.

Brace yourselves, winter is coming

As most, if not all, of the group members, are tropical person, preparing for the cold weather was a big concern. As we opened the door exiting the airport, greeted by the immense cold which will be remembered through this day, our conference journey started.

What is HolyJS?

HolyJS Moscow is a technical conference revolving around the topics of Javascript and its ecosystem. It covers a wide range of the most recent and popular topics in the world of Javascript. The conference is not only held in Moscow but also in the city of Piter (a.k.a St. Petersburg). The conference is organized by JUG.ru group. They are an active independent organization based in Russia who focuses on organizing conferences and meetups for developers. If you are interested in more of their activities or conferences, head on over to their website.

The walks

Before the day of the conference, we had a leeway of free time as we took a city tour around Moscow. With a little bit of help from Google Translate and our communication skills challenged, we overcame some hiccups and finally were able to experience Moscow’s Metro. The Metro stations underground were amazing, each with their own unique architecture.

We made sure to visit some of the popular sites in Moscow. Some of our stops were The Red Square, St Basil’s Cathedral, GUM, and Izmaylovo Kremlin.

Red Square in the background

Trips aren’t complete without bringing home little souvenirs to remember by and to be honest, we are craving for chocolates in Moscow which is said to be very cheap (Pssst, they are!). For matryoshka hunting, we toured to Izmaylovo Market on the east side of Moscow, just beside Izmaylovo Kremlin. We found the place to be a bit barren since we came on a weekday, but there are still a lot of stalls selling merchandise so no worry there. As for the chocolates, we went straight to the Alyenka factory, famous for their Red October chocolate. I say we should’ve bought more chocolates.

The talks

November 24–25, Moscow — The day of the conference!

One of the conference halls of HolyJS Moscow 2018

The event was held for 2 days and was attended by JS professionals from various regions to expand their skills, solve technical issues with the best and the brightest in the community and to learn and collaborate within JavaScript ecosystem. While attending, we had the opportunity to meet and network with the world’s leading experts who are focused on the inbound experience in their own roles.

The conference was very well-organized. It has 3 parallel tracks in different rooms (Day 1: 14 Talks & Day 2: 16 Talks). Each talk was distinguishable by their complexity: (1) Introduction to Technology, (2) For Practicing Engineers and (3) Hardcore. Not only were there talks, HolyJS Moscow 2018 offered other activities which will keep us busy such as the TCXX Proposal Competition (New Proposal to the ECMAScript standard) and the Code in The Dark and JS Battle.

The Expo section caught us by surprise! We can say that it is one of the things we look forward to when we are idly waiting for the next talk. Here, Partners and Sponsor booths were setups. But it’s not just about promotion, the booths offer interesting “win/learn” challenges like Kahoot quizzes, coding tasks, etc. The prizes varied from nice-to-have utilities to extravagant-sized LEGO package! Unfortunately, most of the challenges were presented in Russian so we resorted to translation services. We didn’t win any of the extravagant-sized, but we had fun and learned a couple of tricks along the way.

After a talk, participants have a chance to delve deeper into the talk, or any other topic, in the Discussion Zone where speakers and participants mingle through drinks and snacks. It’s the perfect place to hear more from the best practitioners in the industry on the latest tech.

Photo of the gang in the free photo booth

HolyJS hosted a total of 30 talks which would be too vast to convey in just one article. We’ve selected a few topics that interest us most for you.

1. Michel Weststrate — State Management Beyond The Libraries

Many battles have been fought over what is the best way to do state management. A gazillion of strategies and libraries are out there. Here, Michel elaborated the state management essentials and introduced MobX.

In developing applications, we are always dealing with data movement.

This involves where to store data, where to send them, when to send them, how to make them available and consistent across platforms, etc. To sum it up, we are always dealing with the problem of how we move data from point A to point B (e.g server to screen) and keep all data consumers updated after data mutation. These are not new and has always been a problem for us developers. There are already a very large amount of solutions.

How do we choose (or not choose at all) and be sure that we’ve done the correct decision?

Michel formulated four questions essential when deciding on a state management solution

  • What are the moving parts?
    We should understand first what are the moving parts within the library/solution and decide, is it okay for our app to work as it is? Lesser moving parts makes it easier to grasp the flow and more moving parts makes it easier to read the state and to optimize. For example, React’s state is between a few and a lot of moving parts. Because each component in React can have its own state so the amount of moving parts depends on the number of components with the state.
  • What strategy is used to propagate changes?
    A common solution to make changes available to components is using a subscription system. React has a subscription system called context, where a component can subscribe to data on a higher component tree. This brings us to another question to solve, what should we subscribe to? We can choose to subscribe on changes of a single big object to a more fine-grained attribute of a specific object, this all depends on our application.
    React context: single event per context
    Redux: global event, selectors can be used to fine-grain
    MobX: one event per property, selectors are automated

More subscription means more fine-grained, but also more work.

  • Where does state live?
    Many say that it is better to separate UI and state, to separate state logic and screen logic. Michel opinionated that side effects can live outside of components, only if the state live outside of components. Most libraries such as Redux, MobX, Vuex, and many others have already supported these. Of course, if you are dealing with a very simple state, maybe it is more preferable to manage states inside the component itself.
  • How to deal with references?
    The last point is to know your references when you pass a state to a function. Whether we are passing it as an identity or a value makes a difference to how the function handles the arguments passed. For example when we are passing an Item object with price attribute and delay the function for 1 second, the result will be either (1) the price changed; or (2) the price is not changed, but may not be up-to-date.

So which one is the better state management library? As what Michel said in this talk

Let’s not bash other’s ideas and look beyond them.

One might have what you need and one might not, but that doesn’t mean the other is always better than the other. Choose one, understand them, decide to either stick with them or don’t. It’s also okay to not choose at all!

2. Marko Letic — Bringing Mixed Reality to the Web

The main part was to show how to import a 3D model to a WebGL scene using Three.js, how A-Frame is leveraging this to enable developers to create a simple 3D VR scenes and where is WebXR in all of this.

WebGL (Web Graphics Library) is a JavaScript API for rendering interactive 2D and 3D graphics within any compatible web browser without the use of plugins. In 2018, It’s supported in all major browsers including desktop and mobile. In 2010, Three.js has been released to create 3D animation using javascript. He also demonstrates the basic use of Three.js by creating a simple cube that rotates.

A-Frame is web framework for building virtual reality (VR) experiences. With this framework, you develop VR content in an easy way and support many VR headset. It’s also based on Three.js. He also gives an example by creating object from A-frame and imported 3D assets.

AR.js is combined with A-frame, Three.js, and. jsartoolkit5 for building Augmented Reality for the web that work on any modern phone. He also give us an example with a texture as asset, then casting the element on a surface template image.

In 2018, WebVR changed its name to WebXR. WebXR is API for accessing virtual reality (VR) and augmented reality (AR) devices, including sensors and head-mounted displays, on the Web.

3. Mattias Petter Johansson — Surviving Death by Complexity

It seems like our nice simple software always eventually evolves into a slobbering complex monster, incomprehensible for its users and unmaintainable by its developers. In this talk, MPJ explained how to reach “simplicity“.

In the beginning, MPJ tells us about his experience at Spotify as an engineer, MPJ said Spotify is Technology Company that very pay attention to simplicity and he learns so many things in there about how to manage complexity and how to avoid the bloated product.

As an engineer, we know that every technology company never want to delete their feature even if the feature is useless. Because of the company worry feature that their deleted is the most important one for the customer. But removing feature is a common thing in Spotify.

Complexity just makes the product bloated, hard to maintain and source of ridiculous bugs. For example, if we compare the current version of Adobe Photoshop with the first version of Adobe Photoshop, we can see that Adobe Photoshop has improved and changed so much, but not of all that improvement and changes useful for the user.

The main function of Adobe Photoshop is to manipulate the photo, but Adobe has improved Photoshop too far, now Photoshop is the application that not only able to manipulate the photo, but also video, GIF, even sound. The improvement makes Photoshop very bloated because not all of their user use that feature.

People download Photoshop to manipulate the photo then people will download another application if they want to manipulate video. As a consequence, a lot of people start to leave Adobe and try to find another application that more simple than Adobe Photoshop but still able to provide their needs, because they don’t want to download and fill their little space of harddisk with the application they don’t use.

We also can learn simplicity from Linux Application called grep, every software engineer knows about grep and use grep. Because it’s simplicity grep is not replaceable. grep was created a long time ago before Photoshop, but the engineer of grep know what their user needs, they know what thing they need to improve and they never try to make their software bloated with adding a feature that doesn’t even useful for grep user.

Preventing the product become bloated is not the only responsibility of engineer, it’s also the responsibility of product manager and stakeholders, we must understand we don’t need to give the ocean for a person that just needs a cup of water.

4. Erik Rasmussen — 🏁 Final Form- Form state management via Observers

Managing form state is extremely complicated. Take it from the author of the most popular React form library, Redux-Form. Erik’s talk discussed the lessons learned from building and maintaining the most popular form library, and how they were used to create a new form library (🏁 Final-Form; high performance, subscription-based form state management), optimized for minimal React re-renders, but also powerful enough to be used with other libraries.

Final Form is an ideal form library. It’s a standalone, with zero dependencies, and pure JS library. Small in size with only 4kb gzipped. Subscription-based that only update on the state you need using the Observer pattern. Framework agnostic, so you don’t need to depend on any Javascript framework. It’s also modular and pluggable. Final form also comes with framework support if you want to integrate it with a framework. There are React Final Form and Vue Final Form.

Building forms is kinda hard because there are few things that you need to consider. There are a lot of states. For example, focus, error, field visited, asynchronous validation, submit, error after submit, and the list goes on. These states change rapidly. You need to put effort to decide the User Interface and Experience, because a lot of state that rapidly change.

To make things easier, you can choose to work with a library like Redux-form. Erik shared more about the “how and when” in choosing a library.

  • First, you need to know the complexity is your problem. Do you even need a library?
  • Check the extensibility of the library. Does it fill all your needs?
  • Rate how much you understand the documentation and the given example code. Make sure you understand how to use the library well.
  • Bundle size of the library must be a consideration, especially if forms are only a tiny portion in your application.
  • Also, we can guess its usability from the popularity of the library, like checking the Github star or npm downloads.

Takeaways

Unfortunately for us, even though there were 30 talks in 2 days, we couldn’t join some of the interesting-on-description-talks since we don’t speak Russian. But it was not a big obstacle, because we had “Google Translate” app to the rescue. HolyJS Moscow offers a variety of activities aside from the conference talks which makes it more exciting. From very active booths with coding challenges and prizes which fires the competitive spirit to greater heights, good food and mood, to competitions and discussion panels.

For those of you who want to attend an international conference, please talk to the committee about the language that will be used during conference. Also, we recommend you to make some notes during the talks, because not every speaker uploads their presentation and there could be talks that are only available offline.

All in all, these two days conference was full of JavaScript. Additionally, it also inspires and motivate us to continue to strengthen our skills in working with modern JS-applications: its architecture, best-practices, performance, and memory management.

--

--