What we learned at our first JS Guild Summit

At Dropbox, we work to keep teams flowing—so earlier this month, we convened a group of our frontend engineers to do just that. At the beginning of October, we held the first JS (JavaScript) Guild Summit at our San Francisco headquarters to bring together frontend engineers from our four engineering offices for two days of teaching, learning, and collaboration.

The JS Guild is a grassroots initiative at Dropbox to improve our frontend engineering by fostering community, culture, and code quality. The group strives to teach frontend best practices to generalists and to help strong frontend engineers leverage and grow their domain knowledge.

Over the past year, JS Guild members have championed several foundational improvements, including a large-scale migration of frontend code from Underscore to Lodash and early work for a migration from Flux to Redux. The JS Guild also circulates a biweekly newsletter, which is written by a rotating group of engineers and showcases frontend best practices, recently shipped projects, and news from the frontend world outside of Dropbox.

At the beginning of the summer, the JS Guild identified a unique challenge and opportunity: how to leverage the technical contributions from our engineers in San Francisco, Seattle, New York, and Tel Aviv so that all Dropbox engineers could benefit from the breadth of frontend code shipped in each of our offices.

The JS Guild Summit represented a dedicated effort to break down silos between teams and to facilitate the free flow of ideas between engineers. In the planning of the Summit, Matthew Gerstman, one of the lead JS Guild Summit organizers, thought about “breaking down silos” as “establishing many-to-many connections across engineers so that people can collaborate and communicate as powerfully and efficiently as possible.”

At the beginning of October, 115 Dropbox frontend engineers participated in two days of talks, workshops, open-ended discussions, and social events—all intended to promote knowledge transfer, to celebrate the diversity of frontend work taking place in our four engineering offices, and to identify opportunities for increased collaboration.

At the JS Guild Summit, frontend engineers shared knowledge and broke down silos by giving talks on topics like:

• What’s good about React anyway?
• Everything you need to know about the JS event loop
• How to build accessible and inclusive web components
• Everything you need to know about unicode and emojis (a favorite in Dropbox Paper)

We aimed to make the Summit inclusive, so we accepted talk proposals from engineers with a wide range of technical and public speaking experience. While we held a well-attended talk by VP Design Nicholas Jitkoff, several of our presenters had the opportunity at the Summit to deliver their first-ever technical talks and to gather feedback from a large group of engineers tackling similar technical challenges.

At the Summit, we also had an opportunity to identify areas for technical and foundational improvement by holding an “ unconference,” a series of participant-driven discussions on topics seeded by conference attendees. Over 50 engineers contributed to lively and productive discussions on topics like:

• The future of automated UI testing at Dropbox
• How to increase the Dropbox footprint in the open-source world
• The Dropbox Chooser component
• Web accessibility and inclusive design principles
• How Dropbox engineers can use and contribute to our internal UI component library

In the spirit of sharing insights from our four engineering offices, David Goldstein, a software engineer on the Web Platform team in San Francisco, set out to demystify hot reloading (a utility that’s essential to many frontend workflows) and how his team tailored our implementation to Dropbox code by making it compatible with RequireJS.

Imagine you’re rapidly iterating on a web component and making independent changes in rapid succession. How do you maintain your focus and flow while rapidly modifying the contents of local TypeScript and CSS files?

That’s where hot reloading comes in. Hot reloading is a mechanism that allows the browser to incorporate code changes into a page without a full page reload. It supercharges frontend workflows because:

• Page reloads can be slow and unnecessarily break a developer’s focus and flow.
• Pages have state based on what you’ve navigated to within them. That state is lost on a full page reload, so loading new code without a refresh allows us to preserve the existing state and to isolate the effects of new code changes (enabling easier debugging).

Given our ongoing migration from Flux to Redux, David emphasized that the feasibility of hot reloading is tightly coupled with frontend architecture itself and gave an overview of which pieces of code are hot reloadable in a React/Redux app. With his talk, David aimed to share what happens under the hood of a hot reloading tool and thus to help other engineers better understand the critical pieces of their everyday workflows.

Assaf Kamil, a software engineer from the Tel Aviv office who works on tools and interfaces for Dropbox Business admins, hosted a workshop on Rondo, a framework centered around tightly integrating reusable business behaviors and business flow with Redux. At its core, Rondo provides an interface for encapsulating the actions, state management, and side effects required to support a business flow. In his workshop, Assaf demonstrated how Rondo has accelerated his team’s efforts to build interfaces that help our business customers keep their flow and provided practical training to help other engineers bring Rondo to their teams and offices.

Many timezones away from Tel Aviv in the Seattle office, Staff Software Engineer Josh Zana was an early contributor to our ongoing Redux migration. The migration from Flux to Redux originated last year in a Web Enhancement Proposal (WEP), an internal process that we use to propose foundational changes and to align on a universal approach to implementing such changes. The authors behind the Redux WEP envisioned that migrating from Flux to Redux would provide an opportunity to build a standard “repository” for UI data shared across multiple components, to reduce technical debt, and to improve test coverage.

At a high level, migrating a store from Flux to Redux involves removing state that doesn’t belong in a given store and adding the Redux constructs of actions, selectors, and reducers. This might include porting derived state to Redux selectors (optionally memoized), migrating canonical state to reducers, or converting asynchronous Flux actions to Redux Thunks or Sagas.

In his talk at the Summit, Josh aimed to educate other engineers about how they can safely migrate their teams’s legacy Flux stores to Redux. Over the last few months, Josh and his team have migrated about 80% of their legacy Flux logic to Redux and, along the way, distilled a set of important learnings about undertaking such a migration:

• Plan in advance and ensure that you have a thorough understanding of the legacy store before starting migration work
• Break down migration work into manageable tasks
• Parallelize work across team members for load balancing and knowledge sharing
• Test every reducer in isolation since they should all be side effect-free
• Experiment with Redux Thunks and Sagas and select which of the two is sufficient and/or simpler for your use case

At the Summit, we focused both on frontend technologies (hot reloading, Redux, Rondo, and more) and on product development methodologies. Representing the New York office, software engineer and tech lead Mike Lyons gave a talk on how rapid prototyping and iteration fueled his team’s efforts to ship Dropbox Showcase, a visually compelling sharing tool for professionals and enterprise customers. While his team had to make tradeoffs to get a product to market faster, the rapid prototyping approach reduced the cost and frequency of missteps and anchored their iteration to real-world use and feedback—putting the customer at the center of their work.

Since the JS Guild Summit, numerous frontend engineers have remarked that the opportunity to meet in person with engineers from our other offices allowed them to “understand the human behind the [Slack] avatar” and collaborate more effectively. One attendee recently noted that “my biggest takeaways during the Summit came through hearing other [engineers] present problems that are similar to the ones my team faces. It… gave a lot of insight into how my team can implement our own solutions.”

At the JS Guild Summit, we shared knowledge, broke down silos between engineers, teams, and offices, and invested in our frontend engineering community.

Want to collaborate with Dropbox’s growing community of frontend engineers? We’re hiring for roles in our four engineering offices. Join us!