[antarrah]

> He pointed out that when a major software company releases a their secret sauce, there is going to be hype. Devs think to themselves,'That company writes JS differently than me, and they are prominent and successful. Is their way of writing JS better than mine? And therefore must I adopt it?'

Ahaha. No, believe me I'll not. That's ironic coming from GitLab. I mean I love that company but their front-end sucks big time and it's slow as a snail.

[swsieber]

Isn't that more a symptom of their back end though, and not their js?

[eberkund]

Honest question, how do you know that it's the frontend that's slow and not the backend?

[wldlyinaccurate]

You only need to look at a DevTools timeline to see that it's the front-end which is slow: https://www.webpagetest.org/result/161021_08_XZF/

600KB of CSS, 800KB of JS... That's fine on your MBP over WiFi but on most pages it locks up the main thread on my phone for a good 5-10 seconds.

[sangnoir]

Slow to load and slow are 2 very different things. If you look at the payload timing when comparing 2 branches, you would come to the conclusion that the back end is slow.

[jakecodes]

Hi wldlyinaccurate, thanks for your comment. There are a lot of frontend performance things we are focusing on for the next release. https://gitlab.com/gitlab-org/gitlab-ce/issues/23213.

[wldlyinaccurate]

Cool, I'm glad to see there's a meta issue to track this stuff now. Couple of questions:

Is there a strategy to tackle the CSS and JS bloat?

Is performance something the front-end endboss folk consider important enough to delay feature releases?

Are you monitoring performance with a tool like SpeedCurve?

[jakecodes]

We are constantly working on improving our frontend, and have big plans ahead, so I'd be really interested in hearing what "sucks big time" so we can fix it.