
Treating performance as a product: The technical story of Asana’s rewrite - pspeter3
https://blog.asana.com/2017/08/performance-asana-app-rewrite/
======
spollo
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.

~~~
infecto
This 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
I appreciate that you're not trying to advertise for their competitor, so I'll
be that guy... What did you switch to?

~~~
infecto
We moved to JIRA. Lost the simplicity but its a lot snappier and I believe
there was some organizational benefits as the company grew.

I am happy that I can click a JIRA link and see a page within a second.

~~~
ugh123
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.

~~~
morj239
Would you mind sharing the approximate number of issues and active users in
your JIRA install?

~~~
dasil003
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.

------
twobyfour
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.

~~~
pspeter3
This is already in production for most views. Can you elaborate on your
issues?

~~~
twobyfour
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.

~~~
pspeter3
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?

~~~
riquito
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

~~~
azinman2
Not trying to start a flame war, but do you know for sure “he” is a “he”?

~~~
twobyfour
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".

------
pier25
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?

~~~
ec109685
If the boss says use X, they refuse?

~~~
pier25
No, they use it the first day, and then progressively less. Since this has
happened a few times with different tools management has abandoned hope.

~~~
devopsproject
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.

------
dqv
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](https://my.mixtape.moe/qpziak.png)

~~~
pspeter3
That definitely looks like a bug. Thanks for reporting!

------
osteele
Here'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
My cat's name is Computer. (Adopted, came with the name.) Not great for naming
my frontend framework though.

------
pspeter3
Hi, I'm Phips and I'm one of the engineers behind Luna2. Please let me know if
you have any questions!

~~~
brokenbyclouds
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?

------
rkwasny
After 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)

------
romanovtexas
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?

~~~
sethammons
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.

------
BIackSwan
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.

[1] - [https://medium.com/@addyosmani/progressive-web-apps-with-
rea...](https://medium.com/@addyosmani/progressive-web-apps-with-react-js-
part-2-page-load-performance-33b932d97cf2)

~~~
pspeter3
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.

~~~
BIackSwan
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.

~~~
pspeter3
Sounds great and inline with our thoughts. I'd love to see a blog post with
more detail when it works!

------
otterpro
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.

~~~
twobyfour
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?

------
dirtyaura
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.

~~~
awhitty
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.

[0]: [https://heap.engineering/migrating-react-mobx-while-
shipping...](https://heap.engineering/migrating-react-mobx-while-shipping-new-
features/)

------
pcx
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!

~~~
pspeter3
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.

~~~
pcx
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.

------
jwilliams
"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
Thanks for your kind words! It took a lot of effort but we're happy with the
result.

~~~
azinman2
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).

~~~
pspeter3
We'll try to turn this into a blog post. It definitely is a skill that takes
practice.

------
aaronbrethorst
"[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
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.

------
mystruggle
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.

~~~
ec109685
What are some examples?

------
andr
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?

~~~
pspeter3
Were you looking at the XHR (Luna) or WebSocket (Luna2)? We can do a follow up
blog post on sync if you're interested.

~~~
andr
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!

------
sitkack
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.

------
deathtrader666
Just wondering what are your team's thoughts on Elm?

~~~
pspeter3
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/](https://blog.asana.com/2014/11/asana-switching-typescript/)

------
rmrfrmrf
Looks like a paragraph is repeated in the article.

------
valuearb
Is the UI still terrible? That's why I dropped it.

------
latchkey
Just use Pivotal Tracker and be done with it.

------
hitgeek
i 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.

------
grwthckrmstr
I like Google keep. It's fast :P

------
hasenj
> 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.

