1. 11
  1.  

  2. 5

    I keep thinking of switching to React but then I hold back because I keep seeing posts like this.

    These were the biggest takeaways from this post for me:

    JSX sucks. I know, I know! It is “just a plain javascript with special syntax”. Our design&html guys who need to focus on making this specific form beautiful by wrapping its elements in various quantities of divs - right now - they don’t give a sh*t about purity and plain ES6. … JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each … It is not funny to create 6 components when you are implementing really simple calculator widget.

    I’m actually a believer in the component-based design pattern that React has popularized – that’s how I write my non-framework-based, plain vanilla JavaScript code, and it works really great. So the fact that React more or less forces this style isn’t a problem to me.

    However, the difference between my code and React is that I don’t have HTML in my JS files, I leave that in the views. I mean, I really wonder, how do frontend devs cope with React files? If I were a frontend dev and I needed to update the HTML, I sure wouldn’t want to wade through the tree of JS files just to figure out which file to edit.

    And is React really that strict? If it forces you to have tiny component files where every dynamic element needs to have its own component class, then I can totally understand how that would be a pain. I have found that sometimes this doesn’t need to be the case – sometimes it makes more sense for a component class to refer and add behavior to other elements inside of it without those elements being explicit components. This kind of code may get refactored out later, but having that option is nice.

    I can confirm that two-way data flow code sometimes is not as clean to read, but most of these fears are mixed with overall pain about Angular 1 where two-way binding was bad, and still.. probably it was not the biggest fail even there.

    That’s an interesting argument, and I’ve actually never heard anyone make it before, but I think it dovetails with some of the feelings I’ve had about React in the past. Honestly, the first time I read about Flux (or any of its interpretations, such as Redux), it seemed like it was a solution in search of a problem. When I used Angular 1, I definitely encountered problems with two-way binding, so I understand at least on the surface why a one-way flow is in theory better. However, now that I think about it, my problems were with Angular, not with the idea of two-way binding: I was trying to do something fancy with watches, and it backfired on me. So I can’t help but think, if two-way binding had been simplified so that I couldn’t have shot myself in the foot, wouldn’t that have been better than overhauling the ENTIRE app flow?

    1. 7

      Vue.js may be very nice, but this article is uninformed FUD about React.js and JSX.

      Syntax preferences aside, “mixing” views, logic, styles, etc. in js files makes a ton of sense. Colocating things that affect each other and change together makes a lot of sense once you get over the historical accident that has led us to totally separate technologies for structure, behavior, and appearance. React side steps most of the problems that led to the conventional wisdom. For example, traditional template languages are essentially effectual print statements in which order matters a great deal. React components can easily be refactored without worry about that. Similarly, inline styles were considered so terrible because there was no mechanism for abstraction, but JavaScript offers you the ability to create style objects and abstract them with functions, objects etc. just as you would abstract anything in a general purpose language.

      If it forces you to have tiny component files where every dynamic element needs to have its own component class, then I can totally understand how that would be a pain.

      It does not force you to do this. At all. I’ve worked on a few large React.js projects with a bunch of developers of varying skills and everybody finds their own balance for component size, but my advice is as follows: Break components up in to large natural pieces, use local variables to build up little state-free fragments in one large render method. Over time, refactor those things in to methods or components as needed for parameterization, reuse, or performance.

      if two-way binding had been simplified so that I couldn’t have shot myself in the foot

      Two-way binding is a generally bad idea. I’ve written about the fundamental problem here: http://www.brandonbloom.name/blog/2015/04/26/rarely-reversible/

      1. 1

        Cool, I appreciate the clarifications.

        I don’t know if the post you mentioned helped me to understand why two-way bindings are necessarily a bad idea. Can you expound on this? Specifically, 1) what is “reversibility” mean in this context and 2) what do two-way bindings have to do with it?

        1. 1

          My frustration with two-way bindings is that it leads to everything poking everything.

          How easy is it to track a bug to its source? With a clear hierarchy and direction I find it to be pretty straightforward. When it is two-way I find it to be much more complex.

          1. 1

            I used “reversibility” to avoid having to talk about the finer points of functional inverses. I’m saying that if you have f(data) -> view, there’s no way to get g(view) -> data without a very complex set of rules or a overly simplistic one-to-one mapping of data == view. The former is an open research problem and is unlikely to produce a simple solution. The latter just shuffles the problem to somewhere else: “Hey, I have data-binding of this data and this view… but how how do I get that data to data bind?” - You always need a function without a good inverse somewhere.

      2. 3

        There’s a lot to unpack here. I’ll run through some of the more egregious points.

        Purity, immutability and ideology over getting things done

        This claim is followed by a link to an official blog post which suggests avoiding certain patterns.

        That’s it. That’s too much ‘ideology’ baked into the framework. Nevermind that those patterns can be used (and will continue to work indefinitely)

        This is not examining technology on its merits - it is looking for excuses to support a conclusion.

        JSX sucks

        Here we get a flat assertion about readability. It’s neither actionable or falsifiable; no justification is provided for the claim.

        The difference between ‘unfamiliar’ and ‘difficult’ appears to be lost on the author.

        As evidence that it’s hard to read, the author posts an example in JSX. No vue.js equivalent is posted for comparison, and the JSX form provided makes some odd decisions about which readability features to include/exclude (I’d have used whitespace quite differently and destructured the arguments).

        TL;DR

        It’s possible that Vue is the better tool, but the line of reasoning (if it could be called that) followed in this post is no way to make a decision.

        1. 3

          It’s an opinion piece, it doesn’t need to have any sort of great comparison between them. “Why we chose Vue.js over React” can simply come down to “we just like it more” and that’s fine.

          I don’t think anything is egregious in it.

          1. 1

            The only way that first statement could be a reason is essentially, I don’t know functional style and I can’t be arsed to learn it or its benefits. shrugs