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

201–210 of 304 posts

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

#201

Post by Bahamut »

lhorie wrote: post #192
j_r_f wrote: post #176

Earlier quoted context omitted.

I think you are being a bit overdramatic about JSX. There was zero learning curve -- except for a few errors initially when using class instead of className... The argument that DOM.div() is more readable than is honestly hilarious to me. Any non-trivial tag structure will be unnecessarily complicated through the API. Especially when you can just write it almost exactly how it's going to look when it becomes HTML in…

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?

className was named that to avoid conflict with the JS class syntax originally I believe, since JSX is inline - they probably could put in the work to change it at this point, but it seems like a minimally beneficial change but massively disruptive at this point.

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

#202

Post by pluma »

nikcub wrote: post #95
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.

Disagree. React was released in 2013, but use didn't take off until Dan Abramov released his Flux implementation, Redux, in early 2015[0]. That is a full two years of a Javascript view library with the backing of Facebook where it didn't leave much of a mark vs angular. Most of the projects that contributed to React/Redux becoming popular[1] were developed outside of Facebook - altho some of those developers went on…

A slight tangent: I'm not sure I agree with giving Redux all the credit. There was definitely already some momentum going when Redux was first released although it certainly acted as a multiplier.

It's important to remember that even when Facebook first spoke about Flux there was no Flux library. Facebook's Flux implementation came out very late and even then it pretty much only consisted of the dispatcher. There was no example project to look at so all the "Flux-likes" (of which there were many) tried to look at what FB had presented with an MVC/MVVM mindset and attempt to guess what they meant.

This Cambrian explosion of "Flux libraries" (few of which really deserve the title) had mostly fizzled out by the time Dan presented his talk on time travel debugging (i.e. Redux). I guess without Redux the community would have settled on something with a lot more ceremony until Rx gained traction -- we certainly wouldn't have seen libraries like MobX and I'm fairly sure Apollo would have looked quite different. Maybe Relay would have been more popular.

That said, your core argument still holds: the React ecosystem, although heavily sponsored by Facebook, is not dependent on Facebook by far. There are alternative engines for JSX that aim to be compatible with React to varying degrees (e.g. Preact and Inferno) and Relay is the only state library out there that's directly tied to Facebook the same way React is.

Additionally because it's not a monolothic framework but an ecosystem of libraries, React is more adaptable to change. If React were taken in a direction the community disagrees with and make a hard cut like Angular 2 did, Preact could evolve independently and continue providing compatibility layers for React users.

On another tangent: the problem with React/Redux is that neither React nor Redux depend on the other and there are other combinations (like React/MobX or Preact/Redux) that share the same general ecosystem. But I guess the same could be said for early GNU/Linux. I've settled on just talking about "React" the same way I settled on talking about "HTML5" when that became a thing ("Is the new website HTML5?" "Yes, by definition.").

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

#203

Post by dahauns »

mgkimsal wrote: post #153
OJFord wrote: post #118

I'd only heard of Vue as a name before this, but I followed the link to the documentation, which looks fantastic: {{ message }} var app = new Vue({ el: '#app', data: { message: 'Hello Vue!' } }) > Hello Vue! > This looks pretty similar to just rendering a string template, but Vue has done a lot of work under the hood. The data and the DOM are now linked, and everything is now reactive. How do we know? Just open your…

vue feels to me like a condensed knockout. i still use knockout on some projects, but have used vue on a couple new ones too. as much as I'd like to see knockout progress - simplify a bit more to be more compact like vue, i'll take vue if that never happens. anyone using knockout looking to migrate, vue is a worthy spiritual successor imo.

Heh, after a quick look at the examples I tend to agree. Looks actually a lot like durandal (lifecycle hooks!) plus the knockout.punches syntax enchancements (the local filters look nice!), minus the dreaded parentheses. :)

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

#204

Post by debaserab2 »

lhorie wrote: post #192
j_r_f wrote: post #176

Earlier quoted context omitted.

I think you are being a bit overdramatic about JSX. There was zero learning curve -- except for a few errors initially when using class instead of className... The argument that DOM.div() is more readable than is honestly hilarious to me. Any non-trivial tag structure will be unnecessarily complicated through the API. Especially when you can just write it almost exactly how it's going to look when it becomes HTML in…

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 job of keeping your logic in javascript and out of your template.

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

#205

Post by andrewstuart2 »

tashoecraft wrote: post #182
jamra wrote: post #73

Earlier quoted context omitted.

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, Observab…

Also jumping in. The biggest problems with Angular2+ is that they called it Angular, and had a terrible release. It's not Angular, it's a completely different framework. They rode their own hype train and it's made searching for tutorials, examples, libraries much more difficult. I was lucky in that we didn't start our project until after the true release happened, but having such a long alpha, beta, and release cand…

> They rode their own hype train

This is my single biggest problem with Angular 2. It's not Angular, but in calling it "Angular 2," they effectively killed off a powerful framework which had a promising future, all while basically hamstringing Angular 2 from the start for (at least) the reasons you mentioned.

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

#206

Post by nkohari »

lhorie wrote: post #192
j_r_f wrote: post #176

Earlier quoted context omitted.

I think you are being a bit overdramatic about JSX. There was zero learning curve -- except for a few errors initially when using class instead of className... The argument that DOM.div() is more readable than is honestly hilarious to me. Any non-trivial tag structure will be unnecessarily complicated through the API. Especially when you can just write it almost exactly how it's going to look when it becomes HTML in…

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 values are ignored in JSX:

    const Dashboard = (props) => {
      let avatar;
      if (props.user) avatar = ;
      return (
        
          {avatar}
          ...some other content...
        
      );
    };
Regarding class vs. className: class is a reserved word in JS. It's not really a perf thing, it's the fact that JSX was intended as a very simple transform. If JSX used class instead of className, the transpiler would need to be contextual since "class" would sometimes mean "css class" and sometimes "JavaScript class". The baseline complexity for the parser would be higher and could lead to all sorts of complexity. Rather than deal with that the React team avoided the problem by using className instead, keeping things simple.

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

#207

Post by jmtulloss »

Bahamut wrote: post #201
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?

className was named that to avoid conflict with the JS class syntax originally I believe, since JSX is inline - they probably could put in the work to change it at this point, but it seems like a minimally beneficial change but massively disruptive at this point.

It was named that to match the DOM api[0], which React does whenever possible. The DOM api is probably named for the reason you state.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

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

#208

Post by noir_lord »

jeswin wrote: post #54
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…

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…

> Examples being history management and back button, state management (especially if you prefer immutability), and server side rendering.

Maybe/maybe not, I use a Mini-SPA approach where I pass down libraries.js, bundle.js and foo-page.js (all minimised and such) on the initial page load I pull the data and pass that down as well (avoiding the round trip).

With that approach I get most of the benefits of an SPA in terms of behaviour but without having to use client side history management and I don't break the back button.

I still get to issue calls and such and the actual orchestration of the page side js is done with a very light class that each page extends from that has just a handful of methods.

Component orchestration is managed with pub/sub.

I've found it an extremely nice way to develop, there isn't a massive duplication of code and it's very easy to reason about, it lacks a few of the benefits of a pure SPA but has most of them and the separation is very easy.

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

#209

Post by duncanawoods »

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

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

#210

Post by miskin »

swah wrote: post #144
elliotlarson wrote: post #65

Earlier quoted context omitted.

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

Nice thing about Vue.js is that you can get quite far with JS links only, no need for npm. I recently used it for tiny pet project and was surprised how useful it was. And I am no JS pro.
Post reply on HN