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

261–270 of 304 posts

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

#261

Post by sytse »

INTPenis wrote: post #109
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 wit…

Are you running the Omnibus packages? They should help by monitoring the Sidekiq process for you.

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

#262

Post by lhorie »

Bahamut wrote: post #201
lhorie wrote: post #192

Earlier quoted context omitted.

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?

className was named that to avoid conflict with the JS class syntax originally I believe, since JSX is inline - they probably could put in the work to change it at this point, but it seems like a minimally beneficial change but massively disruptive at this point.

There's also stuff like onClick, readOnly, xlinkHref... I would guess that a healthy number of React-related google searches are related to these gotchas

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

#263

Post by amalag »

elliotlarson wrote: post #27
dntrkv wrote: post #10

Can someone explain why someone would choose Vue over React (or one of the clones)? When I looked at the docs for Vue it reminded me of my Backbone days.

I'm mostly a backend Rails developer, but I've spent the last 3 months developing stuff with Vue, Elm, React, and Angular 2 in an effort to see which of the front-end frameworks I would like best (I messed with Ember a year ago but haven't had a chance to revisit since). To me it seems like React is about putting logic in code instead of templates/markup. Vue is more in the vein of Angular, where you have logic in yo…

Have you checked out Aurelia?

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

#264

Post by connorshea »

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.

Sorry for the bad experience :(

We're constantly working on improving GitLab's performance, and we have a bunch of issues open for performance fixes/improvements we'll be doing for the upcoming 9.0 release: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

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

#265

Post by connorshea »

OJFord wrote: post #215
OJFord wrote: post #118

I'd only heard of Vue as a name before this, but I followed the link to the documentation, which looks fantastic: {{ message }} var app = new Vue({ el: '#app', data: { message: 'Hello Vue!' } }) > Hello Vue! > This looks pretty similar to just rendering a string template, but Vue has done a lot of work under the hood. The data and the DOM are now linked, and everything is now reactive. How do we know? Just open your…

> I followed the link to the documentation, which looks fantastic It is fantastic, and engrossing. After I said that this morning I tabbed back to the docs and read through 'cover' to 'cover'. Great docs, and looks like a great framework - I think that I could read through and understand the whole thing with very little JS knowledge is testament to that.

The Vue docs are seriously amazing, I couldn't rap my head around React fully because its docs just weren't very good (though they've improved them since I last tried).

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

#266

Post by connorshea »

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.

Actually we just removed Turbolinks the other day, so this is a non-problem. :)

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

#267

Post by connorshea »

rubber_duck wrote: post #86

No mention of TypeScript - I wonder why ? It's such a powerful tool when your code base scales.

We didn't go with TypeScript because we were burnt by CoffeeScript before. People don't know TypeScript or CoffeeScript nearly as much as they know vanilla/ES6 JavaScript. It's easier to hire for and easier to get contributors for.

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

#268

Post by connorshea »

simondelacourt wrote: post #147
wikyd wrote: post #51

Are you using Webpack directly with Rails? I'm curious how your development environment works.

Another option would be to use Webpacker, in development now, https://github.com/rails/webpacker

Once Rails 5.1 comes out and we upgrade to it we'll probably switch to Webpacker. It was an awesome development in the Rails ecosystem and really verified our investment into Webpack.

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

#269

Post by connorshea »

ZenoArrow wrote: post #238
YorickPeterse wrote: post #229

Earlier quoted context omitted.

We have no plans to move to another Ruby implementation, primarily because Ruby itself is not yet a bottleneck for us.

Is it something you'd consider? Even if it's not a performance bottleneck right now it's probably worth it to reduce server costs (more efficient Ruby implementation = fewer servers required to run GitLab.com). Could be looking at serious gains, 3x over CRuby looks to be a fairly reasonable goal when using RubyTruffle (slow startup times can be mitigated against with SubstrateVM), and if that's not an option due to i…

JRuby isn't an option for us because we use too many gems, many of which have compatibility issues with JRuby's implementation of Ruby. This is especially a problem for gems with C extensions.

I think Truffle is the most interesting new development in this realm, if it gets support for C extensions as they plan for it to, it may eventually be reasonable to run GitLab on it. That wouldn't be for a few more years though.

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

#270

Post by connorshea »

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.

It should be noted that Gogs was recently forked to Gitea due to disagreements about the management style of Gogs as an open source project.

See https://blog.gitea.io/2016/12/welcome-to-gitea/

Post reply on HN