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

241–250 of 304 posts

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

#241

Post by kevin_thibedeau »

tomstuart wrote: post #56
spicyj wrote: post #39

Earlier quoted context omitted.

create-react-app is our recommended way to build simple React apps (and some complex ones). It has no configuration and is designed to be very easy to set up. (My understanding is that Vue templates also need to be compiled -- is that incorrect?) I wrote the tutorial. Could you give any suggestions on how I could make it easier to get into?

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…

This is why I am using Vue and never gave React a second thought. Everyone "says" JSX is optional but there is no practical way to invest in React without having to deal with it.

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

#242

Post by reddit_clone »

peterhunt wrote: post #233
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…

Many people find deeply nested tree structures hard to read when you need to mentally balance a bunch of parentheses. The inability for s-expression languages to gain significant traction with lay programmers is evidence of this.

People who use Lispy languages do _not_ balance parenthesis mentally. In fact they completely ignore parenthesis and go only by indentation. Parenthesis disappear when you are at certain level of proficiency.

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

#244

Post by lhorie »

debaserab2 wrote: post #204
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?

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.type === 'bar' ? (
          
            More stuff
            
          
        ) :
        x.type === 'baz' ?  : null
      }
    )
At this point, I think it's perfectly valid to have the opinion that JSX isn't helping much, since the JS-to-HTML ratio in this case is relatively high.

Refactoring would just make it more difficult to mentally piece things back together given you would end up with sparse component instantiations scattered amidst otherwise-procedural js code, as opposed to the more ideal single-root, declarative virtual dom tree.

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

#245

Post by maccard »

pythonaut_16 wrote: post #216
irq11 wrote: post #146

Earlier quoted context omitted.

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.

I think the point is that Gitlab faces unique challenges because anyone can host Gitlab on their own hardware, so they're always trying to solve performance problems in a way that any typical user could also solve it. Github on the other hand can use strategies solely targeted at their SaaS performance. It seems that Github also maintains more control over their enterprise version than Gitlab but I'm not 100% sure th…

https://gitlab.com/gitlab-org takes 4 seconds to load on my machine with a gigabit wired connection.

https://github.com/github takes ~2.2 seconds, but by about 1 second has most of the information on screen and is simply waiting for the activity graphs.

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

#246

Post by jcoffland »

thewhitetulip wrote: post #85
jcoffland wrote: post #64

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!

Or a day.

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

#247

Post by lhorie »

nkohari wrote: post #232
duncanawoods wrote: post #209

Earlier quoted context omitted.

I think this proves lhorie's point. Markup syntax is dominated by code when you are building complex dynamic apps instead of static documents. What do you really gain by putting angle brackets around Avatar instead of calling a function? FWIW I believe new react devs are slow to realise they can use local variables like this because JSX looks like it is doing string templating instead of object instantiation.

The example I gave was simplistic, but the value of JSX is the ability to easily nest elements. For instance, let's take my previous example and say we're creating a profile link: const Dashboard = (props) => { const {user} = props; let link; if (user) { link = ( {user.name} ); } return ( {link} ...some other content... ); }; If you want, you could create a `createProfileLink()` function, or you could create a `Profi…

I disagree in two ways: the first is that the ability to write template composition procedurally isn't specific to JSX. You can do that in plain js/hyperscript just as well.

The second point is precisely that this is procedural code. If the ability of putting together templates procedurally is the pinnacle of templating power/expressiveness, we might as well go back to Backbone.js.

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

#248

Post by jayajay »

philliphaydon wrote: post #134
jayajay wrote: post #59

Earlier quoted context omitted.

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.

> I hate writing react.

Out of curiosity, what was the straw that broke the camel's back?

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

#249

Post by iamleppert »

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.createDocumentFragment. These are perfect 1:1 browser APIs that allow you to do everything you've ever wanted, there's no magic, they call directly into the browser engine to give you what you need.

If you want to increase performance, start first by measuring everything. Time to first byte. Time to DOMContentLoaded. The page onload event. window.performance timings; do real user monitoring, not TODO app benchmarks on the latest framework flavor of the week.

The entire web community needs a healthy dose of pragmatism. But it's okay, it gives me extra work. I really enjoy doing freelance performance work and telling everyone which code/library/framework is to blame for performance issues and rewriting everything so simply. Show people what works and you'll find they shut up real quick.

Post reply on HN