Live data from Hacker News

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

about.gitlab.com

141–150 of 304 posts

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

#141
post #77

Earlier quoted context omitted.

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.

The major problem with polymer is that it does not support npm.

It seems polymer 2 will support yarn. but until then, it is a no go.

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

#142

Earlier quoted context omitted.

There's also gitbucket built in scala. The UI is much nicer than gitea. https://gitbucket.github.io/gitbucket-news/gitbucket/2017/01... running it is simply java -jar gitbucket.war

I don't know, that UI looks a little too "mobile first" to me (for something I would only use on my computer). EDIT: also, the colors seem quite dull from those screenshots

heh heh.. no real way to win. https://gitlab.com/gitlab-org/gitlab-ce/issues/6057

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

#143
post #93

Sadly I think the problem of GitLab's sloweness is not the UI framework :( We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.

I recently needed a simple self-hosted git web interface for about 3 people, and I only have a cheap 2GB RAM VPS that also runs other things. After looking at gitlab's requirements, I didn't even try. Setting up the gitea docker container was so easy ( https://docs.gitea.io/en-us/install-with-docker/ ) and it only takes like 160 MB of RAM plus it's super fast. Then again, I only needed the more basic features, so I d…

For the uninformed (like myself) Gitea is a fork of Gogs.

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

#144
post #54

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

Do you mean lighterweight as jQuery or VueJS/React?

I ask because I'm having a major FUD of using VueJS in a small (tiny) project - I don't seem to be able to think in those terms yet, and I don't really use npm (those starter projects generate 1000 files...).

I'm from the time when you would just list JS files in the HTML..

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

#145

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…

also in vue 2.0 you can use jsx e hyperscript

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

#146
post #127

Earlier quoted context omitted.

GitHub is a rails site. Does the same thing, and is fast. I don't know where people get the notion that rails is slow.

there is a difference between scaling a rails application when you are running a cloud business and running a packaged application on-site. I'm pretty sure nobody is running gitlab backed by databases like AWS RDS or something. I have shipped large rails apps as packaged software for on-site install (using jruby). It's not easy.

I'm not sure what your point is. Rails isn't any slower when deployed on-site, nor is it more likely to be a bottleneck.

If your local database is slow and the app code requires lots of DB resources, then sure...but that's the app, not rails.

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

#148

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…

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

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

#149

Earlier quoted context omitted.

I'm a C# guy and even I would say the JSX is far more readable there. I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case.

I don't mind if people prefer JSX its just a shocking cost - rewriting language ASTs, build tools and IDEs for something that rhymes with html but is really only a couple of characters away from standard language constructs. > I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case JSX is literally an extra level of abstraction. You are not writing html but calling…

I agree that I wouldn't change your current tooling, as the cost isn't worth it. JSX isn't that great. But even though it turns that HTML into function calls, there is still an expectation of how it will work: i.e. those functions will still produce the specified html. At the end of the day, writing a layout in html is so much more intuitive than using function calls. Makes me think of how MS introduced the XAML language when they created WPF, making it far nicer to build UIs out of code than in winforms.

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

#150
post #105
post #97

Earlier quoted context omitted.

Yeah, being unable to host Gitlab under 512MB is just too bloaty for me. I know Gogs doesn't have this issue for the same features I use. I still use Gitlab though because it's the mainstream.

well we use it because alternatives that costs money always takes years to finish a simple feature and tell people that they can extend it via their plugin repository. and we also use it for their CI integration. It's just simpler than setting up a Jenkins instance for simple jobs (well gitlab ci is slower but not so much that it is painful)

GitLab CI is even slower than Jenkins? It's been on my list of alternatives to evaluate, but I guess I'll just push it further down the stack...
Post reply on HN