Live data from Hacker News

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

about.gitlab.com

151–160 of 304 posts

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

#151

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.

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 have built a full fledged production 2d/3d application in JS. It was less complex than what GL has to do, and it was 670kb fully minified and obfuscated. We are constantly looking for ways at GL to make our file size smaller and our JS faster. It is something we are actively putting our time towards.

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

#152
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.

For me, the ability to use inline-template to add Vue-powered interactivity to server-rendered HTML is the huge win.

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

#153
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.

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

#154
Vue.js is just a better option for every-day development in smaller and mid-sized teams, it gives more freedom working with arbitrary html, which is huge, it also gives easy start - you don't need compiler to use Vue across your legacy codebase. React is a good thing if you are a hard-core fulltime frontend dev in a big team, I guess. That's why potential of Vue.js popularity is ~25-30% of jQuery worldwide usage while React will probably might get 5-10% at most - that's just my impression after using both React and Vue. http://pixeljets.com/blog/why-we-chose-vuejs-over-react

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

#155

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…

All I ever used of Angular was the parts that Vue kept.

So, it was the right idea, and the Angular creators just got carried away.

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

#156
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.

The obligatory read to help with this question: https://vuejs.org/v2/guide/comparison.html

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

#157

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…

When a react component tree has more than 3 level height, react component's lifecycle callbacks start getting crazy unmanageable. Mounting, unmounting, rendering, props receiving, updating etc, these callbacks' calling orders open to bad rendering practice(e.g. unnecessary render, unexpected calls), that's why people avoid putting logics in there. It claims to be self-contained but parent-child communication breaks i…

> It claims to be self-contained but parent-child communication breaks it in several ways

I think you'll find that most react developers advise against doing parent-child communication in react components for all but the simplest cases. Does it involve writing higher order components? Probably. Curious, why aren't you a big fan of them?

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

#158

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…

I somewhat agree, but a little inconvenience comes when you have to insert HTML that you got from somebody else, like from a design template or an ad or analytics code. Sure you can convert it by hand or with an editor extension but then you are just doing the same as JSX, or you can insert it as a string but then it becomes inconsistent.

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

#159
Vue really has the best of both worlds. You can use it like old-style angular or take the component approach. You can just include the 71kb minified script and take off or you can use a build system with components - Take a look at Vue-cli: https://github.com/vuejs/vue-cli

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

#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

Post reply on HN