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

101–110 of 304 posts

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

#101

Post by GeneralMaximus »

vog wrote: post #83
rdsubhas wrote: post #78

Earlier quoted context omitted.

Two-way binding I guess. Once we get used to one-way binding and immutable data structures, anything else feels indeterministic. (Note: Just guessing what the commenter might have written. I'm a long-term VueJS user)

This. I just had a look at Vue and everything looked fine so far, until they started with two-way-bindings. Two-way-binding failed already long before the web and SPAs. Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Not sure why frameworks keep repeating this well-known anti-pattern. I'd prefer framworks like React or Riot any time over two-way-bin…

> Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises.

Can you elaborate on this? The last time I wrote a native application was 6 or 7 years ago using Cocoa and Objective-C. If I remember correctly, Cocoa had a mechanism that was similar to two-way binding. Have things changed recently? What do modern iOS/Mac applications use?

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

#102

Post by gtaylor »

jabl wrote: post #90
ZenoArrow wrote: post #71

I'm not aware of the performance bottlenecks with GitLab, but are there any plans to speed up the backend as well, such as moving to a faster Ruby implementation?

There's another github/gitlab clone called gigs that's implemented in go. Never used it myself, but if you want to save server resources I guess it's an option.

*Gogs

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

#103

Post by rkwasny »

Something went terribly wrong in our field ....

"On GitLab, our pages would load an average of 20kb on each page load versus the full JavaScript file size of 800kb+."

What exatly takes 800kb? I don't see a 3d animation/game on every gitlab page...

IMHO the solution to all this craziness is just generate small mostly-static page quickly and do not have 200 onLoad() functions.

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

#104

Post by realharo »

merb wrote: post #93

Sadly I think the problem of GitLab's sloweness is not the UI framework :( We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.

I recently needed a simple self-hosted git web interface for about 3 people, and I only have a cheap 2GB RAM VPS that also runs other things. After looking at gitlab's requirements, I didn't even try.

Setting up the gitea docker container was so easy (https://docs.gitea.io/en-us/install-with-docker/) and it only takes like 160 MB of RAM plus it's super fast.

Then again, I only needed the more basic features, so I doubt that's gitlab's target audience anyway.

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

#105

Post by merb »

jackyb wrote: post #97
merb wrote: post #93

Sadly I think the problem of GitLab's sloweness is not the UI framework :( We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.

Yeah, being unable to host Gitlab under 512MB is just too bloaty for me. I know Gogs doesn't have this issue for the same features I use. I still use Gitlab though because it's the mainstream.

well we use it because alternatives that costs money always takes years to finish a simple feature and tell people that they can extend it via their plugin repository.

and we also use it for their CI integration. It's just simpler than setting up a Jenkins instance for simple jobs (well gitlab ci is slower but not so much that it is painful)

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

#106

Post by elsurudo »

GeneralMaximus wrote: post #101
vog wrote: post #83

Earlier quoted context omitted.

This. I just had a look at Vue and everything looked fine so far, until they started with two-way-bindings. Two-way-binding failed already long before the web and SPAs. Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Not sure why frameworks keep repeating this well-known anti-pattern. I'd prefer framworks like React or Riot any time over two-way-bin…

> Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Can you elaborate on this? The last time I wrote a native application was 6 or 7 years ago using Cocoa and Objective-C. If I remember correctly, Cocoa had a mechanism that was similar to two-way binding. Have things changed recently? What do modern iOS/Mac applications use?

Cocoa Touch (iOS) got rid of bindings altogether and you manage updates manually (although I use a bindings library to emulate the old OSX bindings support in one of my apps).

Not sure on macOS, bindings may still exist there.

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

#107

Post by __luke »

rkwasny wrote: post #103

Something went terribly wrong in our field .... "On GitLab, our pages would load an average of 20kb on each page load versus the full JavaScript file size of 800kb+." What exatly takes 800kb? I don't see a 3d animation/game on every gitlab page... IMHO the solution to all this craziness is just generate small mostly-static page quickly and do not have 200 onLoad() functions.

I completely agree, thanks to the webpack move it will now be a lot easier to take control over the chunking of the JavaScript. There are a few things in place already but it can be thinned out a lot more now.

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

#108

Post by burriko »

bobbytherobot wrote: post #81
phasecode wrote: post #72

Earlier quoted context omitted.

Are there any specific reasons you can point to, rather then a blanket statement?

I'll take a stab, although I don't share the same absolute stance. I've run the gambit when it comes to types of front-end projects. The React community has more focus on scaling React for large teams and companies. This isn't to say Vue can't do any of this, but there is a clear focus in the React community. I need to do isomorphic rendering because of SEO, there is a lot of React documentation on that and very litt…

I love both React and Vue, but I feel the need to step in and defend Vue a little here.

Of the 3 points you listed, Vue has a section in the official documentation dedicated to Server-Side Rendering, ditto for using it with Typescript for static typing, and it even gives you replayable state with Vuex (the official redux-style library for Vue).

They really are both great options.

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

#109

Post by INTPenis »

merb wrote: post #93

Sadly I think the problem of GitLab's sloweness is not the UI framework :( We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.

I run a private gitlab used by 2-4 users regularly and a few others irregularly.

The biggest issue is the sidekiq process. I've had so much trouble with it hanging that I'm starting to wonder if it's a problem with my VM. But it's one VM in a big vSphere environment and no one else is having problems.

Have you noticed Sidekiq hanging? When it hangs it often says it's using all its jobs, and you can't shut it down without forcing a kill signal.

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

#110

Post by vog »

elsurudo wrote: post #106
GeneralMaximus wrote: post #101

Earlier quoted context omitted.

> Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Can you elaborate on this? The last time I wrote a native application was 6 or 7 years ago using Cocoa and Objective-C. If I remember correctly, Cocoa had a mechanism that was similar to two-way binding. Have things changed recently? What do modern iOS/Mac applications use?

Cocoa Touch (iOS) got rid of bindings altogether and you manage updates manually (although I use a bindings library to emulate the old OSX bindings support in one of my apps). Not sure on macOS, bindings may still exist there.

That's exactly my point. The concept of bindings (in the sense of two-way-bindings) hasn't proved to be successful - neither today nor in the past, neither on desktop or in the web.

As a more general throught:

When comparing concepts or patterns, there are often discussions about which one is better, comparing different but almost equally good options. Choosing the "best" one is hard. So the list of advisable patterns is constantly evolving and changing.

However, some concepts clearly didn't pay off over decades across a huge variety of settings. These anti-patterns are quite stable, and more or less just growing, not changing. It may make sense to collect these ones.

The "good" concepts may be subject to fashion and evolution, but the "bad" ones are stable and hence worth collecting.

Post reply on HN