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

271–280 of 304 posts

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

#271

Post by cmatija »

cmatija wrote: post #165
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

My bad there. I though you were referring to GitLab.com

We're planning a bunch of performance improvements for 9.0, which is intended to make GitLab faster for everyone. 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

#272

Post by hrayr »

randomsofr wrote: post #253
iamleppert wrote: post #249

You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document…

> Generate the markup on the server and send it down to the client! You are so smart, how come no one thought about that before.

Obviously they did, hence the "It's post-modern web development." No need for snark.

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

#273

Post by [deleted] »

randomsofr wrote: post #253
iamleppert wrote: post #249

You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document…

> Generate the markup on the server and send it down to the client! You are so smart, how come no one thought about that before.

[deleted]

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

#274

Post by mi100hael »

paulddraper wrote: post #254
iamleppert wrote: post #249

You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document…

> Generate the markup on the server and send it down to the client! It's post-modern web development. Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX. There are solutions that use the same templating server and client side, but they are far from pedestrian.

> Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX.

Strongly disagree that there's any actual improvement on UX. Plenty of sites like GitLab, GitHub, YouTube, etc. insist on using JS to load what could be entirely separate pages, but instead leave the user with some slow, hand-rolled progress bar on the top of the page. For sites doing nearly-full-page refreshes, a server pre-rendering is going to be faster. For sites doing smaller content-level changes, there's no reason something like turbolinks, pjax, or regular old ajax/DOM manipulation can't be used, which is almost always faster.

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

#275

Post by cmatija »

creo wrote: post #188

GitLab rushing good news about frontend when backend crashes is good short term PR support plan.

We have separate teams working on frontend and backend.

Here's a list of performance issues which we intend to work on: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

Most of them are scheduled for 9.0 or 9.1

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

#276

Post by ng12 »

kevin_thibedeau wrote: post #241
tomstuart wrote: post #56

Earlier quoted context omitted.

Not the OP, but I'll state the obvious on their behalf. The number one thing that you (and Facebook) could do to help people learn React, and combat the perception that it requires overly complex tooling, is write a tutorial that shows how to use React entirely in-browser without any build toolchain. A static HTML file, some tags pointing at a CDN — done. No distractions, nothing to download, nothing to install, noth…

This is why I am using Vue and never gave React a second thought. Everyone "says" JSX is optional but there is no practical way to invest in React without having to deal with it.

JSX is a breeze though. The trial-by-fire for me was handing a bunch of ugly components to our designer who only knew HTML/CSS/JS. He picked it up no problem.

And to me using JSX is infinitely better than have to use opaque template directives like Angular and Vue.

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

#277

Post by jeffbachtel »

cmatija wrote: post #167
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

Does GitLab have any plans to implement a git server that does not rely on POSIX filesystem semantics and gets away from the need for NFS?

It seems like a git server storing objects in an object store would allow the GitLab SaaS to scale out better.

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

#278

Post by northrup »

jeffbachtel wrote: post #277
cmatija wrote: post #167

Earlier quoted context omitted.

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

Does GitLab have any plans to implement a git server that does not rely on POSIX filesystem semantics and gets away from the need for NFS? It seems like a git server storing objects in an object store would allow the GitLab SaaS to scale out better.

GitLab does have a plan to try and mitigate the bulk of pain generated from hosting lots of git repositories against a POSIX based filesystem by abstracting a layer of caching functionality and horizontal scaling. This project is called Gitaly[0] and is being tracked on GitLab.com

[0] https://gitlab.com/gitlab-org/gitaly

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

#279

Post by paulddraper »

mi100hael wrote: post #274
paulddraper wrote: post #254

Earlier quoted context omitted.

> Generate the markup on the server and send it down to the client! It's post-modern web development. Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX. There are solutions that use the same templating server and client side, but they are far from pedestrian.

> Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX. Strongly disagree that there's any actual improvement on UX. Plenty of sites like GitLab, GitHub, YouTube, etc. insist on using JS to load what could be entirely separate pages, but instead leave the user with some slow, hand-rolled progress bar on the top of the page. For sit…

> regular old ajax/DOM manipulation

Yes, exactly. There's no way to do this on the server, so anything you do with DOM will be split in to separate server and client side worlds.

For example, https://github.com/git/git/compare/master...next will show you "base: master, compare: next" when you load it. But I can use the dropdown + autocomplete to update that value.

That value is set both on page load, and also (justifiably, IMO) dynamically. Multiply that by a hundred bespoke things and you yearn for less server client spaghetti.

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

#280

Post by philliphaydon »

jayajay wrote: post #248
philliphaydon wrote: post #134

Earlier quoted context omitted.

I hate writing react. I have much more enjoyable experience with vue or riot.

> I hate writing react. Out of curiosity, what was the straw that broke the camel's back?

After a few hours of Vue / Riot I could sit and begin writing a full fledged app.

React for me was a bigger barrier to entry, i kept running into road blocks and searching google how to do things then everything is like "you need flux" or all these other things and I just got more confused and frustrated. Once you know it, its great, powerful, fast, a pleasure to use.

But I still prefer vue/riot. Simple easy straightforward.

Post reply on HN