A few years ago, the advice for keeping your page fast was to keep your page weight down. These days, […]
The rapidly evolving device and browser landscape allows us to collect increasingly rich data via our snippet. Because we host the snippet and our customers fetch it from us dynamically, expanding its functionality requires a strict eye on compatibility for all of our customers' end users. Our primary concerns are safety and iteration speed, and we’ve invested heavily in robust testing and deployment infrastructure to allow us to confidently roll changes out without spending weeks in manual testing.
Improving Perceived SPA Performance by Prefetching Critical ResourcesNovember 20, 2016 12:34 pm
I remember being intrigued by Smashing Magazine’s post this summer about using PJAX to effectively turn static markup websites into […]
Browser DGAF (that you use React) Pt. 2: FLIPping in ReactSeptember 21, 2016 8:05 pm
In the first post in this series, we looked at how coding within the React paradigm could lead to poor […]
Browser DGAF (that you use React)March 16, 2016 5:58 pm
Adventures in React Performance DebuggingRecently I read Benchling’s 2-part series in debugging performance issues in React, and it really echoed the issues and solutions that I’ve been working through on the Sift Science Console. So I was inspired to chime in with some of my own React performance debugging experiences in what may become a short series itself.
d-Threeact: How the Sift Science Console Team Made d3 and React the Best of FriendsMay 19, 2015 10:25 pm
A little less than a year ago, the Sift Science Console Team decided to migrate its Backbone and Marionette Views to ReactJS see also our post on specific React tips we learned along the way. Among the many facets of a piece-by-piece migration like this was figuring out how best to manage (err...'reactify') our d3 charts. There were already a couple good reads/ listens on this topic—with very different views on the responsibilities of each library—which we found quite helpful in establishing our own approach.
Best practices for building large React applicationsMay 7, 2015 5:41 pm
Sift Science has been using React in production for almost a year now. In that time, we grew our application from a Backbone + React frankenstein hybrid app into one fairly large hierarchy of React components. In this post, we’ll describe some techniques and best practices that have helped us scale our UI code base with minimal friction. We’ll also walk through some common component design patterns.Hopefully this post will save you time and sanity and provide you with some new tools for maintaining a React code base that builds on itself (instead of breaking down) as the complexity of the UI grows.