Our long term plan to make GitLab as fast as possible with Vue and Webpack • Hacker News Board

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

#171

Post by mgkimsal » Tue, Feb 07, 2017, 2:07 PM UTC

skrebbel wrote: post #168

mgkimsal wrote: post #153

Earlier quoted context omitted.

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.

It feels like I'm using view models, but I don't think I am. The idea of a 'vue object' ties some metadata, data and methods together, which seems like a somewhat tighter coupling, but also a bit more pragmatic (less "schlepping").

I'm no expert in either, but one of the things I liked about knockout early on was that it was pretty straightforward to decorate existing pages with knockout functionality, and vue has been the same way. Technically react may be the same way, but it never felt as easy as vue or ko. (I've only recently done some 'hello world' stuff in react, so again, no expert) I do have production code with knockout in multiple project spanning back about 4 years or so, so that's where my current comfort-zone is, but vue is starting to replace that.

https://vuejs.org/v2/guide/comparison.html#Knockout has a very short comparison, but they link to a "todo list" gist here comparing the two sets of code: https://gist.github.com/chrisvfritz/9e5f2d6826af00fcbace7be8...

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

#172

Post by Unbeliever69 » Tue, Feb 07, 2017, 2:10 PM UTC

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…

I've personally been impressed with learning Mithril over React. Surprisingly easy to learn for people coming from React and super fast. XHR and routing are included. You can use JSX but hyperscript (pure JS that has no compilation step) is favored for markup. Add in some Aphrodite for inline styling your components, Redux for state management and you have a pretty robust, blazing fast framework that is sufficient for many modern application without all the package bloat.

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

#173

Post by cmatija » Tue, Feb 07, 2017, 2:14 PM UTC

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.

No need to be sorry. We always appreciate honest feedback.

We're working really hard on identifying the causes of our performance issues, as well as fixing them.

There's a META issue about this 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

#174

Post by jblok » Tue, Feb 07, 2017, 2:14 PM UTC

jakecodes wrote: post #151

rkwasny wrote: post #103

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

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

#175

Post by StavrosK » Tue, Feb 07, 2017, 2:20 PM UTC

chalupa-man wrote: post #129

StavrosK wrote: post #46

Earlier quoted context omitted.

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)…

Oh, thank you for the detailed answer. I'm a bit ashamed to say that I really hate JS the language, but Elm sounds like a very nice alternative and potentially very interesting to play with.

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

#176

Post by j_r_f » Tue, Feb 07, 2017, 2:22 PM UTC

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…

I think you are being a bit overdramatic about JSX. There was zero learning curve -- except for a few errors initially when using class instead of className...

The argument that DOM.div() is more readable than is honestly hilarious to me. Any non-trivial tag structure will be unnecessarily complicated through the API. Especially when you can just write it almost exactly how it's going to look when it becomes HTML in JSX.

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

#177

Post by ythn » Tue, Feb 07, 2017, 2:23 PM UTC

jetter wrote: post #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 whil…

I'm assuming in the web dev world "legacy codebase" is used very loosely here.

In my company, "legacy codebase" is referring to C code from the 70s that is still ticking today.

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

#178

Post by falcolas » Tue, Feb 07, 2017, 2:26 PM UTC

dustingetz wrote: post #148

duncanawoods wrote: post #116

Earlier quoted context omitted.

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…

point of jsx is to make react more intuitive to non-programmers

If JSX is embedded in a codebase, what is the value of that? Let me clarify a bit. What is the value in creating a limited tool optimized for neophytes that will be used extensively by experienced professionals, who would be better served by flexibility?

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

#179

Post by Touche » Tue, Feb 07, 2017, 2:31 PM UTC

irq11 wrote: post #125

comex wrote: post #57

Earlier quoted context omitted.

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

Yeah, exactly. It's amazing that so many developers use GitHub, which has excellent performance, but don't take any of its lessons with them.

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

#180

Post by Touche » Tue, Feb 07, 2017, 2:37 PM UTC

ythn wrote: post #177

jetter wrote: post #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 whil…

I'm assuming in the web dev world "legacy codebase" is used very loosely here. In my company, "legacy codebase" is referring to C code from the 70s that is still ticking today.

That's right, in the web dev world "legacy codebase" is 3 or 4 years old, created by a previous team who all quit once they finished the rewrite of the previous "legacy codebase".