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

161–170 of 304 posts

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

#161

Post by jobvandervoort »

randallsquared wrote: post #150
merb wrote: post #105

Earlier quoted context omitted.

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)

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

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

#162

Post by steinuil »

fleshweasel wrote: post #88

One of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week. I also am strongly against string…

Have you tried Elm? It is strongly typed and it uses function to represent html elements and attributes, which end up looking a lot like JSX.

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

#163

Post by hashkb »

duncanawoods wrote: post #116
fleshweasel wrote: post #88

One of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week. I also am strongly against string…

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…

Don't use it! I just use hyperscript and functions. Works great.

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

#164

Post by k__ »

fleshweasel wrote: post #88

One of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week. I also am strongly against string…

This.

"Good view layer code means that templates should be as declarative as possible, NOT that the view layer as a whole should avoid procedural logic altogether." - https://lhorie.github.io/mithril-blog/getting-over-a-fear-of...

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

#165

Post by cmatija »

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.

Hey, thanks for joining in on the conversation.

We agree. It's not just the front-end. We had problems with bot the front-end and back-end. But we're working hard on making things better / more performant on all fronts.

We have an issue specifically about this. https://gitlab.com/gitlab-com/infrastructure/issues/947

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

#167

Post by cmatija »

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?

Definitely. We have lots of ongoing efforts. (Not necessarily moving to a different Ruby implementation, though)

You can take a look at an overview of our efforts here: https://gitlab.com/gitlab-com/infrastructure/issues/947

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

#168

Post by skrebbel »

mgkimsal wrote: post #153
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…

vue feels to me like a condensed knockout. i still use knockout on some projects, but have used vue on a couple new ones too. as much as I'd like to see knockout progress - simplify a bit more to be more compact like vue, i'll take vue if that never happens. anyone using knockout looking to migrate, vue is a worthy spiritual successor imo.

Do you end up using View Models in Vue just like you might in Knockout? To me, a big benefit of React is making that translation step implicit; I like the idea of View Models but in practice I'm just schlepping a lot of data around between the models and view models.

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

#169

Post by Androider »

megawatthours wrote: post #160

In webpack.config.js > if (IS_PRODUCTION) { > config.devtool = 'source-map'; Ouch! This will make for a huge bundle. See https://webpack.github.io/docs/configuration.html#devtool Merge request here: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9028

Surely the sourcemap is externalized to a separate file and only loaded if you attach a debugger, if the sourcemap is even deployed to prod together with the bundle at all (unlikely in my experience). 'source-map' produces much nicer traces than 'cheap-module-source-map', and both type of maps are going to be huge in any case.

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

#170

Post by jobvandervoort »

developer2 wrote: post #45
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…

Unfortunately for GitLab, they've locked themselves into a position of trying to compete directly with GitHub. If GitHub has instantly smooth transitions between page loads while browsing a repository, then GitLab is going to follow suit. It's really hard to be competitive while ignoring the nagging thought that "competing requires copying the competitor".

Performance is really important, especially to user experience. We want GitLab to be fast, independent of the scale it's used at.

Right now, GitLab is fast and snappy for people that self-host it, but GitLab.com is not and we're not happy with that [0]. Making our front end performant is part of that and I'm happy our engineers have been working hard on that.

We have been using Prometheus extensively to monitor speed of transactions on the backend and I'm seeing a strong push to more monitoring to front end monitoring as well (I owe you a link here).

[0]: https://gitlab.com/gitlab-com/infrastructure/issues/59

Post reply on HN