News for hackers. Stuff that matters.

A comment on Our long term plan to make GitLab as fast as possible with Vue and Webpack. Parent comment

Re:Our long term plan to make GitLab as fast as possible wit... by jakecodes on Tuesday February 07, 2017 @07:53AM (#13589003)
Our entire JS is 800kb not each page. So we are splitting it on a per page basis. Everything including issues, MRs, file browsing. There was 800kb of JS in the entire app before I joined as the first FE Eng. There is jQuery and other libraries and our own code. That was the reason we wanted to remove Turbolinks. So we don't load all the JS for the entire app at once. We want to load things on demand.

Funny thing, I have built a full fledged production 2d/3d application in JS. It was less complex than what GL has to do, and it was 670kb fully minified and obfuscated. We are constantly looking for ways at GL to make our file size smaller and our JS faster. It is something we are actively putting our time towards.

[ Parent | on HN ]
Re:Our long term plan to make GitLab as fast as possible wit... by jblok on Tuesday February 07, 2017 @09:14AM (#13589449)
Why do you need to use Turbolinks, when you can just do a normal page load, and set the correct cache headers for your javascript bundles, to stop the browser re-downloading the same script.
[ Parent | on HN ]
Re:Our long term plan to make GitLab as fast as possible wit... by strken on Tuesday February 07, 2017 @10:28AM (#13589932)
This isn't specific to GitLab or GitHub, but turbolinks, pjax, and friends are really useful when you have a lot of setup that can be shared between pages, i.e. initiating a websocket connection, rendering a header with notifications and an avatar in it, decompressing and parsing your js and css, etc., and you don't want to implement a single page app.

When I refresh the GitLab sign-in page in Chromium, I see that the initial page load takes 40ms to parse css, 250ms to parse and execute js, and then another 70ms after DOMContentLoaded. This is with a warm cache. It's not unreasonable to think that turbolinks might save about 300ms on page loads, which is a respectable performance boost.

[ Parent | on HN ]
Re:Our long term plan to make GitLab as fast as possible wit... by byroot on Tuesday February 07, 2017 @10:16AM (#13589853)
The browser will still have to parse and execute it. That where Turbolinks can improve performance.

It comes with it's own drawbacks though.

[ Parent | on HN ]
Re:Our long term plan to make GitLab as fast as possible wit... by connorshea on Tuesday February 07, 2017 @03:51PM (#13592674)
Actually we just removed Turbolinks the other day, so this is a non-problem. :)
[ Parent | on HN ]