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

121–130 of 304 posts

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

#121

Post by BinaryIdiot »

jeswin wrote: post #54
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…

IMO this is not true at all. Any non-trivial SPA not based on a framework will end up inventing one eventually that solves the very same problems which were already solved for you. Examples being history management and back button, state management (especially if you prefer immutability), and server side rendering. On the other hand, if the app is not an SPA, you probably don't need the framework. Both history and st…

I know you just listed some examples but I think many on HN place frameworks too highly. They're useful if they can make you more productive but many of the items they cover are not that difficult to substitute or attack from another angle.

> Examples being history management and back button

This is already built into the DOM API since HTML 5 (you can use hashes if you want to go old school as well). So you don't need any special library or framework to handle this for you.

> state management (especially if you prefer immutability)

Well, depends on what you mean by state management. Do you mean if you go forward and back the browser will reload what you already entered? The browser will keep state in some scenarios. In others it's simply storing it and reloading it.

It's not like this is difficult or anything. Most frameworks require setting this up in various ways anyway.

> server side rendering

I would argue server side rendering is far easier without a framework. Without a framework you can load templates from the server side that have data already injected and ready to go. The JavaScript front end just deals with it.

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

#122

Post by chrisseaton »

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?

Yes actually I think they had one developer working part time on Rubinius.

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

#123

Post by Vinnl »

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.

It sounds like Vue is easier for the style of teams working at GitLab, where there are designers that mostly do the HTML+CSS.

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

#124

Post by scrollaway »

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…

Frankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at).

JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.

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

#125

Post by irq11 »

comex wrote: post #57
developer2 wrote: post #45

Earlier quoted context omitted.

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 matters - a lot. It's often overlooked because its effect on users is more unconscious than consciously noticed, but even small speedups greatly affect user motivation, as measured by any number of blog posts about "page load time" and "conversions". However, "instantly smooth transitions" may not require using JavaScript. According to the blog post, GitLab observed a performance increase after ditching T…

The irony, of course, is that GitHub doesn't use any of the JS framework complexity that people here seem to think is necessary. They use jQuery and PJax.

Sometimes I feel like 95% of the thrashing in the JS world is from people trying to fix the wounds inflicted by the previous Hot New Thing...

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

#126

Post by zebra9978 »

realharo wrote: post #104
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 d…

There's also gitbucket built in scala. The UI is much nicer than gitea.

https://gitbucket.github.io/gitbucket-news/gitbucket/2017/01...

running it is simply java -jar gitbucket.war

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

#127

Post by irq11 »

educar wrote: post #112

Sorry to be negative but GitLab's performance is embarassing :/ It is so slow and it's not clear why. Is this because of rails? Just seems very poorly engineered.

GitHub is a rails site. Does the same thing, and is fast.

I don't know where people get the notion that rails is slow.

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

#128

Post by sandGorgon »

irq11 wrote: post #127
educar wrote: post #112

Sorry to be negative but GitLab's performance is embarassing :/ It is so slow and it's not clear why. Is this because of rails? Just seems very poorly engineered.

GitHub is a rails site. Does the same thing, and is fast. I don't know where people get the notion that rails is slow.

there is a difference between scaling a rails application when you are running a cloud business and running a packaged application on-site. I'm pretty sure nobody is running gitlab backed by databases like AWS RDS or something.

I have shipped large rails apps as packaged software for on-site install (using jruby). It's not easy.

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

#129

Post by chalupa-man »

StavrosK wrote: post #46
Jarwain wrote: post #36

Earlier quoted context omitted.

What are your thoughts on Elm compared to the other three?

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) and recommend that everyone use it. So it's like having a really lightweight framework baked into the standard library and indistinguishable from it.

Those four functions are view (take a model and return some HTML, like a React top-level component's render method), update (take a model and a msg/action and return a new model, like a Redux reducer), init (an initial state) and subscriptions (a list of things to watch for changes and automatically create msgs/actions from, like mouse movement or websockets). When you run a program, it feeds the initial model into the view, and renders it. HTML elements can create messages (dispatch actions) based on DOM events, and subscribed things (like websockets) can also create messages. Every time a message is created, it gets fed into the update function with the existing state, and you branch on the message type to figure out what the new state should be. Then that new state is fed into the view function again and the result is diffed against the virtual DOM and the optimal update made.

The biggest differences between React and Elm are that you don't mess with lifecycle hooks and that you don't repeat this pattern for every sub-component. Instead, you just write lots of small functions that take a model and return some HTML, and you can call those from your top-level view function -- a bit like building everything out of React stateless components.

Writing any Elm code feels a lot like writing React, but with much less boilerplate, reduced complexity, excellent error-catching, and static typing.

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

#130

Post by Existenceblinks »

Jarwain wrote: post #36
elliotlarson wrote: post #27

Earlier quoted context omitted.

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…

What are your thoughts on Elm compared to the other three?

The most annoying thing in Elm, not the language itself but their community. People complain about openness, elm packages can't grow as fast as contributors want to see.

I do not want to write a long story of composability and fancy types that haskellers want it and Elm doesn't have. But thoes are also big blockers

Post reply on HN