12 ms·
Treating performance as a product: The technical story of Asana’s rewrite
- pspeter3 9y agoHi, I'm Phips and I'm one of the engineers behind Luna2. Please let me know if you have any questions!
- brokenbyclouds 9y agoCan you say anything about the challenges involved in creating a unified My Tasks view that shows all your tasks across all organizations to which you belong?
- twobyfour 9y agoIs this already in production? Because until a few months ago, Asana's network performance was crap. Now it's just mildly bad, but the UI has become almost unusably slow.
- pspeter3 9y agoThis is already in production for most views. Can you elaborate on your issues?
- twobyfour 9y agoI type a sentence into the UI and it takes about 30 seconds for the text to appear, one character at a time. If I click anywhere else before the text has finished displaying, the text input continues from there, resulting in bizarre fragmentation. Scrolling jumps under my mouse. It sometimes takes 3 or more tries for the UI to register that I've gripped a handle to drag a list item to a different location in the list. This is in the latest Safari on a recent Mac laptop on a symmetric 50mbps connection.
- pspeter3 9y agoThanks for letting us know. That sounds like an exceptional case from our metrics. Would you be willing to share your Asana user ID so we could learn more?
- kevan 9y agoOut of curiosity, are you watching percentiles or averages in your metrics?
- pspeter3 9y agoWe used to track percentiles but discovered Asanas struggled to empathize with them. We switched to defining semantic performance bands (eg < 100ms, < 300ms, < 1s, < 3s, < 5s, < 10s). For each action, we track the percentage per band. Asanas seemed to empathize better with time as the independent variable and percentage as the dependent variable.
- f1notformula1 9y agoCan you elaborate on what an Asana is and what "empathize" means? I'm not an Asana user, so perhaps I'm unfamiliar with the jargon.
- btilly 9y agoI would also suggest that you do the same with a metric for "slowest action in 15 minute period of user input". 99% of actions are fast but you have hundreds of actions over 15 minutes, people will notice those slow ones.
- deathtrader666 9y agoJust wondering what are your team's thoughts on Elm?
- pspeter3 9y agoI deeply respect Elm and think many other teams members do as well. The fractal architecture concept was one of the influences to how we write Luna2 code. My main concern with Elm for Asana is long term risk. Choosing Elm means choosing a framework and a language. You can see more of our thoughts here: https://blog.asana.com/2014/11/asana-switching-typescript/ https://blog.asana.com/2014/11/asana-switching-typescript/
- spollo 9y agoI can't believe they are patting themselves on the back for performance. I'm running a brand new macbook pro, latest chrome, fiber internet AND asana fully cached. It still is a 6 second initial page load and then every single UI interaction is slow, slow, slow. My entire companies biggest pain point with asana is how insanely slow it is for a simple product.
- infecto 9y agoThis was my largest gripe with Asana and why I was so happy when we moved away from it. The simplicity of Asana is nice BUT the web app is terrible in how bloated it feels. I hated clicking Asana links to a task because it would have to load the entire app and wasted what felt like so much time.
- kbd 9y agoI appreciate that you're not trying to advertise for their competitor, so I'll be that guy... What did you switch to?
- maccard 9y agoNo affiliation, but even jira is snappier than asana for me.
- aantix 9y agoBurn!
- pkaeding 9y agoI'm not the GP, but we went through a similar journey here, and after ditching Asana, we went to Todoist, which is nice in its simplicity (and fast). Sooner or later, the simplicity became too simple, so we switched to Clubhouse, where we are now. It is serving us well. Presumably, one day, we will outgrow that, and need to go to JIRA (with all of its power and complexity), but it would be nice to delay that inevitable as long as possible.
- dirtyaura 9y agoA great writeup! A lot of startups face the situation that you need to do significant architectural changes to pay the technical debt and re-enable development speed, or improve the performance and scalability of the service. At the same time, stopping feature development altogether for months is impossible. Incremental rewrite is often the only way to go. I liked how you approached the rewrite with adapters. I'd be very interested if somebody would collect these kind of "rewrite war stories" to a book form and maybe synthesize common patterns from the stories.
- pspeter3 9y agoThanks! We would have really appreciated a resource like that when we started the process. We wanted to share our story in case it is helpful to others.
- awhitty 9y agoI would love a resource like that! We went through a very similar process on my team [0], and I was pleased to see this post validating some pain points we had seen. > In hindsight, we chose the correct trade off. This is key, and I think it's almost something you have to blindly follow when going into the transition. It's a lot easier to justify the decision to incrementally rewrite in retrospect than it is to get excited about it in the process. I think more examples would help shift that. [0]: https://heap.engineering/migrating-react-mobx-while-shipping-new-features/ https://heap.engineering/migrating-react-mobx-while-shipping...
- pcx 9y agoI wish Asana had better support for Sprint cycles. Otherwise, I just love using it. The only task management tool I've actually ever liked. I've tried several popular ones - primarily Trello, JIRA, Basecamp & GitHub Issues. Kudos for the rewrite, hope you folks continue improving it!
- pspeter3 9y agoThanks! Our hope is that Luna2 enables developers to more efficiently improve the product. While performance is still a top priority, more engineers can now focus on the product experience.
- pcx 9y agoWe are facing a similar situation in my company. Our current stack (just React) is not able to handle the complexity of the project, and refactoring existing features or building new ones has been a pain. We are slowly but gradually moving the code to React + Redux + Flow. We are already seeing gains with this move.
- brokenbyclouds 9y agoClickUp may be worth a look for you
- hitgeek 9y agoi haven't used asana in a couple years. I just signed up for a new account, and it seemed pretty snappy. I might give it a try again.
- jwilliams 9y ago"The final principle was simple over easy." This is a great principle and really good to see in this article. Usually when I've seen rewrites it goes the other way. There is some simplistic component that gets rewritten in some new language/framework/etc and end up being much more complicated.
- pspeter3 9y agoThanks for your kind words! It took a lot of effort but we're happy with the result.
- azinman2 9y agoI would love to see actual examples of this. It’s something that sounds interestint in theory but difficult to know how to render into practice (especially to validate that is the correct priority).
- pspeter3 9y agoWe'll try to turn this into a blog post. It definitely is a skill that takes practice.
- p4lindromica 9y agoSimple in interface or implementation? One is MIT, the other is New Jersey.
- rkwasny 9y agoAfter using Asana/JIRA/Service now for some time I switched to simple issue tracking in self-hosted Gitea. No javascript framework to load, page loads are measured in milliseconds. It maybe has 10% of functionality but it "just works"(tm)
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- BIackSwan 9y agoQuestion out of curiosity. Since Asana has started using react - are you using route based chunking/code splitting[1] to significantly speed up page load times? We have started using it for some pages (with some complex UI flows) and it has sped up the page load times by an order of magnitude. Makes the first interaction super snappy while the other stuff loads in the background. [1] - https://medium.com/@addyosmani/progressive-web-apps-with-react-js-part-2-page-load-performance-33b932d97cf2 https://medium.com/@addyosmani/progressive-web-apps-with-rea...
- pspeter3 9y agoWe have not yet but it is the goal we're working towarss. Migrating our legacy Luna code to be compatible with "use strict" and not rely on implicit global variables has been a grueling endeavor. We're actively testing a Webpack based bundle in production right now. If that works, we'll start testing both chunking and code splitting. Do you have any data on the page load performance improvements? We would appreciate any insight.
- BIackSwan 9y agoSure. We are a B2C company. We have multiple customer flows to place orders on our website. Majority of our users use mobile phones to place orders. Thus, performance of our webapp on mobile is critical. Our users have slow 3G connections to access it. And we ran experiment to speed up one of flows to use route based chunking/code splitting. We got a 10x improvement. The uncached gzipped page load speed went from ~30s to ~3s on a 3G connection. We used chrome's throttling (both network and CPU) feature to test and build the app. We had to modify our user flow a bit to allow render the first page super fast, but it was well worth the tradeoff. The biggest reason of the speed up was just the smaller initial bundle size (the first chunk only contained react and react-dom plus the first component to render) and the fact that the render only needed that to get started with the first paint. There is still the problem that the other chunks are not loaded until the subsequent components are actually asked to be rendered - so now we are working on a way to asynchronously preload the other chunks in the background while the user is interacting with the first component, thus making the subsequent interactions super fast. Still a WIP though.
- pier25 9y agoThe problem we face at my company is that it's very difficult to get people to use these kind of tools. My team is remote so we use slack and other apps all the time, but getting customer service or other depts to use a simple chat is difficult. Implementing something like Asana or Basecamp is impossible. How did you implement those tools in your company?
- ec109685 9y agoIf the boss says use X, they refuse?
- flukus 9y agoYou aren't wrong, but tools people hate will get used as little as possible. With Basecamp for example, people might create tickets but then all the discussion about them is done via email rather than the ticket itself. It's enough to not get fired but still an overall poor result for the company. A little while ago I wrote some docs for a project, a simple markdown readme basically, but the boss decided that all documentation has to be in sharepoint, so I converted it to a word doc and threw it in sharepoint. My takeaway lesson was not to not document anything though because I hate using sharepoint and Word for. A top down command like "use x or get fired" isn't particularly helpful, making the right thing to do the easiest thing to do generally is though.
- jmiserez 9y agoThey may say yes, but then still use backchannels like email and phone to get things done. Which makes the items on the platform out-of-date, underused, or plain wrong. And items people actually put on the platform won’t get done or updated without also writing emails or calling. It takes time to get everyone on board, but if the platform works well people will change.
- pier25 9y agoNo, they use it the first day, and then progressively less. Since this has happened a few times with different tools management has abandoned hope.
- aaronbrethorst 9y ago"[B]uilding a native application for each platform was untenable for our size at the time. As a result, we...developed an in house versions (sic) of Firebase, RxJS, and React." Something tells me that shipping a macOS app, a Windows app, and a decent web client would've been easier than what they did. So what's the real story? Did the scope of the project keep getting bigger, and they stayed the course due to loss aversion?
- pspeter3 9y agoThe statement was for 2009 when we had ~5 employees. I'm not sure what the timeline would look like if we had chosen the path you suggested. It does seem likely that we could have avoided an incremental rewrite. As mentioned in the post, a large reason for the rewrite was the tight coupling of UI and data fetching code.
- osteele 9y agoHere's a video of the Laszlo Webtop Calendar https://www.youtube.com/watch?v=97KLyHzpkro https://www.youtube.com/watch?v=97KLyHzpkro, from 2008. This was written in a hybrid of XML and our own dialect of JavaScript, that compiled either to Flash byte code, or to a subset of JavaScript compatible with major browsers. (JavaScript in 2008 was nowhere near as healthy as it is now.) The reason I mention this, apart from the similar time frame and similar-ish functionality, is “They named the framework Luna (after Dustin’s cat).” The Laszlo company and framework were named after our Peter's cat. (The cat, in turn, was named after László Moholy-Nagy.)
- c_r_w 9y agoMy cat's name is Computer. (Adopted, came with the name.) Not great for naming my frontend framework though.
- dqv 9y agoIf anyone from Asana is out there, the fonts on your site look /very/ weird on my machine - Debian 9.1, Chrome 60.0.3112.78. https://my.mixtape.moe/qpziak.png https://my.mixtape.moe/qpziak.png
- otterpro 9y agoThe slow loading speed was definitely the primary reason that I stopped using Asana. I just tried Asana today on Firefox, and it felt faster than before, or at least the perception of it was faster. I hope that they work to optimize the iOS app as well. I know the op is about web and not iOS app, but iOS app is just painfully slow, and takes awhile to load a simple page with 1 single task! My other gripe is that it won't work in off-line mode, when I don't have internet access. Anyway, being slow really ruins the user experience.
- twobyfour 9y agoInteresting, I for one find the iOS app very snappy and the web version often unusably slow. And the iOS app does work offline too. Have you upgraded recently?
- valuearb 9y agoIs the UI still terrible? That's why I dropped it.
- mystruggle 9y agoSomething is not right about asana. This article is so filled with buzzwords and meaningless "values", "principles" that I want to puke. Even in this industry, I've never heard anyone talk like this, except when I attended an asana hiring info session a few months ago.
- ec109685 9y agoWhat are some examples?
- romanovtexas 9y agoIt's kinda surprising how frequently rewrites occur across tech companies; considering rewrites can essentially stop the development of any new features in the product. I was recently part of one such huge rewrite, albeit it was truly necessary since we were porting from a 1970s COBOL based Mainframe to a Java based Middleware solution. This rewrite itself caused blocked any other development projects for the last 6 months and sucked in a lot of resources. Isn't sticking to a stable tech stack that helps run production smoothly and let the developers have their peace of mind better? Rewrites might be essential, but only in the cases where your technology is seriously ancient. Is this only due to the crazy front-end and JS frameworks world or am I missing something else here?
- sethammons 9y agoI can't speak for every case. At my work, we've done some rewrites. On the back end, we've seen 20-100x improvements in performance and the code is easier to maintain after switching many projects from Perl to Go. On the front end, we had to switch because the framework was no longer getting security updates (simple js and html from a symfony back end to an API driven SPA). I can't talk to the benefits of the front end rewrite aside from allowing us to dog food our APIs and allowing the front end teams to use tooling of their choice.
- rmrfrmrf 9y agoLooks like a paragraph is repeated in the article.
- latchkey 9y agoJust use Pivotal Tracker and be done with it.
- grwthckrmstr 9y agoI like Google keep. It's fast :P
- andr 9y agoI did a quick Inspect in Chrome and noticed that instead of doing request/response, the server is sending a list of everything that has changed since the last request (or at least it appears so). Do you care to talk more about your client/server API design?
- hasenj 9y ago> When we started development in 2009, few rich web applications existed. And with so few examples, there were no best practices to follow. I think what you need is not best practices. You need principles. If you take performance as a matter of principle from the get go, you will never ever ship a slow product. Most startups nowadays seem to value design more than performance. They even value the design of their landing page more than they value the design of the actual product. Another thing they seem to value is _perceived_ ease of development, at the expense of performance. I say perceived because, in my experience, what you may perceive initially as a productivity boost ends up becoming a productivity burden as the code size grows.
- sitkack 9y agoBad performance is a misfeature. Performance as a product would have to either put you below the limits of perception -or- 10x faster than the closest competition.