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?
Our long term plan to make GitLab as fast as possible with Vue and Webpack
71–80 of 304 posts
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#72It'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.
Are there any specific reasons you can point to, rather then a blanket statement?
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#73Earlier quoted context omitted.
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 agree with this. If you're augmenting a traditional request/html-response web app with some JavaScript functionality, a lighter weight view library fits the bill nicely. But, if you're developing a SPA that consumes an API, you might really enjoy what a more holistic framework provides in terms of code structure, front-end data management, and just general guidance on how to do certain standard things, like basic C…
Jumping on the bandwagon here...
The key is the single directional data flow. It was purposed in Flux, made better in Redux, and is used in Angular as well.
If you're writing a large web app, the dependency injection part of Angular 2+ isolates your modules much better than Redux. You won't need a single file with action creators. Each service can contain its own information.
Though not a feature of Angular, Observables are the baked in method of HTTP. Using Observables are far superior to Promises. You can compose Observables and make the callback part of javascript a lot easier on you. You can also cancel Observables, which is not possible with promises.
One of the things I miss with React is JSX, however, it's not so bad. There is even a mobile framework called nativescript that allows you to write Angular 2+ code with Native UI.
People jumping on the Angular hate train are mostly riding the vapor from Angular 1.X. The new framework has been done very well.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#74Earlier 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 also dictates a very specific way of structuring your front-end application. This style is very similar to Redux and other such immutable state -> render -> actions -> reducer -> state flows. I can absolutely see why someone would compare it with front-end frameworks.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#75We 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.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#76Can 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.
Preference? Maybe they're just plain sick of hearing "Just use React" all the time.
That's like saying just use Javascript for everything. Good grief.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#77Can 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.
If you already know react and are happy using it, then there's no reason to use Vue. But if (like me) you were never quite able to figure out how to use React (especially all the build tooling that's suggested in every tutorial), then Vue is worth a look as it's incredibly simple to get started with and easier to learn. I find it especially appeals to people coming from a place of familiarity with html and css (where…
Then you should look at Polymer. It is just DOM nodes (custom elements_, you can however compose complex applications with it without any trouble.
I feel its very straightforward way to build applications and most parts of it are handled by browser API's. It seems like a perfect middle ground between react/angular 2/vue - and you can still throw in redux or uniflow-polymer if you want.
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#78Earlier 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?
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)
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#79It'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.
"at scale"? I hear this a lot of when react gets sold, but apparently most of the time people are using this in the old MongoDB "web scale" meaning, not when it comes to scaling up to complex interfaces (i.e. "we use it like jquery, but get lot of hits/s", not "this is our enterprise CRM desktop that's on par with your average single developer Delphi program").
Re: Our long term plan to make GitLab as fast as possible with Vue and Webpack
#80Earlier quoted context omitted.
Not the OP, but I'll state the obvious on their behalf. The number one thing that you (and Facebook) could do to help people learn React, and combat the perception that it requires overly complex tooling, is write a tutorial that shows how to use React entirely in-browser without any build toolchain. A static HTML file, some tags pointing at a CDN — done. No distractions, nothing to download, nothing to install, noth…
Thanks for replying! Our official tutorial was actually exactly that for _years_, but it didn't seem to help much. I get the sentiment though and maybe we can find another way to make it work.
Offering an alternative point of view: I would really like if the tutorial at least pointed towards documentation on what do I need and why, and the right way to set these things up between Babel and Webpack, as well as Typescript.
Maybe my use case is rarer, I don't know, but if I want to do things right, I want to understand what I'm setting up. Do I really need babel? If I use Typescript, do I still need it? etc...
I understand this doesn't have much to do with React per se but if these components are a definitive part of the ecosystem people work with, there is value in at least telling people where to find a high quality explanation for how they fit together.