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

Post by wcarron » Tue, Feb 07, 2017, 4:44 PM UTC

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…

Post by ergo14 » Tue, Feb 07, 2017, 4:51 PM UTC

rk06 wrote: post #141

ergo14 wrote: post #77

Earlier quoted context omitted.

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.

Post by zeven7 » Tue, Feb 07, 2017, 4:56 PM UTC

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…

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

    React.createElement("foo", { className: "bar" });

    React.createElement("foo", { 'class': "bar" });

Post by [deleted] » Tue, Feb 07, 2017, 5:01 PM UTC

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.

Post by Cyph0n » Tue, Feb 07, 2017, 5:06 PM UTC

jasim wrote: post #220

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…

In support of this argument - The HTML snippet embedded in `let titleView = " Hello "` can only be parsed as a string. This means no tooling support - no linting, no tags that autoclose, no code formatting. But if you have a distinct syntax for XML, the parser can clearly figure out what the strings are, and what the tags are. First class support for XML is, after using JSX, just so obvious in hindsight if you're bui…