Meetup #86

Paveł Gerasimov

They said: "Make it faster"! How to improve FE performance of one of the most complex views in the product. 

Sometimes (well, always) products evolve, face the new requirements, and your legacy views designed in old good times start to work not so fine as customers expect. To solve this you have two ways - rewrite everything from scratch (which usually makes stakeholders furious) or try to improve the existing codebase to ensure it meets the new expectations. Here we will tell you how we started to suffer from performance problems in Wrike Workload - one of our most heavy and complex views in our product, how we improved its overall performance in a few months, and what tools and technologies we used for that.

Bartosz Gryta

Scalable UX/UI patterns - the real cost of your HTML select element 

When developers are talking about scale issues, they usually mention auto-scaling groups, load balancing or shedding, bundle size, code splitting, chunks caching, availability zones, and so on: not everyday pieces of a codin' cake. The truth is that, however, scale issues are not so distant as they may seem. This talk tackles user experience and design patterns at scale, from the perspective of simple elements, like a picker (HTML select), in large applications. How does such a trivial element affect overall scalability?

Mikołaj Olszański

Beyond Lighthouse: measure JavaScript and website performance by counting CPU instructions 

Can we count CPU instruction for JavaScript and websites? Can it be a more reliable performance metric? Could it be be a less noisy Lighthouse buddy? Can we wrap it into a CI feedback loop for a developer who cares? Why would we do that? RAIL like and Lighthouse metrics are amazing, but they depend on networking and can be noisy. Let's try to build a workflow where with every commit we can measurably improve performance for our users.