I 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.
Is 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.
The problem we face at my company is that it's very difficult to get people to use these kind of tools.<p>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.<p>How did you implement those tools in your company?
If 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. <a href="https://my.mixtape.moe/qpziak.png" rel="nofollow">https://my.mixtape.moe/qpziak.png</a>
Here's a video of the Laszlo Webtop Calendar <a href="https://www.youtube.com/watch?v=97KLyHzpkro" rel="nofollow">https://www.youtube.com/watch?v=97KLyHzpkro</a>, 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.)<p>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.)
After using Asana/JIRA/Service now for some time I switched to simple issue tracking in self-hosted Gitea.<p>No javascript framework to load, page loads are measured in milliseconds. It maybe has 10% of functionality but it "just works"(tm)
It'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.<p>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.<p>Is this only due to the crazy front-end and JS frameworks world or am I missing something else here?
Question 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?<p>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.<p>[1] - <a href="https://medium.com/@addyosmani/progressive-web-apps-with-react-js-part-2-page-load-performance-33b932d97cf2" rel="nofollow">https://medium.com/@addyosmani/progressive-web-apps-with-rea...</a>
The 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.<p>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.
A 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.<p>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.
I 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!
"The final principle was simple over easy."<p>This is a great principle and really good to see in this article.<p>Usually when I've seen rewrites it <i>goes the other way</i>. There is some simplistic component that gets rewritten in some new language/framework/etc and end up being much more complicated.
"[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."<p>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?
Something 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.
I 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?
Bad 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.
> When we started development in 2009, few rich web applications existed. And with so few examples, there were no best practices to follow.<p>I think what you need is not best practices. You need principles.<p>If you take performance as a matter of principle from the get go, you will never ever ship a slow product.<p>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.<p>Another thing they seem to value is _perceived_ ease of development, at the <i>expense</i> of performance.<p>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.