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.
I'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.
Clubhouse is pretty sweet, I feel like it's basically Pivotal Tracker done right. Fast enough to not get in the way but flexible enough for most workflows. We're a pretty small company though, I don't know if something like JIRA becomes more necessary as the company scales.
We never used Asana, but moved from Trello to Clubhouse as well after we outgrew Trello's simplicity. Clubhouse has been awesome so far, and generally loads quickly
Thats probably dependent on the hardware and size and complexity of workflows and DB size. Our JIRA install is one of the slowest webapps i've seen in a while. Can't wait to move on to something else.
It varies widely. We have ~300 users, 30 projects, probably on the order of ~20k tickets. Performance has been up and down, occasionally things slow way down and we have to file a ticket and then they come back with some excuse about re-indexing or relocating the instance. Normally it's pretty acceptable, but it feels like there are a ton of a variables that go into its performance day-to-day and minute-to-minute.
I'm at a medium/large company, but without access to real numbers i'd say off the top of my head its probably >500 users across 100+ projects and 10s of thousands of issues.
That seems bananas to me, because JIRA is literally the most painfully slow application I've ever used in my entire career. We use their hosted version, though.
Do you host your own JIRA instance and have somebody in charge of running/tweaking it?
For me the slowness of JIRA means I loathe going into it. It feels soooo clunky, so 90s in performance and UX. I’m moving to JIRA from trello and it’s night and day. Even something as basic as having a notification inbox with read markers is a paid plugin for JIRA, and everything else seems to require many many clicks (each with their own several second load time). It’s horrible.
I keep going back to Trello for my todo/issue needs. With stuff like Zapier it goes from being simple yet powerful to goddamn nuclear. But I have to be honest here and say that I've never experienced Asana as slow (it's underlying model just doesn't work for me).
For example, create cards based on email sent to gmail or order cards sent to woo commerce. I have barely scratched the surface of what Trello+Zapier can do but I'm pleasantly surprised that there are tons of ready made 'zaps' for all kinds of app combos.
Also not OP, but we've been using dapulse. Terrible name, but it's been working great. It has similar concepts to asana and trello. It loads fast and easy to use.
Asana was ridiculously simple when we started using it, and I was incredibly happy with it. Then they kept adding, adding and adding irrelevant things, and now I'm pretty put off by it. I wonder if this is a cycle, and a new 'brand-new asana' alternative will spring up soon.
Page load performance is still a top focus of the company. While page load has improved significantly over the last six months, we know it has a long way to go. Our two largest performance issues are initial HTML time and bundle evaluation time. We're actively working on a solution to both of them.
Those may be your biggest challenges but he is suggesting that even once it is all loaded it is slow. That should probably take priority over initial load time for an application people are likely to keep open all day. Just look at how long gmail takes to load, it is like forever but doesn't matter nearly as much as how quick it is once loaded.
Thanks for pointing that out. Our belief is that the majority of in app actions are now fast but that there are still exceptions. We're constantly trying to find new exceptions and remove them. Hopefully this thread alerts us of new ones.
Curious: What's your strategy for measuring application performance? Would love to hear more details on how you're tracking the effect of your efforts.
At a high level, we try to collect real user metrics for everything we can. Interana helps us analyze that data in near real time. For more detail, I hope we can write a blog post soon to answer your question.
In my personal experience Asana is still the snappiest. I've tried Trello, Basecamp and daily use the monstrosity called JIRA. Asana initial load takes a little while, but it hasn't created any problems for me. I always have Asana pinned in my Firefox.
There’s now this dev myth that everything is faster in chrome. Not so anymore. I wish more people would take other browsers more seriously. Personally I find safari the fastest on my Mac, and prefer its font rendering as well.
We just started using Asana a couple of months ago, but we're not seeing the performance issues some other folks are mentioning. I just hit Asana full refresh and it took 2-3 seconds to render all of the components in My Tasks. It seems pretty snappy in my opinion. Asana with a few Zaps has been great. Because I know they're watching...could you guys add a calendar view to the iOS app? =)
Not asana related (or even working in this area) but this piqued my curiosity, would you be able to answer a couple questions? My contact info is in my profile.
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.
I 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.
Thanks 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?
It looks like a standard dark pattern in React, you are re-rendering more components than needed on certain inputs changes, you should ask him in which input he's typing, it would probably more useful than his user name
You're right, it's not really germane to the primary topic of conversation in this thread, but thank you for noticing and pointing it out anyway. Fwiw, I'm a "she".
It doesn't happen all the time - seems to be intermittent, but when it's happening, it'll go on for several minutes at a time. When it does happen, the activity monitor shows the browser process using basically the entire CPU.
Sometimes but not always, reloading the page fixes the problem; it does seem to be more likely to happen when the page has been open for an extended period, but sometimes the problem persists after a fresh page load. (There's one project that I use to organize most of my work, and I'm liable to leave that tab open to that project without reloading or even changing the sort/filter for weeks on end.)
What seems to happen is that memory usage spikes (by as much as 100 MB) alongside CPU usage while the typing lag is occurring, and then it drops back to baseline as soon as the text is displayed properly.
We 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.
I 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.
Thanks for the advice! We believe that users remember the slowest actions as well. Your strategy sounds like it will help identify the long tail of rare yet slow actions.
"Tracer bullets". Have a flag that can be put on an action that causes it to be logged very verbosely. In a way that travels through your system. And then aggregate those logs, process them, and make them available. Then randomly tag a small fraction of actions with that flag. Like 0.1%. Because you do this relatively rarely, you can make verbose logs without overwhelming your system.
When you receive a complaint about foo occasionally being slow your first stop is to see if you've got a concrete action that was slow, look at the picture from the logs, and try to figure out why. This will greatly help in reproducing rare problems or, if you can't, at least identifying where they come from deep in your system.
The 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?
I once heard a story about a manager who let it be known he would give out 20$ if people used product management tool X. During one meeting, someone pulled up a note on said tool and he handed them a crisp 20$. A few more instances of that and everyone was using it. Or so the story goes...
> How did you implement those tools in your company?
You have to remember that tooling isn't valuable for its own sake. A chainsaw is much more powerful than a knife, but it's the wrong tool when you're sitting down to dinner.
Getting new tooling adopted in the enterprise is about sitting down with your users, understanding what their goals are, understanding where their current pain points are, and showing them how the tooling will help them achieve their goals and solve their pain points, oftentimes requiring close, high-touch support and adaptation to get that done.
If you can't sell the tooling on its own merits to people in your company, you have no business mandating its use.
> If you can't sell the tooling on its own merits to people in your company, you have no business mandating its use.
That assumes that a) such dept has the capacity to understand the advantage of using such tool and b) other depts have time to go and try to sell them that.
You 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.
They 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.
I've dealt with this in the past and am dealing with it again with a very simple trello board.
"What is the status of issue X?"
"What is the IssueID?"
"I didn't create one"
"Create an new entry in the tracker and we can all track progress of issue X"
Repeat as many times as necessary.
edit: I also try to create a trigger or other automatic action in the tool. For example, our issue tracker updates the release notes when items are modified or marked as completed. If you can get people to use the triggered tool it will create an incentive.
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. https://my.mixtape.moe/qpziak.png
Here's a video of the Laszlo Webtop Calendar 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.)
Can 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?
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.
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?
I 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.
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?
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.
We 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.
Sure. 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.
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.
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.
Interesting, 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?
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.
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 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.
Thanks! 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.
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!
Thanks! 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.
We 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.
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.
I 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).
"[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?
The 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.
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?
Both look interesting, although clearly Luna2 is the evolved version. I would definitely enjoy a post on your sync strategy! Thank you for being so open!
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.
I 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/
> 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.
