4 ms·

> 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 d

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

eberkund 10y ago
Honest question, how do you know that it's the frontend that's slow and not the backend?
- wldlyinaccurate 10y ago
  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/ 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 10y ago
    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 10y ago
    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 https://gitlab.com/gitlab-org/gitlab-ce/issues/23213.
    - wldlyinaccurate 10y ago
      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?
swsieber 10y ago
Isn't that more a symptom of their back end though, and not their js?
jakecodes 10y ago
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.

eberkund 10y ago

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

wldlyinaccurate 10y ago
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/ 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 10y ago
  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 10y ago
  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 https://gitlab.com/gitlab-org/gitlab-ce/issues/23213.
  - wldlyinaccurate 10y ago
    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?

swsieber 10y ago

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

jakecodes 10y ago

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.