Treating performance as a product: The technical story of Asana’s rewrite
blog.asana.com
blog.asana.com
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.
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.
Disclosure: I have suggested few features for Restyaboard and its developers implemented them.
I am happy that I can click a JIRA link and see a page within a second.
Do you host your own JIRA instance and have somebody in charge of running/tweaking it?
Switched the Trello. Never been happier.
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.
"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.
Using store state vs local state shouldn't matter much, as long as your components are pure and only pull what they need from the store.
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.)
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?
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.
"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.
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.
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.
Users always resist change.
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.)
No javascript framework to load, page loads are measured in milliseconds. It maybe has 10% of functionality but it "just works"(tm)
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?
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...
Do you have any data on the page load performance improvements? We would appreciate any insight.
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.
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.
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.
> 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...
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.
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?
I just signed up for a new account, and it seemed pretty snappy. I might give it a try again.
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.