Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

about.gitlab.com

Post reply on HN
Print view View original

131–140 of 304 posts

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

#131

Post by duncanawoods »

scrollaway wrote: post #124
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…

Frankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at). JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.

> will look fine when nesting dozens

Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability:

C#

http://imgur.com/a/nVWdC

JSX

http://imgur.com/a/qwAfD

You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle brackets, end tags and escaping expressions with {}, it can actually be more verbose.

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

#132

Post by jabl »

gtaylor wrote: post #102
jabl wrote: post #90

Earlier quoted context omitted.

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.

*Gogs

Thank you, indeed it's gogs ( https://gogs.io/ )

Damn you autocorrect!

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

#134

Post by philliphaydon »

jayajay wrote: post #59
jorblumesea wrote: post #38

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…

I've always been a pretty average front-end guy, but React actually makes me like writing front end code. It's just a great way to think.

I hate writing react. I have much more enjoyable experience with vue or riot.

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

#135

Post by hacker_9 »

duncanawoods wrote: post #131
scrollaway wrote: post #124

Earlier quoted context omitted.

Frankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at). JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.

> will look fine when nesting dozens Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability: C# http://imgur.com/a/nVWdC JSX http://imgur.com/a/qwAfD You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle br…

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.

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

#136

Post by realharo »

zebra9978 wrote: post #126
realharo wrote: post #104

Earlier quoted context omitted.

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…

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

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

#137

Post by rk06 »

vog wrote: post #83
rdsubhas wrote: post #78

Earlier quoted context omitted.

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

There are two types of two-way binding.

1. Bad Two Binding i.e. Two way binding between components. Vue2 and most of the UI frameworks shun this.

2. Good two way binding i.e. Form model binding. Because form input can actually come from two sources (user input and javascript). this is naturally two-way and this is why frameworks continue to keep it.

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

#138

Post by mkalygin »

vog wrote: post #110
elsurudo wrote: post #106

Earlier quoted context omitted.

Cocoa Touch (iOS) got rid of bindings altogether and you manage updates manually (although I use a bindings library to emulate the old OSX bindings support in one of my apps). Not sure on macOS, bindings may still exist there.

That's exactly my point. The concept of bindings (in the sense of two-way-bindings) hasn't proved to be successful - neither today nor in the past, neither on desktop or in the web. As a more general throught: When comparing concepts or patterns, there are often discussions about which one is better, comparing different but almost equally good options. Choosing the "best" one is hard. So the list of advisable pattern…

Could you explain why two-way binding is a bad pattern? Why it hasn't proved to be successful?

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

#139

Post by duncanawoods »

hacker_9 wrote: post #135
duncanawoods wrote: post #131

Earlier quoted context omitted.

> will look fine when nesting dozens Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability: C# http://imgur.com/a/nVWdC JSX http://imgur.com/a/qwAfD You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle br…

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 a function to create a data structure element and JSX totally obfuscates that. I pity poor programming newbies trying to understand what JSX is actually doing "so you are telling me is a function...but?".

In the functional form its just your normal language, nothing is disguised, everyone can see what it is doing and no post-processing magic is required e.g.

    public class DOM
    {
        public static IElement div(object attributes, params IElement[] children) 
        {
            return new Element(...);
        }
    }

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

#140

Post by dchest »

duncanawoods wrote: post #131
scrollaway wrote: post #124

Earlier quoted context omitted.

Frankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at). JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.

> will look fine when nesting dozens Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability: C# http://imgur.com/a/nVWdC JSX http://imgur.com/a/qwAfD You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle br…

(The JSX one returns undefined)
Post reply on HN