Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our long term plan to make GitLab as fast as possible with Vue and Webpack

about.gitlab.com

Post reply on HN
Print view View original

191–200 of 304 posts

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#191

Post by sb8244 »

justinlaster wrote: post #187
sb8244 wrote: post #185

Earlier quoted context omitted.

I don't understand this. You could build up the template using jsx exactly like you could otherwise. For instance, I could put that in a variable and then use it in another template via {}

You could , but it's unintuitive (in my opinion) to do so -- which was the parent's comment larger point. You're not doing anything different, and to an extent the latter is actually lying about what's going on (you're not writing HTML). I also lose a certain level of tooling by doing it the JSX way. Why try to mask what you're doing? Why make it harder for your tools to help you out?

I guess I haven't felt this pain that you've felt. I'm satisfied with my tooling and feel that small components help keep things very clear and focused.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#192

Post by lhorie »

j_r_f wrote: post #176
duncanawoods wrote: post #116

Earlier quoted context omitted.

JSX frustrates me. When did we suddenly start thinking syntax was desirable again? When did the complexity of combining markup syntax and a programming language become a good idea? Why are we forcing this crazy complexity into every language and every IDE / code editor out there? I much prefer react with standard functions e.g. var element = DOM.p({id : "thing"}, DOM.div(), DOM.div()); You can use an API like this in…

I think you are being a bit overdramatic about JSX. There was zero learning curve -- except for a few errors initially when using class instead of className... The argument that DOM.div() is more readable than is honestly hilarious to me. Any non-trivial tag structure will be unnecessarily complicated through the API. Especially when you can just write it almost exactly how it's going to look when it becomes HTML in…

DOM.div() vs seems like a bad example. IMHO, when you get an element with tons of event handlers and conditional classes, or when you have a deep chain of ternaries that's where angled bracket syntax starts to become unwieldy.

The className thing is a big deal too, in my opinion. Preact and Mithril do what you would expect, and perf doesn't suffer, so why can't React/JSX normalize it as well?

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#193

Post by mattmanser »

duncanawoods wrote: post #139
hacker_9 wrote: post #135

Earlier quoted context omitted.

I'm a C# guy and even I would say the JSX is far more readable there. I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case.

I don't mind if people prefer JSX its just a shocking cost - rewriting language ASTs, build tools and IDEs for something that rhymes with html but is really only a couple of characters away from standard language constructs. > I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case JSX is literally an extra level of abstraction. You are not writing html but calling…

In my experience, using a programming syntax for markup actually turns into a PITA. My only experience is HTML + Silverlight, but in both instances doing it in markup over code is almost always easier/quicker/simpler to read/less TLOC.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#195

Post by RobertoG »

chalupa-man wrote: post #129
StavrosK wrote: post #46

Earlier quoted context omitted.

Isn't elm a language? Why compare it with frameworks?

Elm is a language, but it's sort of automatically a framework as well. There's a function in the standard library called Html.program that takes four functions as arguments and returns a React+Redux style application from them. The Elm runtime exists solely in the browser and expects your main function to return some HTML, which it will display using a virtual DOM. They call this pattern 'the Elm Architecture' (TEA)…

Your comment should be incorporated to the Elm documentation. Thanks for it.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#196

Post by byroot »

jblok wrote: post #174
jakecodes wrote: post #151

Earlier quoted context omitted.

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 h…

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.

The browser will still have to parse and execute it. That where Turbolinks can improve performance.

It comes with it's own drawbacks though.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#197

Post by pluma »

Touche wrote: post #180
ythn wrote: post #177

Earlier quoted context omitted.

I'm assuming in the web dev world "legacy codebase" is used very loosely here. In my company, "legacy codebase" is referring to C code from the 70s that is still ticking today.

That's right, in the web dev world "legacy codebase" is 3 or 4 years old, created by a previous team who all quit once they finished the rewrite of the previous "legacy codebase".

In my experience there's no time limit for "legacy". It pretty just means "code we have to maintain that we would like to replace" these days.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#198

Post by [deleted] »

jorblumesea wrote: post #38

I really think for most cases you only need a view library instead of a heavy application framework. There are only a few cases there something as heavy as Angular or Ember is justified and in many scenarios a thinner view layer like Vue, React, Inferno etc is much better suited. Most of the web is simple enough to not need fancy http features or complex routing support. Everyone rushed to Angular without considering…

[deleted]

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#199

Post by merb »

jobvandervoort wrote: post #161
randallsquared wrote: post #150

Earlier quoted context omitted.

GitLab CI is even slower than Jenkins? It's been on my list of alternatives to evaluate, but I guess I'll just push it further down the stack...

I'm not sure why anyone would say GitLab CI is slow. You run it on any machine you want, so it's fully dependent on that. The script that authenticates and picks up the job is a small Golang app. That's all. GitLab executes CI jobs immediately. See the architecture and related links here: https://about.gitlab.com/gitlab-ci/#architecture

well gitlab ci is slower on our machine than jenkins. also push based ci might be better for performance when having many workers. while gitlab ci is pull based which can net in negative performance. of course pull based is way less painful when nodes go down/etc..

actually the biggest problems of slowness also comes from docker and caching. I think our docker setup for jenkins/gitlab-ci is not equal. for some jobs we will probably migrate away from docker, as soon as we are able to have a good story for running parallel tests.

Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack

#200

Post by strken »

jblok wrote: post #174
jakecodes wrote: post #151

Earlier quoted context omitted.

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 h…

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.

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.

Post reply on HN