LinkedIn NYC Tech Talk Series: JavaScript Meetup

Inside the LinkedIn office at the Empire State Building in New York City, we routinely hold a series of meetups covering topics that range from web and mobile to distributed systems and video technologies. The LinkedIn NYC Tech Talk series serve as a place for the New York tech community to engage with experts in the field, learn from each other, and share their best practices.

Last Thursday, July 19th, we hosted three speakers—Chad Hietala, Robert Jackson, and Tom Dale—to talk about all things JavaScript from building large-scale web applications to TypeScript and compilers. The JavaScript Tech Talk gained interest from many in the tech industry who wanted to hear these LinkedIn engineering leaders speak about JavaScript.

We would like to thank everyone who attended the event for a great night of discussion and for developing new ties within the community. For updates on upcoming events in the series, please follow the #LinkedInNYC hashtag, subscribe to the @LinkedInEng Twitter account, and join the LinkedIn NYC Tech Talks Meetup group. For those who weren't able to attend, below is a recap of the talks as well as a video recording of the speakers.

Compilers: The Next Frontier in Web Performance

Chad Hietala talked about the compilers we use in our day-to-day toolchains, which can be generalized as code translators. He recalled how compilers in the web started out as minifiers, like YUI Compressor or JSMin, which aim to reduce the payload size. The big idea back in 2003 was how name mangling—taking identifiers in our code and mapping them into a new set of identifiers that are a lot shorter in length (i.e., from “myFunc()” to “a()”)—was used to reduce JavaScript size.

Chad then progressed through 2008 to 2010, where the idea of JavaScript as a bytecode format was all the rage. With compilers such as GWT and CoffeeScript, a developer could write code in a certain language, and it would get compiled down to vanilla JavaScript.

Today, modern JavaScript compilers such as Babel and Traceur are used to unblock new and proposed language features, provide optimized bundles, and eliminate dead code. “There are, however, problems in paradise because we have changed in how we build web applications,” said Chad. He referenced a tweet where Alex Russell said, “the web is getting slower because no matter how much faster we make Chrome, developers abuse users with ever-larger piles of JS … and JS is the most expensive thing.”

Alex and Chad pointed out that JavaScript’s parse and compile time is significantly longer than when a browser downloads other resources, such as images or text, which merely get downloaded and painted in the window. The issue is further compounded by the way developers think about developing a new feature, which is to typically start with JavaScript first and think about CSS later, with HTML having exited out of this picture.

Chad then explained how the introduction of technologies such as WebAssembly (WASM) and projects like the Glimmer VM enable the compilation of JavaScript source code into much lower level code to reduce the parse and compile time in the browser. Furthermore, since Ember owns the entire stack, none of the app code needs to be changed to take advantage of WASM within Glimmer VM, and we should be able to reap the benefits with shorter parse and compile times.

The Joy of TypeScript

“I have a very severe open source addiction,” Robert Jackson announced in his introduction. However, Robert admitted to not knowing much about TypeScript initially, when he argued against it with Tom over his blog post, “What’s the Deal with TypeScript?” back in April 2017.

Since then, Rob became a TypeScript convert. In his talk, Rob took us through the joys of TypeScript and where we might want to hold off on it.

Before we go into that, what is TypeScript? It is an open source compiler of TypeScript syntax into vanilla JavaScript, which adds features as well as optional static types. It contains numerous built-in types, such as Array, Enum, Tuple, and void, and allows you to declare your own Interfaces or contracts within your code.

“How is this different from CoffeeScript?” Robert rhetorically asked the Tech Talk audience.

Robert posits that four key TypeScript Design Goals explain the safeguards it provides when we use it. TypeScript must:

1. Impose no runtime overhead on emitted programs.
2. Emit clean, idiomatic, and recognizable JavaScript code.
3. Align with current and future ECMAScript proposals.
4. Use a consistent, fully erasable, structural type system.

TypeScript can be leveraged for minimal cost because it produces no overhead while still allowing the code to be readable for debugging purposes and future-proofing the language. There are, however, some caveats to it.

“We're not going to take a major version bump because there was a bug in the compiler where it failed to identify early errors, even though that's technically a breaking change,” wrote Ryan Cavanaugh in a GitHub issue about TypeScript.

The reason for this is that “any compiler change could result in a breaking change,” said Rob. This is similar to fixing a bug in an ESLint plugin, where the linting bug might be fixed, but then you end up breaking someone else’s real-life work because of it. He believes this is a messaging issue that needs to be resolved, but not a deal breaker.

Another caveat we encounter is that “contributing typings to a JavaScript project is like giving the maintainers a puppy,” Robert said. It is a tradeoff in the cost for upkeep, so package maintainers need to be clear and upfront about why types are wanted or not wanted in a project and provide clear guidelines.

The upkeep costs, however, are a fair price to pay for the benefits, from syntax discoverability, which allows us to catch errors before execution, to editor type integrations, which provide features such as autocompletion, to finding file definitions and the actual file itself.

TypeScript also allows us to make use of interface-driven design, which uses type interfaces as a way to communicate how to use our packages and what we might want to add. Furthermore, by combining factory functions and type interfaces we can make our packages opaque. Exposing the type interfaces as the way to interact with them, makes them both reusable and easy to refactor. “We are much better supported with TypeScript than we are with just JavaScript,” Robert concluded.

JavaScript at LinkedIn Scale

What is LinkedIn scale? Tom Dale discussed in his talk that LinkedIn supports over 560 million members in 24 different languages across more than 200 countries. This is achieved through the hard work of hundreds of UI engineers in offices in over 30 different cities in vastly different time zones. While most members might be familiar with the LinkedIn flagship application, we also support a multitude of other products such as Sales Navigator and Campaign Manager.

To coordinate across the different product teams, the Presentation Infrastructure (PI) team provides a platform for developers to create sites that are fast, maintainable, and secure. LinkedIn has heavily invested in next-generation web application architectures and technology. In this talk, Tom also covered how hundreds of engineers spread across different offices and time zones build modern web applications.

The architecture, or how LinkedIn uses JavaScript in practice, naturally comes to mind when we need different organizations within LinkedIn to have a similar way of developing applications. The Pemberly architecture combines open source software we were already using in the mid-tier (Play) along with a web framework (Ember) to address that gap. This stack allows LinkedIn to mimic the same architecture as you would see in a native app where the rendering logic is moved away from the server and into the device the member is holding in their hands. “Having the same architecture lets us maintain high feature parity between the three applications we support,” explained Tom.

The workflow engineers have to go through to build LinkedIn’s web applications directly affects how the engineers build it. For example, the 3x3 strategy of releasing the application three times per day with no more than three hours in between code commit to it running in production ensures that the feedback loop is always present. LinkedIn’s code review guidelines even require that all code pass a code review by a product owner and a platform owner and be subject to static analysis and automated tests.

The Presentation Infrastructure team also learned that doing web development sustainably and at scale means that LinkedIn needed to standardize, optimize for change, and empower product teams. Tom mentioned how standardization helps reduce the number of decisions a team has to make, since “those are decisions, but they are not important ones for the team.” There are also fringe benefits for standardizing your stack, such as increased leverage of tools and products you build and the ability to respond.

Another lesson is to optimize for change, even at the infrastructure level. We should “prefer declarative systems, [which] gives you as the infrastructure builder a lot more room to change,” said Tom, as it provides us with the freedom to try new approaches without rewriting apps. Luckily, when everyone in the company is on one stack, it makes it very easy to automatically migrate, with some investment in automated tools that produce a huge impact.

Finally, we need to empower product teams, as they will act as your strongest allies for using the platforms we build. It is good to get feedback early before committing to a direction and use RFCs to give other teams ownership over the infrastructure they will use every day. Make sure that there is an escape hatch for the rare edge cases where engineers need a supported way to break out of the opinionated system to do what they need to do.

Acknowledgments

Thanks to Chad Hietala, Robert Jackson, and Tom Dale for presenting their talks and to Siva Visakan Sooriyan, Alex Easton, Anne Trapasso, and Anita Desai for organizing the meetup. This would not have been possible without the many volunteers from LinkedIn as well as all the attendees for making the meetup a success!