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

251–260 of 304 posts

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

#251

Post by lhorie »

nkohari wrote: post #206
lhorie wrote: post #192

Earlier quoted context omitted.

DOM.div() vs seems like a bad example. IMHO, when you get an element with tons of event handlers and conditional classes, or when you have a deep chain of ternaries that's where angled bracket syntax starts to become unwieldy. The className thing is a big deal too, in my opinion. Preact and Mithril do what you would expect, and perf doesn't suffer, so why can't React/JSX normalize it as well?

Ternary operators should never be nested, whether you're using JSX or not. If you have that many conditionals you should use variables and/or decompose the optional pieces into sub-components. Pretty much any time you have a tag that has a huge number of attributes, it's a smell that you need to decompose something. Variable assignment is the simplest answer, which takes advantage of the fact that null or undefined v…

I'm actually fine w/ JSX being "dumb" and just translating `class` to `class`, but when used in conjunction w/ React, the end result is that the JSX "markup" has a lot of traps that simply don't exist in similar libraries like Mithril.

`className` isn't the only offender. `onClick` and `readOnly` are other notorious one. And then there's stuff like `xlinkHref`, because it's not like anyone ever imports SVG from external tools.

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

#252

Post by debaserab2 »

lhorie wrote: post #244
debaserab2 wrote: post #204

Earlier quoted context omitted.

If you have deep chains of ternarys, that's a symptom that you should be splitting your rendering code into another function or component. This would be true regardless or what approach you are taking to templatihg. That's one thing I really appreciate about jsx: the lack of rich template code syntax makes it glaringly obvious when your template code is doing too much and should be refactored. It does a really good j…

Refactoring into functions/components doesn't magically make a complex ternary tree go away. It helps the body of each branch be less noisy but the ternary tree will still be there. You're talking about taking something like `foo && bar || baz && quux` and turning it into `isSomeCondition()`, but that's a pretty obvious refactor in any templating system. I'm talking about things like return ( { x.type === 'foo' ? : x…

Without understanding what x.type is, I'd be inclined to write that without any ternary operator at all using plain old if statements with each returning JSX markup. I try to keep logic in JSX to simple ternary operators and loops at most. JSX is really just shorthand for DOM.div() for me. I imagine the code structure looks pretty similar to actually using DOM.div though. I'm not seeing how programmatically creating markup with DOM.div results in significantly different code, although if you have some good examples I'd love to understand them better.

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

#253

Post by randomsofr »

iamleppert wrote: post #249

You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document…

> Generate the markup on the server and send it down to the client!

You are so smart, how come no one thought about that before.

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

#254

Post by paulddraper »

iamleppert wrote: post #249

You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document…

> Generate the markup on the server and send it down to the client! It's post-modern web development.

Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX.

There are solutions that use the same templating server and client side, but they are far from pedestrian.

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

#255

Post by fleshweasel »

steinuil wrote: post #162
fleshweasel wrote: post #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…

Have you tried Elm? It is strongly typed and it uses function to represent html elements and attributes, which end up looking a lot like JSX.

Haven't had the chance to try it myself but I have read quite a bit and I like what I see, particularly the high quality error messages in the compiler. However, I think I'd have a hard time getting my team on board with it as we use Visual Studio for the bulk of our development, and we would need to learn to work with the JavaScript interop APIs to do things like try Elm out for a single new feature on a page.

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

#256

Post by haukur »

msoad wrote: post #44
dntrkv wrote: post #10

Can 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.

React has no templates which is an advantage until it hits you with large bundle sizes. Every line of JSX is transformed into a longer JavaScript program. I love that React makes developers more productive with JSX but there should be a way of outputting HTML for large template like React components. Browser are much happier dealing with HTML.

You can convert a component to static markup with react-dom (the same package used to attach the app to the container element).

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

#257

Post by fleshweasel »

iamleppert wrote: post #249

You want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document…

Every tool for its job. If you have serious dynamic behavior and you try to handroll it yourself, you risk either low maintainability and bugs in your bespoken optimized DOM manipulation algorithm or doing things in fundamentally inefficient ways. That said, people should be cautious about taking on new dependencies, and definitely need to take an evidence-based approach to performance optimization.

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

#258

Post by dustingetz »

falcolas wrote: post #178
dustingetz wrote: post #148

Earlier quoted context omitted.

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

If JSX is embedded in a codebase, what is the value of that? Let me clarify a bit. What is the value in creating a limited tool optimized for neophytes that will be used extensively by experienced professionals, who would be better served by flexibility?

I had a lot of success back in 2013/14 by having our outsourced graphic designer directly modify JSX files in our codebase. He picked up just enough javascript to figure it out. I just told him where the file was or set up a test harness and he delivered pull requests against our actual codebase.

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

#259

Post by lhorie »

debaserab2 wrote: post #252
lhorie wrote: post #244

Earlier quoted context omitted.

Refactoring into functions/components doesn't magically make a complex ternary tree go away. It helps the body of each branch be less noisy but the ternary tree will still be there. You're talking about taking something like `foo && bar || baz && quux` and turning it into `isSomeCondition()`, but that's a pretty obvious refactor in any templating system. I'm talking about things like return ( { x.type === 'foo' ? : x…

Without understanding what x.type is, I'd be inclined to write that without any ternary operator at all using plain old if statements with each returning JSX markup. I try to keep logic in JSX to simple ternary operators and loops at most. JSX is really just shorthand for DOM.div() for me. I imagine the code structure looks pretty similar to actually using DOM.div though. I'm not seeing how programmatically creating…

Those are two different aspects of template code.

Pulling things out into plain if statements is fine if you only have one or two, but in my opinion, it gets progressively harder to understand the code as the number of if statements increase (for the same reason that writing vanilla DOM creation code does). In my experience, when this type of refactor is allowed, it's common to pull just about everything up to the top of the render function (conditional className compositions, conditional components, even loops). This increases cognitive load because now the maintainer has to mentally piece everything back together on every read. Having been that maintainer, I'd say it's the sort of code that it's fun to write, but not fun to read.

The rationales in favor of hyperscript are largely cosmetic (e.g. JS indents more naturally), and I think that's very much a potato-potahto kind of discussion. Personally, I feel that hyperscript is more readable (because of the terser CSS selector syntax), but likewise, I totally understand that some people find angled brackets easier to read even if that entails super long attribute lists.

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

#260

Post by sytse »

jobvandervoort wrote: post #170
developer2 wrote: post #45

Earlier quoted context omitted.

Unfortunately for GitLab, they've locked themselves into a position of trying to compete directly with GitHub. If GitHub has instantly smooth transitions between page loads while browsing a repository, then GitLab is going to follow suit. It's really hard to be competitive while ignoring the nagging thought that "competing requires copying the competitor".

Performance is really important, especially to user experience. We want GitLab to be fast, independent of the scale it's used at. Right now, GitLab is fast and snappy for people that self-host it, but GitLab.com is not and we're not happy with that [0]. Making our front end performant is part of that and I'm happy our engineers have been working hard on that. We have been using Prometheus extensively to monitor speed…

The issue you linked to was moved to https://gitlab.com/gitlab-com/infrastructure/issues/947

The performance issues we plan to work on are in https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

Post reply on HN