DEV Community: Justin Lam

How to grow in your career: Hint, it's not about the tech.

Justin Lam — Wed, 08 Jul 2020 18:07:17 +0000

Here is my take on 7 things to grow in your software development career beyond getting better at the tech.

1. Learning to estimate and plan

A way to leverage more value from yourself is to lead others to create value. One way to lead others is to strengthen your estimation and planning skills. Estimating how much work something takes is more of an art than science. What helps you get better at estimating is experience and technical knowledge. Important and impactful projects take months with a team of developers. This will need coordination and organization to make sure you will deliver on time and on budget. One reason why managers and leads are important because they can coordinate others. Coordination is not easy but successful coordination can produce great value. A senior developer should reinforce this skill.

2. Having an attitude to do more than expected

In my career, I'm been guilty of refusing extra work before. I've once told a manager of mine that this isn't my responsibility. That kind of attitude held me back in my job. You should be careful of limiting yourself to only what people ask of you. Be comfortable to venture beyond your job description. This includes fixing those quality of life bugs that no one wants to bother. It could be improving internal tooling that has no clear ownership. Don't be shy to volunteer for other things like helping onboard new hires or help with recruiting. There might come a time when managers, PMs, or designers will need an extra hand. Offer to build a tool for them or assist them even if it doesn't involve coding. Rising beyond your expectation will definitely put you above the rest.

3. Being able to convince others to follow your cause

Going beyond senior demands the ability to convince others to follow your cause. You'll need support from managers and colleagues if you want your ideas realized. Do you want to refactor major sections of the codebase? Do you want to launch that other amazing new feature? How about getting people to fix their bugs? You should be able to communicate the benefits of your idea and why people should help you. The goal is to get enough excitement that others will start championing for you.

4. Learning to read the room, maintaining professionalism

One thing I've seen hold people back in their career is not controlling their emotions. Being able to project positivity that encourages peers is invaluable. A senior developer should understand how to deliver critical feedback well. Being condescending and negative can create an uncomfortable atmosphere to work in. Growing more senior means learning how your actions and attitudes affect everyone else.

5. High level of patiences

Too many times have I seen mistakes happen because either I was too impatient or someone else was. When you become impatient you will tend to say the wrong thing and choose the wrong decision. Over time, your career will test your patiences. There will be stress and there will be times of frustration. A high senior developer knows when to not rush and make good sounds decisions. Delaying work is much better than rushing for an immediate answer.

6. Perception means more than you think

We all have an idea of what we are like. We know why we have decided to make a certain decision or done something a certain way. Yet, the internal model of yourself can be quite different from what others may think about you. How others think about you is actually more important than you think. Managers and peers conduct performance reviews without you being in the room. Facts about you are true or false but your soft skills are open to subjective interpretation. This is why as you grow into a more senior level controlling your own public relations is something important to keep in mind. You may have done the work but are people seeing you as the person they would go to or someone else. Your words and attitude can trump your technical skills so be aware of how you convey yourself.

7. Mentoring not only junior people

Developing yourself as a senior developer means to mentor junior and senior developers. As you grow in your career take note of what you know and what others don't know. Junior developers will need mentorship but so do senior developers. Think about what knowledge you posses that you can teach others. The approach might be different though. You can teach classes, hold retrospectives or write detailed documentation. The idea is to think about how you can mentor or teach anyone you work with.

Post Commit: Ensuring Quality Before Release

Justin Lam — Tue, 23 Jun 2020 20:03:24 +0000

Story Time

You just spent the last few weeks writing the latest and greatest feature for your users. You did your due diligence and wrote entire suite of unit tests and integration tests. Your fellow colleagues reviewed your code and gave their thumbs up. You press commit, your CI and CD processes are green and your feature officially releases. You go home eagerly anticipating the praises and accolades in the following days.

Then it happens.

The complaints start pouring in, tweets about how your new feature doesn't really work, even worst it broke other features in your app. Things don't look good and you spend the next few days to a week fighting fires. You are starting to lose customer satisfaction.

How would we have handled this better? I will describe how committing your feature is just the beginning of your journey to releasing your software.

Let's take a journey

Know What Success Means

Hopefully before you begin writing your feature you know what success looks like and what metrics you are anticipating to move. We don't build things in a vacuum, and new features don't automatically imply happy users. Are you looking for increase in new users, high engagement with existing users, better performance, etc... make sure you know what you want and how you will measure it.

Have Internal Builds

Some people might refer to this as an experimental build, sandbox build, alpha build, etc... This is a version of your build for internal use only. The internal build allows developers to safely commit code for internal testing and experimentation. This is the build other engineers, PMs, designers, etc... will go to for an early feel of what the feature is going to do.

Dogfood Your Software

Once you have an internal build deployment process, your next phase for ensuring quality is to have dogfooding sessions. As the developer of your feature, setup some time with your team to test your new feature and do your best to break it. Report any bugs, fix, and repeat the dogfooding process a few times. Also, this is a good time to evaluate design decisions, user interaction, performance, etc...

Formal QA Testing

If your team is fortunate enough to have a QA team, this is the time to officially submit a build to them along with a write up on how to use it. Having dedicated QA professionals will help immensely in finding edge cases. The QA team should have additional resources, like multiple multiple devices or configurations to test on. Examples include testing in many different screen sizes, all variations of mobile devices, different deployment environments, etc...

Use Feature Flags

One of the best ways to save yourself in an emergency is to be able to turn your feature off after deployment. Building feature flags into your code before release will give you that safety net.

Deploy Incrementally

Internal dogfooding and QA testing can still miss some edge cases. Sometimes the best way to get feedback is from real users. It is best to release your software incrementally. Start with 5% of your users and evaluate any feedback you might get back. Once things are stable, start deploying to 10%, 25%, 50%, 75%, etc... until you finally release to 100% of your users. Find a good cadence you feel necessary for your business. This helps ensure you don't upset too many users if something does go horribly wrong.

Measure Success Through Data

Circling back to the first point, this is the time to measure if your feature is providing the value you intended. This is also the time to make sure there aren't any performance issues and regressions through data. That means you need to have dashboards with metrics to monitor the health of your software. Don't always take anecdotes or customer feedback as your only source of feedback. Sometimes the data will tell you a different story.

Release Is Only The Beginning

Following these processes will help you release your software in a safe way. But all the processes in the world won't guarantee 100% bug free and user satisfied software. Keep an eye on your feature and continue to address any feedback and issues as they appear. The success of your software really depends on the amount of love you give it through its life time after committing your code.

Importance of Editing and Proofreading

Justin Lam — Tue, 15 Jan 2019 14:37:16 +0000

I've experienced this time after time again, many developers don't proofread their work. I don't know why some developers have this urgency to submit their code for review right after they get it working without doing the important step of editing and proofreading.

Do you remember in school when you finished that essay or research paper, you edited and proofread it before submitting right? I believe this should apply to our source code too. In a way, source code is a developer's form of written communication.

After you finished completing a portion of work that is ready for submission or code review, consider doing the following.

Editing:

Does your code integrate properly into the overall system. As an analogy, writing the next chapter in the book or the next paragraph in the essay.
Using the right data structures for impact and efficiency.
Are you expressing what you are doing clearly and to the point.
Using the language as best as you can, e.g. don't write your Swift code like Java, or your JavaScript code like C#.
Are you being overly verbose or too compact with your code.
Have you communicated your intentions clearly that would be understood to another developer and not just the computer.

Proofreading:

Have you checked for spelling, grammar, and typing mistakes. Linting helps but you'll be surprised how often people ignore lint warnings.
Are you conforming to the style of the existing code and being careful of things that a linting tool might not catch.
Did you go through a checklist of common runtime errors.

I've heard reasons for not doing this, most of the time it comes down to "I want to submit my code as soon as possible. I don't want to be waiting around and have my code get out of date with the rest of the codebase." Our source code is not only how we make the computer work but also a form of communication between developers. I encourage all developers, especially newer developers, to foster the same habit you have with other written communications. Edit and proofread your work before submitting.

Time to change how we do Stand-Ups

Justin Lam — Thu, 10 Jan 2019 12:40:46 +0000

We are all familiar with the Stand-Up meeting, where everyone meets on a pre-determined cadence (every day, 3 times a week, etc...) to answer the 3 important questions.

What did I do yesterday that helped the development team meet the sprint goal?
What will I do today to help the development team meet the sprint goal?
Do I see any impediment that prevents me or the development team from meeting the sprint goal?

We call it the Stand-Up meeting because attendees are supposed to be standing while answering the 3 important questions. The discomfort of standing is intended to keep the meetings short. The reason we try to answer these 3 important questions is so that the project can be completed successfully in a timely matter.

However, having worked in the software industry for many years and have been on countless teams I am feeling that we are severely abusing the original intent of Stand-Ups and just doing it "just because we have always been doing it".

I have noted the following issues with the traditional in person Stand-Ups.

Absent attendees miss out on all the information presented. This happens more often than you think. e.g. "I need to get my car fixed in the morning, will be missing stand up today", "Cat peed all over the carpet so I need to clean it up, will be missing stand up today", "Got a dentist appointment and will miss stand up today", etc...
People are frequently late to Stand-Ups which inevitably prolongs the Stand-Up meeting time.
People almost always go off into tangent discussions that aren't important to the rest of the team. I am beginning to think this is just human nature.
I've heard of other Stand-Ups lasting up to 45 minutes to an hour. That team felt quite proud of it too.
Forced time limit almost never works. Some people just love to describe every minute detail of their work even when the 3 minute timer is beeping.
Humans have terrible memory.

I want to propose we replace the face to face 15 minute Stand-Up meeting with group chat software (Microsoft Teams, Slack etc...). This ensures the 3 important questions are documented and searchable. No more missing information, no more he said/she said misunderstandings and threads can be replied to and referenced back.

But I've heard feedback from teammates that they want to see each other face to face and they "supposedly" get value from making the Stand-Up meetings super long. Translation: We like to waste time talking about the weekend or what we did last night. Well, may I introduce to you the "let's go get coffee together meeting" for those social needs.

Learn to defend your decisions

Justin Lam — Wed, 13 Jun 2018 06:05:23 +0000

One thing I learned recently which really helped me grow as an engineer is to learn how to defend my decisions. When you make an choice on a framework to use, an architecture pattern, or the style of your code, it is very important that you can defend why you made that decision. I have noticed that unseasoned or junior developers can't really justify why they made their choice. Typical answers when grilled includes, "That's how it's been done in other places in the codebase", "It works", "We have always been doing this", or "That's what everyone else does".

How does being able to defend your action help you grow? For every decision you make while designing and developing, you should be asking yourself how would other people poke holes in my choice. If they do find a flaw, how would I be able to explain to them that it's okay or that I've thought about it and I've got a solution later. A good developer will mostly likely be able to defend their decision with some hesitation if grilled on the spot. An excellent developer would have already prototype the alternatives, vetted through any flaws well in advance and be able to defend their position when questioned. You will grow tremendously when you do this. You will become more confident in your choices. It's not easy and it takes a lot of time but it is rewarding. You might end up going down the rabbit hole that is full of tangential tracks but it will be worth it to your growth.

There is a good technique you can use to help achieve more confidence in defending your decisions. When you make a choice you can try to ask your self why. Ask yourself why you are doing this, why is this better than the alternatives, why is it important, and keep asking why to drill down to the fundamentals. Learn to be curious, learn to see alternatives, and learn to be humble. You may have put in countless hours to learn every bit of defense for your decision but always be prepared to acknowledge you may not know everything and someone may provide a better solution.

A note for those doing the grilling, be strict but be fair. There's no need to put others down if they can't completely defend their choice but use it as an opportunity for them to learn.

World Block Creator

Justin Lam — Sun, 20 May 2018 22:23:25 +0000

What I built

This online web app allows you to build a 3D world using blocks. While you are building your world, you can also see others build theirs in real time. In addition, you can go into spectator mode and see all the creation happening around you. Get inspiration from others and build your own to showcase.

Demo Link

http://worldblockcreator.herokuapp.com/

Link to Code

https://github.com/justinctlam/WorldBlockCreator

How I built it

Stack Overview:
Pusher - https://pusher.com/
React - https://reactjs.org/
Babylon.js - http://www.babylonjs.com/
Heroku - https://www.heroku.com
TypeScript - https://www.typescriptlang.org/
Node.js - https://nodejs.org/en/

Development
Being new to the web stack development world, I had to learn a lot about getting a simple web app standing from scratch. I knew I wanted to use TypeScript and Babylon.js as that is what I have been learning a lot about recently.

My first step is to create a hello world client and server app and deploy it for use. I struggled a bit in this area and most tutorials didn't give all the little details. Some tutorials are some combination of the stack I wanted but there was no one tutorial that met all my needs. However I did find one that I ended up using as the base of my application. Deploy React and Express to Heroku was the best one I found that taught me how to create a client and server app using React locally and how to deploy on Heroku for distribution. It worked wonders for me.

I wanted to use TypeScript instead of JavaScript because I found the type checking really useful. I decided to go with the TypeScript-React-Starter kit from Microsoft. If you are following the tutorial from Deploy React and Express to Heroku you would make a simple change from create-react-app client to create-react-app client --scripts-version=react-scripts-ts to enable TypeScripting in the app.

You can also add TypeScript support on the server side by adding the TypeScript package to the serve app. You can find an example on my GitHub.

From here I've got a fully working app and server using React and TypeScript that is testable locally and deployable on Heroku!

For my Pusher Contest idea I wanted to do something in 3D, so I decided to use Babylon.js as my 3D framework/engine package. I know Three.js is also very popular but I've been learning and using Babylon.js and is best to use what I am most efficient at the moment. I wanted to make something that users can create and share and I would use Pusher to allow you to see what others are building in real time.

The basic concept is simple. The user is presented a ground plane and when the user clicks on it, a small box appears where the user clicked on. The user can continue clicking on the plane or start clicking on the boxes and more boxes are placed where the user clicked. The user can also remove boxes by right clicking on them. From there the user can choose different colors for the boxes and start building whatever they can imagine.

When the user decides to take a break, they are free to go into spectator mode and fly around looking at other users building their world in real time. Be inspired by what others build and incorporate those designs into your own.

For the real time aspect of the application I used Pusher channels for communication between the client and server. When a user does something on the client side, like adding a box or removing a box, an event is sent to the server. On the server side, those events are relayed to the other clients connected to the server. Also on the server side, I used Pusher's webhooks to determine when a client is disconnected. Then the server will inform all the other clients about the disconnected client and the clients will remove the elements associated with the disconnected client from the 3D space.

Future considerations

Because of the limited time I can spend on this app, there are a few features I haven't implemented yet. I hope to get to them in the future:

Store the data in a database to save between sessions
Consider authentication to allow people to login
Allow users to send likes about a design
Add more tools or shapes to enable more expressive designs

Additional Resources/Info

I would love to hear about any feedback, bugs, or feature requests.

To the Pusher Team, it would be nice to have TypeScript support for the server APIs.

Reflections on GDC 2018

Justin Lam — Wed, 28 Mar 2018 00:45:14 +0000

Introduction

I felt so blessed when my company gave me the opportunity to attend GDC aka Game Developers Conference. GDC is the world’s largest event for the professional game industry attracting the largest gathering of game developers in the world and I felt really amazing to be among all these talented individuals. At this conference, professionals such as artists, engineers, and designers come together to showcase, discuss and present the latest technologies and learnings within the industry. The conference format consists of workshops, summits, presentations, expo, and award ceremonies.

GDC 2018 is my first ever GDC, and over the course of the five day conference I picked up a lot of knowledge, experience a lot of tech, and generally amazed at how much the game development industry has grown. I wanted to summarize a few interesting tidbits as well as offer suggestions on how to navigate GDC if you ever get a chance to go.

Here is a quick high level view of GDC over the five day conference.

There are varying levels of passes you can purchase for the event where prices can range from $250 to $2300. Each type of pass provides increasingly more access to the events, for example the $250 Expo pass only allows you to visit the expo and awards ceremony while the $2300 All-access pass gives you the VRDC track, all of the GDC conference session, access to the online videos, and more.

VRDC

I was fortunate enough to get the all-access pass and I spent the first two days at the Virtual Reality Developers Conference, VRDC for short. At VRDC, I was able to get a good understanding of the latest developments in VR, AR, MR, and XR. In "Explorations in XR Creation Tools", I learned how Google built their new light panel in Tilt brush, how UnityLabs are exploring VR authoring within a VR environment and how Oculus designed their Home experience. There were good tips on prototyping with cardboard boxes from a session titled, "Playtesting VR: Brownboxing, Spycams, and Fuzzy Rugs". I also learned some good practices when building for multiple VR headsets in "1 Game, 6 Headsets, 10 Controllers: Multiplatform VR with 'Floor Plan'" and the importance of multi user collaboration experiences in "Room for Everyone: The 'Rec Room' Approach to Community VR" and "Pac-Man HoloLens: Developing a Mixed Reality Game for a Board Audience". In the session, "Exploring the Unsolved Challenges of VR Gaming", the speaker showed that VR still struggles with conveying weight, how to handle reading text, and locomotion. But despite these challenges, there were good presentations on best practices such as how to do gazing control in "Mind Control in Mobile VR: Gaze Activated in SingSpace".

GDC

GDC sessions offered up a variety of topics including engineering, art, design, and business. Many of the talks centered around the latest learnings from the past year within each discipline.

As many of the presentations were recorded and will be posted on the GDC Vault online, I decided to attend the round tables session in lieu of the presentations. I found the round tables were some of the best things to attend and were considered quite unique as they were not recorded. The round tables sessions gathered people to sit around a large table and talk about a topic, it can be about AI, animation, tools development, audio, business, etc. A wide range of experiences can be found at these round tables, from big influencers in the industry to first year students. The discussion is raw and eye opening because people speak from different perspectives and come from different walks in their journey in the industry. The hot topic this year seems to be if the game industry should unionize or not.

Expo

The GDC Expo is where companies from all around the world showcase their latest commercial products and latest technologies. You can find major companies, like Microsoft, Amazon, Google, Facebook, Unreal, Unity, Sony, etc. on the show floor creating excitement for their newest offerings. The Microsoft booth was jam packed all three days, where you try out mixed reality headsets, Xbox demos and their new PlayFab backend infrastructure for multiplayer and telemetry services. Amazon also had a huge presence with their new GameOn service and Lumberyard game engine. Facebook was furiously demoing the new Oculus Go and Santa Cruz (mobile 6-dof HMD). Google had some daydream stuff. Unity’s presence at GDC was huge, almost every mid to small size developers are using Unity and they have many performance enhancements coming, e.g., a new Entity Component System architecture, compiling C# to native code, and a new job scheduler system. Unreal and NVIDIA were showcasing their new real-time ray tracing technology. A few notable demos include, real time CGI human puppeteering, ultrasonic haptic feedback and full body VR equipment.

Getting the most of GDC

GDC is held at Moscone Center in downtown San Francisco. San Francisco is a beautiful city but downtown San Francisco can be a bit sketchy. Just watch yourself and stick to the crowds.

As this is my first GDC, I always felt anxious about missing out on things because there was so much going on and so many sessions and events were overlapping. It is almost impossible to see everything so you need to make a plan but also allow yourself flexibility to change those plans.

If I had to do it over again this would be my strategy.

If you can afford it, definitely attend the VRDC talks or the tutorial sessions in the first two days. They are an amazing experience. But don't fret if you can't because these session are recorded and are made available on the GDC Vault online. Although the GDC Vault is not cheap, estimated to be $550 if you don't have the right pass.

Give yourself 2 hours each day to spend time at the Expo or more if you can afford the time. See if you can find time slots in your schedule when none of the talks are interesting to you or if you think you can just watch later in the GDC Vault. But be sure to attend the GDC Pitch days where participants practice pitching their games Shark Tank style. Super cool to watch.

If you have a choice between going to a round table versus going to a talk, definitely attend the round tables. While you are there, I encourage you to talk to people and don't be shy to speak up and participate in the discussions. It's a very cool experience knowing you can bounce ideas back and forth with very senior people in the industry. Also make sure to attend the IGF and Game Developers choice awards ceremony as well.

Finally, stay calm, drink lots of water, and keep snacks around. You will not have time to eat lunch : )

Conclusion

Overall, GDC was an amazing experience. The atmosphere was electrifying. You can sense the game development community is a tight knit group, who are very motivated in pursing their passion. The awards ceremony during the middle of the conference revealed how much passion is in this industry. If I had to do it over again, I would bring business cards and spend a bit more time talking to individual people about their experiences and journey in the industry. I think the networking opportunities are abundant at conferences like these. I loved it and would want to go back again.

Building a 3D application with Electron and BabylonJS using TypeScript

Justin Lam — Tue, 26 Dec 2017 23:33:25 +0000

Introduction
Setting Things Up
Building the Application
Time to Build
Package and Distribute
Final Thoughts and Resources

GitHub: https://github.com/justinctlam/BabylonJS-Electron

1. Introduction

Are you interested in building a cross-platform desktop 3D application? Maybe you want to do a visualization application or even a game? I'm here to help, the following tutorial will guide you on setting up BabylonJS with Electron. I will also incorporate TypeScript so that you can see how all these technologies work together. I hope you find this combination useful and informative.

I wrote this article to help me as well as others that are coming from a non-web background, maybe from iOS, Android, desktop application, backend, etc... I'll do my best to make this as straight forward as possible and I am targeting those who are just starting out with web development.

First some basic explanation of the tech stack.

BabylonJS: A complete JavaScript framework for building 3D games with HTML5, WebGL, WebVR and Web Audio.
Electron: Build cross platform desktop apps with JavaScript, HTML, and CSS.
TypeScript: A free and open-source programming language developed and maintained by Microsoft. It is a strict syntactical superset of JavaScript, and adds optional static typing to the language.

To glue all this tech together I will be using the following infrastructure.

Visual Studio Code: Visual Studio Code is a code editor redefined and optimized for building and debugging modern web and cloud applications.
NPM: A package manager for JavaScript and the world’s largest software registry. Discover packages of reusable code — and assemble them in powerful new ways.
Electron-builder: A Complete solution to package and build a ready for distribution Electron app with “auto update” support out of the box.

This tutorial will not assume you have anything already installed. I will cover all the tools that are necessary to build it from scratch. Let's begin!

2. Setting Things Up

Let's start by installing NodeJS which will give us the ability to use NPM. You can find it here (https://nodejs.org/en/)

This tutorial was tested on NodeJS version 6, which you can download here (https://nodejs.org/dist/latest-v6.x/).

Optional: I would recommend using Visual Studio Code as your IDE. This is purely optional and not necessary to complete the tutorial. You can get VS Code here (https://code.visualstudio.com/).

Next, let's create a folder, let's call it babylonjsElectron

In a terminal or command prompt shell execute the following:



npm init

Select default for all options. This will create a package.json for you with some parameters set.

Next we will need to download and install some packages through NPM for our project.

Execute the following commands in your terminal or command prompt.



npm install --save babylonjs@3.1.1
npm install --save-dev typescript@2.6.2
npm install --save-dev electron@1.7.10

From here onwards this tutorial will work with the following versions of the packages. 3.1.1 of BabylonJS, 2.6.2 of TypeScript, and 1.7.9 of Electron.

A little bit of explanation about the package dependencies.

Dependencies are the packages we will need to run our application and devDependencies are packages we will use to help build the application but isn't required in the distribution of the application.

Your package.json file should now contain these properties:



"dependencies": {
    "babylonjs": "^3.1.1"
  },
  "devDependencies": {
    "typescript": "^2.6.2",
    "electron": "^1.7.9"
  },

3. Building the Application

We'll need 3 files to start out index.html, main.ts, and renderer.ts

Create a src folder under your current directory, for example babylonjsElectron/src.

In the src directory, create the two files main.ts and renderer.ts.

In the root directory under babylonjsElectron/ create index.html.

In main.ts put the following boiler plate code:



import { app, BrowserWindow } from "electron";
import * as path from "path";
import * as url from "url";

let mainWindow: Electron.BrowserWindow;

function createWindow() {
  // Create the browser window.
  mainWindow = new BrowserWindow({
    height: 600,
    width: 800,
  });

  // and load the index.html of the app.
  mainWindow.loadURL(url.format({
      pathname: path.join(__dirname, "../index.html"),
      protocol: "file:",
      slashes: true,
  }));

  // Open the DevTools.
  mainWindow.webContents.openDevTools();

  // Emitted when the window is closed.
  mainWindow.on("closed", () => {
    // Dereference the window object, usually you would store windows
    // in an array if your app supports multi windows, this is the time
    // when you should delete the corresponding element.
    mainWindow = null;
  });
}

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
// Some APIs can only be used after this event occurs.
app.on("ready", createWindow);

// Quit when all windows are closed.
app.on("window-all-closed", () => {
  // On OS X it is common for applications and their menu bar
  // to stay active until the user quits explicitly with Cmd + Q
  if (process.platform !== "darwin") {
    app.quit();
  }
});

app.on("activate", () => {
  // On OS X it"s common to re-create a window in the app when the
  // dock icon is clicked and there are no other windows open.
  if (mainWindow === null) {
    createWindow();
  }
});

// In this file you can include the rest of your app"s specific main process
// code. You can also put them in separate files and require them here.

In the renderer.ts file put the following code:



import * as BABYLON from 'babylonjs';

export default class Renderer {
    private _canvas: HTMLCanvasElement;
    private _engine: BABYLON.Engine;
    private _scene: BABYLON.Scene;

    createScene(canvas: HTMLCanvasElement, engine: BABYLON.Engine) {
        this._canvas = canvas;

        this._engine = engine;

        // This creates a basic Babylon Scene object (non-mesh)
        const scene = new BABYLON.Scene(engine);
        this._scene = scene;

        // This creates and positions a free camera (non-mesh)
        const camera = new BABYLON.FreeCamera("camera1", new BABYLON.Vector3(0, 5, -10), scene);

        // This targets the camera to scene origin
        camera.setTarget(BABYLON.Vector3.Zero());

        // This attaches the camera to the canvas
        camera.attachControl(canvas, true);

        // This creates a light, aiming 0,1,0 - to the sky (non-mesh)
        const light = new BABYLON.HemisphericLight("light1", new BABYLON.Vector3(0, 1, 0), scene);

        // Default intensity is 1. Let's dim the light a small amount
        light.intensity = 0.7;

        // Our built-in 'sphere' shape. Params: name, subdivs, size, scene
        const sphere = BABYLON.Mesh.CreateSphere("sphere1", 16, 2, scene);

        // Move the sphere upward 1/2 its height
        sphere.position.y = 1;

        // Our built-in 'ground' shape. Params: name, width, depth, subdivs, scene
        const ground = BABYLON.Mesh.CreateGround("ground1", 6, 6, 2, scene);
    }

    initialize(canvas: HTMLCanvasElement) {
        const engine = new BABYLON.Engine(canvas, true);
        this.createScene(canvas, engine);

        engine.runRenderLoop(() => {
            this._scene.render();
        });

        window.addEventListener('resize', function () {
            engine.resize();
        });
    }
}

const renderer = new Renderer();
renderer.initialize(document.getElementById('render-canvas') as HTMLCanvasElement);

In the index.html put the following in it:



<!DOCTYPE html>
<html>

<head>
    <meta charset="UTF-8">
    <title>Babylon JS Electron App</title>
    <style>
        html,
        body {
            overflow: hidden;
            width: 100%;
            height: 100%;
            margin: 0;
            padding: 0;
        }

        #render-canvas {
            width: 100%;
            height: 100%;
            touch-action: none;
        }
    </style>
</head>

<body>
    <canvas id="render-canvas"></canvas>
    <script>
        require('./app/renderer.js');
    </script>
</body>

</html>

4. Time to Build

We are going to build the application now. Normally you don't need to build JavaScript files but for TypeScript there is a "build" step that takes the TypeScript files and transpiles them into JavaScript for consumption.

To start off, we will need a tsconfig.json. Create a tsconfig.json under the babylonjsElectron/ folder.

Then put the following in tsconfig.json:



{
    "compilerOptions": {
      "target": "es6",
      "module": "commonjs",
      "noImplicitAny": true,
      "sourceMap": true,
      "outDir": "app",
      "baseUrl": ".",
      "paths": {
        "*": ["node_modules/*"]
      }
    },
    "include": [
      "src/**/*"
    ]
  }

The "include" property tells the TypeScript compiler where to look for the source files. We will be outputting our JavaScript files under babylonjsElectron/app folder as specified in the "outDir" property. We also have "sourceMap" set to true so that the debugger can find and put breakpoints in the TypeScript file. For more information about the other properties, you can find them here in this resource: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html

Next we will add some command line scripts to package.json. These command line scripts are used to help use execute various commands or combination of commands.

In package.json add the following under the "scripts" property:



"build": "tsc",
"start": "electron ./app/main.js",

So your package.json file should look like the following:



  "scripts": {
    "build": "tsc",
    "start": "electron ./app/main.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

tsc in the "build" property is the TypeScript compiler. In the "start" property, we will launch electron with our compiled TypeScript source, main.js.

You maybe wondering, what about renderer.ts file? It's not reference in main.ts but it is reference in index.html.

Electron has two processes, the main process and the render process. The main process is responsible for creating and managing BrowserWindow instances and various application events. The render process is responsible for running the user-interface of your app. You can find a more detail explanation here: https://codeburst.io/deep-dive-into-electrons-main-and-renderer-processes-7a9599d5c9e2.

In your terminal or command prompt, execute the following command:



npm run build

This will "build" your TypeScript file. Next, execute the following command:



npm start

This will launch the electron application. Success!

Running on Mac

Running on Windows

You may see a warning like the following in your terminal or command prompt:



Electron Helper[68582:2728327] Couldn't set selectedTextBackgroundColor from default ()

At the time of this tutorial, this is a bug in Chromium. I'm going to assume it will be fixed in future builds of Electron so let's not worry about it.

As you can see, when you run the application that the development panel is opened. If you prefer the development panel not open automatically, comment out the following line in main.ts:



mainWindow.webContents.openDevTools();

5. Package and Distribute

Alright! Now that we have a working application, let's get ready to package it up for distribution.

For this task we will need the electron-builder NPM package to help us.

Execute the following command in your terminal or command prompt:



npm install --save-dev electron-builder@19.49.0

Next we'll add the following script to "scripts" in package.json:



"dist": "build"

So now package.json will look like this:



  "description": "This is a babylonjs electron sample",
  "main": "./app/main.js",
  "scripts": {
    "build": "tsc",
    "start": "electron ./app/main.js",
    "dist": "build",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Be sure that you have something in your "description" property as well.

You will also want to make sure that the "main" property is pointing to the main.js file as shown above.

We are at the final stretch.

Finally, execute the following command:



npm run dist

This will generate a DMG file for you on Mac. You can find the file under babylonjsElectron/dist folder. When you open up your DMG, it should look like this:

In order to make a Windows application just run the following in your Windows command prompt.



npm run dist

This will generate an exe file for you on Windows. You can find the file under babylonjsElectron/dist folder.

You can customize a few options for each system as well.

If you intend to release your app, you will need to code-sign your application. For the purpose of this tutorial I will not be covering this but you can find more details here: https://www.electron.build/code-signing.

On Mac, you can specify some options for the DMG generator.

In package.json, you can add the following options to the DMG property:



"build": {
    "appId": "yourappid",
    "dmg": {
      "contents": [
        {
          "x": 110,
          "y": 0
        },
        {
          "x": 240,
          "y": 0,
          "type": "link",
          "path": "/Applications"
        }
      ]
    }
  }

Let's quickly discuss what some of these properties mean:

"appId" is where you would put your application ID if you ever plan to submit to a store like App Store.
In contents, you can specify the variety of files and paths to appear within the DMG.

You can find more details of the properties here: https://www.electron.build/configuration/dmg.

On Windows, you can customize the type of installer to use.

By default, electron-builder will build a "nsis" (Nullsoft Scriptable Install System) installer. There are various other installer options such as a "portable" installer which will produce an executable that just runs and doesn't install, and a "squirrel" installer that does one click package updates.

For example, you can add these addition configuration properties to the 'package.json' file to create a no installer executable:



"build": {
    "appId": "yourappid",
    "win": {
      target: "portable"
    }
  }

You can find more details of the properties here:
https://www.electron.build/configuration/win.

6. Final Thoughts and Resources

It's pretty cool that one can easily develop cross platform applications using just JavaScript, HTML, and CSS. Now, not only can you create a cross platform application but you can create a cross platform 3D application for richer and immersive experiences.

At of the time of this tutorial, Chromium supports WebVR but Electron has yet to use the latest version of Chromium. I'm hoping that not too long from now Electron will support WebVR and we can start building cross platform VR applications!

You can find the full source code here on GitHub: https://github.com/justinctlam/BabylonJS-Electron

Some resources I used to write this tutorial:

BabylonJS - https://www.babylonjs.com/
Babylon.js Editor and Electron - https://medium.com/babylon-js/babylon-js-editor-and-electron-706d6faf479b
Electronylon - https://github.com/mmmeff/Electronylon
Building a desktop application with Electron - https://medium.com/developers-writing/building-a-desktop-application-with-electron-204203eeb658
A complete guide to packaging your Electron app - https://medium.com/how-to-electron/a-complete-guide-to-packaging-your-electron-app-1bdc717d739f
Cross-platform Desktop JavaScript 3D Game Engine with NodeJS, Electron and BabylonJS - http://grosan.co.uk/cross-platform-javascript-3d-game-engine-with-nodejs-electron-and-babylonjs/