Live data from Hacker News

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

about.gitlab.com

111–120 of 304 posts

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

#111

Earlier quoted context omitted.

Yet much easier to do by avoiding a single page app all together.

Is there anything meaningfully different between a site made up of a number of discrete single page apps and one built with Vue?

Sure! Multiple discrete single page apps are simpler to develop and maintain, especially for apps that have a lot of dependence on the backend. IMO it promotes a healthy (aka obvious) separation of concerns and provides flexibility. A UI framework like Vue helps us cut a lot of corners when we need to, but no doubt, not every problem needs to be solved using the framework, the ability to retreat to vanilla when you can is hugely underrated IMO, especially given the _promising_ future of vanilla.

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

#113
post #96
post #4

> For example, the profile page could be potentially very light, and there would be no reason for that if someone is linked directly to the profile page; it should load every single piece of Javascript in our project. There are plenty of ways to do that with single Page apps; it's not a great argument against all single page apps, just poorly designed ones.

Open question: how well does Vue handle isomorphism? Our standard React template now for new projects is isomorphic, and we're porting old projects when/where we can.

I haven't experienced personally, but I remember seeing SSR in Vue docs (https://vuejs.org/v2/guide/ssr.html) for a start. This also looks pretty sweet https://github.com/vuejs/vue-hackernews-2.0

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

#114

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…

There is the choice of preact[1], that has a very similar api, is more lightweight and even has a compatibility layer for the few react packages that need it.

[1]: https://github.com/developit/preact

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

#116

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 every language without any hacks. It doesn't hurt readability or productivity and it has normal expression evaluation semantics. JSX isn't syntactic sugar, its a gross "syntactic artificial flavour" because it doesn't make the syntax easier, it just makes it look something a bit like HTML but with dozens of subtle differences e.g. attribute names, attributes values, tag closing rules, special extensions etc.

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

#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 browser’s JavaScript console (right now, on this page) and set app.message to a different value.

I guess that didn't take any extra work to setup, since it's a fair assumption the Vue docs are rendered with Vue (!) - but a really easy yet nicely motivating introduction.

Obviously this isn't too tricky with 'vanilla' JS, but there's certainly more ceremony involved, and I'm sure the templates can be more complex such that the JS/Vue contrast would be much greater.

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

#119
post #95

It's good to see vue.js getting some love. I believe it would be the preferred Web framework these days if it had backing from FB like React does. Too many people fall into the trap of believing a tech is the best just because some big Corp sponsors it. I fell for Angular once for the same reason.

Disagree. React was released in 2013, but use didn't take off until Dan Abramov released his Flux implementation, Redux, in early 2015[0]. That is a full two years of a Javascript view library with the backing of Facebook where it didn't leave much of a mark vs angular. Most of the projects that contributed to React/Redux becoming popular[1] were developed outside of Facebook - altho some of those developers went on…

I very much agree to this. In fact, I'd consider Redux to be more the application of React's ideas to state management than an implementation of Flux: https://vincenttunru.com/A-short-history-of-Javascript-frame...

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

#120

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 it in several ways, I am not a big fan of HOC.

People claim the simple of "just a view layer" of react, I don't think so. I haven't tried vuejs, but it seems like it takes care of most rendering callbacks/component communication seamlessly.

Post reply on HN