Live data from Hacker News

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

about.gitlab.com

81–90 of 304 posts

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

#81
post #66

Earlier quoted context omitted.

disagree. React has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale. I think vue is a perfect fit for gitlab but not quite perfect for facebook or a more complex web app on the front end.

Are there any specific reasons you can point to, rather then a blanket statement?

I'll take a stab, although I don't share the same absolute stance.

I've run the gambit when it comes to types of front-end projects. The React community has more focus on scaling React for large teams and companies. This isn't to say Vue can't do any of this, but there is a clear focus in the React community. I need to do isomorphic rendering because of SEO, there is a lot of React documentation on that and very little for Vue. I need static analysis for my code to prevent errors, Flow answers that. I need a replayable state for debugging errors, Redux gives you that.

None of what I mention about React is its sole domain. You can list off many alternatives.

Reading through why people choose Vue, many common needs come up. The one that I find interesting is needing a system that Designers can understand because they code up the HTML and CSS. I doubt that is something that comes up with React teams.

In my opinion, if you require a framework, Vue and React are two great options. It comes down to various small differences about your team needs. (Please stay away from Angular though.)

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

#82

We at http://www.reportdash.com uses Backbone + Backbone Layout Manager + Jade Every time I see a post like this , I feel sad for being less cool. I try to learn a bit of the mentioned cool framework. Then I realise, how awesome my current set up is.

> Add On: Custom Domain with SSL - $50 per month Great way to discourage companies from handling their data online in a secure way. Seriously with SSLs as cheap as $4.99 per year, your pricing feels like its 1999 all over again!

The $50 is for Custom Domain and not SSL. Thanks.

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

#83

Earlier quoted context omitted.

Are there any specific reasons you can point to, rather then a blanket statement?

Two-way binding I guess. Once we get used to one-way binding and immutable data structures, anything else feels indeterministic. (Note: Just guessing what the commenter might have written. I'm a long-term VueJS user)

This. I just had a look at Vue and everything looked fine so far, until they started with two-way-bindings.

Two-way-binding failed already long before the web and SPAs. Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Not sure why frameworks keep repeating this well-known anti-pattern.

I'd prefer framworks like React or Riot any time over two-way-binding.

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

#84
post #54

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…

Can't you use supporting libraries for more advanced stuff? Use Vue for the view layer, vuex for state handling, vue-router for routing and vue-resource for ajax, I feel that it is faster (as in dev learning time) to write an app in Vue without knowing any basics of Vue/front end dev world, I know this because I wrote this app, http://github.com/thewhitetulip/Tasks-vue as I started to learn Vue from the docs, later, I started to write a tutorial as I learned it, https://github.com/thewhitetulip/intro-to-vuejs/ because there is no such resource which taught from the newbie side.

I didn't re-invent the wheel, it is just like what we usually do with Go, we don't use a framework, but a toolkit.

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

#85

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.

Vue has a clean API, just enough. No complex stuff, you can get started in a week!

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

#87
post #66

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 has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale. I think vue is a perfect fit for gitlab but not quite perfect for facebook or a more complex web app on the front end.

> React has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale

And yet somehow even on my quite powerful Macbook Facebook can halt to a freeze for me when scrolling long feeds or comment threads. One would guess that React would handle those scenarios gracefully, but that doesn't seem to be the case.

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

#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 references to model properties in your template. Again, it's much better to use tools that provide some static validation of what you're doing.

Give me React with TypeScript to help me make sure I'm passing around what I said I'm expecting to receive at each point as features are changed and added, and I'll be in business.

Honestly, I use React in spite of my opinion of Facebook.

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

#89

We at http://www.reportdash.com uses Backbone + Backbone Layout Manager + Jade Every time I see a post like this , I feel sad for being less cool. I try to learn a bit of the mentioned cool framework. Then I realise, how awesome my current set up is.

Is not it more important it works for your setup than have the coolest and newest framework running? Look at Gmail... it's internally really old, nevertheless very successful and good enough for the use case.

Agree. But when you are a startup, working on limited resources, you often worry whether you miss something, whether you are doing something the hard way etc. So it is not exactly 'sad about being not cool', but more like a worry on 'not using something that can apparently increase productivity'

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

#90

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?

There's another github/gitlab clone called gigs that's implemented in go. Never used it myself, but if you want to save server resources I guess it's an option.
Post reply on HN