Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing User Interface Complexity, or Why React is Awesome

jlongster.com

Post reply on HN
Print view View original

121–130 of 228 posts

Re: Removing User Interface Complexity, or Why React is Awesome

#121

Post by jpfuentes2 »

tomdale wrote: post #97
DougBTX wrote: post #75

Earlier quoted context omitted.

Won't that only happen if a state change has been made? That is, the diffing algorithm will only get invoked once every 16ms if the state changes faster than once every 16ms.

Nope, it calls it regardless of state change—that's the point, you eliminate the challenge of determining when state has changed. To quote TFA: > A set method to change state could trigger a rerender (React has setState), but there's an even easier way to react to changes: continuously call renderComponent with requestAnimationFrame to repaint the UI, and only change the DOM when the component returns different conte…

Thanks for clearing up the confusion. Although, I think it's worth it for you to edit your initial reply since it's the most upvoted comment so far.

Also, your comment, to me, shows there is still some confusion regarding Om's internals:

> However, this relies on being able to listen for state change from the underlying model data. [...] Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface.

Actually, the interface used is ClojureScript's flavor of STM: you set your app state, generally a hash-map, in an atom. When you mutate the app state via `swap!` it is published to Om -> React -> render. This may seem like a pedantic distinction, however, the key point is that you are required to use an atom which controls app state mutation. You could also use strings and vectors as your app state if you so choose.

Re: Removing User Interface Complexity, or Why React is Awesome

#122

Post by chrisabrams »

ben336 wrote: post #57
embwbam wrote: post #36

Earlier quoted context omitted.

So I have a word of caution. As someone else in the thread mentioned, React is very intuitive for beginners. There's another framework I've used that was also intuitive for beginners: Backbone. The reason why Backbone is inferior to Angular and Ember is because it optimized for the beginner. Angular and Ember are optimized for the experienced developer on a large code base. Specific to your suggestion, which I think…

Curious why you think Backbone is optimized for beginners as opposed to Angular. I get that Backbone and React have fewer concepts to learn and thus are more approachable. But if you're building serious applications I'd say Backbone and React require MORE experience, because there are fewer choices made for you than Angular (and especially Ember).

I would agree; Backbone and React are tools that help you do the job, but they don't decide how the job is done. That's up to you. Angular is like the cookie-cutter.

Re: Removing User Interface Complexity, or Why React is Awesome

#123

Post by mikewhy »

iamwil wrote: post #41

Has anyone tried to use a different template engine with React? I was just wondering, since I didn't want to use JSX inline, and writing out html with React.DOM isn't appealing either. I just wanted a way to put templates in tags that get loaded by React Components. That way, I won't be mixing templates and the behavior of the components. Has anyone done this before?

There are some conference videos of Peter Hunt where he talks about why this isn't a good idea.

- Placing markup and logic in separate places separates languages, not concerns

- React/JSX has the full power of JavaScript, not some intentionally crippled lookalike

Re: Removing User Interface Complexity, or Why React is Awesome

#124

Post by nostrademons »

I think this post is missing something in its description of Web Components: the fundamental difference between a JS-based framework like React and a Web Components-based framework like Polymer is that the former takes JS objects as primitives and the DOM as an implementation artifact, while the latter takes the DOM as a primitive and JS as an implementation artifact. You cannot wrap your head around Web Components and give both it and JS frameworks a fair shake until you can make this mental shift in perspective fluently.

The line in the post where "You can't even do something as basic as that with Web Components.":

  var MyToolbar = require('shared-components/toolbar');
In fact has a direct analogue with HTML imports:
And that's key to understanding Web Components. The idea of the standard is that you can now define your own custom HTML elements, and those elements function exactly like the DOM elements that are built into the browser. This is a key strategic point: they function exactly like the DOM elements that are built into the browser because Google/Mozilla/Opera/et al hope to build the popular ones into the browser eventually, just like we've gotten and / based on common web usage patterns.

A number of the other code samples in the article also have direct analogues in Polymer as well. For example, the App/Toolbar example halfway down the page would be this:

  
    
      
        
        
      
    
    
      Polymer('toolbar', {
        number: 0,
        increment: function() { this.number++; }
        decrement: function() { this.number--; }
      });
    
  

  
    
      
        {{toolbar.number}}
        
      
    
    
      Polymer('App', {
        created: function() {
          this.toolbar = this.$.toolbar;
        }
      });
You can decide for yourself whether you like that or you like the Bloop example more - my point with this post is to educate, not evangelize - but the key point is that you can define your own tags and elements just like regular DOM elements, give them behavior with Javascript, make them "smart" through data-binding so you don't have to manually wire up handlers, and then compose them like you would compose a manual HTML fragment.

Re: Removing User Interface Complexity, or Why React is Awesome

#125

Post by ulisesrmzroche »

Zelphyr wrote: post #107
mercer wrote: post #83

Earlier quoted context omitted.

I never quite understand arguments like yours. As aquark pointed out, it's 'frameworks all the way down' anyways. Unless you're a one-of-a-kind master, you're always relying on multiple levels of abstraction. I don't know who pointed it out, but I find that a good rule of thumb is to master at least one layer of abstraction below the 'current' one. So in the case of React, you'd first make sure you are proficient wit…

Here's my experience with frameworks: They're really good at getting you to 80% completion really fast. The next 10% takes a little work but its doable. But that last 10%... its like pulling teeth. With tweezers. Covered in grease. That last 10% is the thing you need done to successfully deliver the project but which the framework designers didn't consider. In my experience you always run into that last 10%. The net…

That's a terrible argument my dude. Do me a solid, what do ya'lls variable names look like right now? Or just real quick, LOC on the smallest file you got.

Re: Removing User Interface Complexity, or Why React is Awesome

#126

Post by mushishi »

The awkward right panel that changed abruptly from time to time, especially the first transition, made me skip the content.

Using a non-common ui idiom is risky. The presentation and topic don't match in a way that reader (i.e. me) had enough expectations left when it comes to what you might actually have to say.

Re: Removing User Interface Complexity, or Why React is Awesome

#127

Post by Zelphyr »

kadhjasdkj wrote: post #115
Zelphyr wrote: post #107

Earlier quoted context omitted.

Here's my experience with frameworks: They're really good at getting you to 80% completion really fast. The next 10% takes a little work but its doable. But that last 10%... its like pulling teeth. With tweezers. Covered in grease. That last 10% is the thing you need done to successfully deliver the project but which the framework designers didn't consider. In my experience you always run into that last 10%. The net…

So if i may ask, what do you use? Just raw DOM manipulations? I feel like your argument is partially valid, but your argument also sounds like it effectively argues for pure Assembly. Anything ontop of that costs you a ton at the 10% mark. Now, i understand there's a difference between a Framework and a Language, but i hope you can understand my point. I feel like you're going to one extreme, and arguing against anot…

I prefer libraries. I'm partial to jQuery[1] for DOM manipulation, simple effects, and AJAX. I love Underscore. Both libraries allow me to pick and choose which parts of them I can use without imposing on me to do it The $FrameworkName Way. That said, when I can use pure JS I do.

    Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maintainable", and sometimes they don't see eye-to-eye.
You're right, they don't always see eye-to-eye. Frameworks are handy if you need to "get it done". You also need to educate your customer that you will have to make trade-offs and cut corners when trying to just "get it done". But I also argue that with enough experience you can, in fact, get it done and make it maintainable. I've seen that time and again.

The reason I don't believe you can write something cleanly with a framework and it be easier to maintain is that the framework is a black box of unknowns. So one option, as someone else has mentioned, is to try to fully understand that black box. But then you've just tied yourself to that framework. Wouldn't you be better served mastering the technology that the framework is written in?

1: jQuery proper. jQueryUI isn't too bad but is still a little more black box than I prefer. I really dislike jQuery Mobile for all the reasons I dislike frameworks.

Re: Removing User Interface Complexity, or Why React is Awesome

#128

Post by RussianCow »

svachalek wrote: post #43
rdtsc wrote: post #29

As mostly an outsider to the web front end development, React.js is probably the easiest one for me to understand among the typical "frameworks", especially Angular and Ember. After all the excitement about Angular for example, I went to learn about it and just got lost with new concepts: DOM transclusion, scopes, services, directives, ng-apps, controllers, dependency inversion and so on. I can use it but need someon…

I've been doing Angular for about a year now and am pretty comfortable with it, but I definitely remember going through that brick wall and see it every time I try to explain it to someone new. React looks much more straightforward to pick up but I am curious whether someone who has "mastered" both would find one or the other more powerful or maintainable.

I haven't "mastered" React by any measure, but I've been using Angular for quite some time, and I find that apps written with it become really frustrating to maintain after a certain amount of complexity. I see Angular somewhat akin to C++ in that it's the most powerful and flexible (IMO) of the popular JS frameworks, but you're also going to spend a hell of a lot of time creating your own structure and conventions. This is a fine tradeoff if you need the flexibility, but for my use cases, React is much simpler and less headache-inducing to use. I just find that I can fit React's model into my head, whereas with Angular I'm constantly needing to figure out how to translate my mental model of my app into code that actually works, and dealing with weird, undocumented edge cases.

Re: Removing User Interface Complexity, or Why React is Awesome

#129

Post by skybrian »

nostrademons wrote: post #124

I think this post is missing something in its description of Web Components: the fundamental difference between a JS-based framework like React and a Web Components-based framework like Polymer is that the former takes JS objects as primitives and the DOM as an implementation artifact, while the latter takes the DOM as a primitive and JS as an implementation artifact. You cannot wrap your head around Web Components a…

It's also not either-or. If you have components written in Polymer that you want to reuse, in principle, a React-like framework could render them. (I don't know how well this works today.)

Re: Removing User Interface Complexity, or Why React is Awesome

#130

Post by malvosenior »

cnp wrote: post #116
malvosenior wrote: post #55

Earlier quoted context omitted.

I understand that there are sometimes practical reasons for not being able to use ClojureScript, but have you given it a go? It's really very, very nice (much nicer than JS in pretty much every way). * Immutable data (you can get some of this in JS with Nolen's Mori http://swannodette.github.io/mori/ ) * Better functional programming than Underscore (map :mykey some-objects) * Great syntax: homoiconicity, thrush oper…

I've been trying to move towards ClojureScript for a while, but there are so few introductory resources out there that allow you to navigate between the Clojure world and the JavaScript world in a way that makes sense to people who come from JS backgrounds exclusively. I wish OReileys would issue an expanded version of their Intro ClojureScript book!

It's definitely a lot to take on. I'd probably start with just plain Clojure to learn the syntax and how to do functional programming, then look into ClojureScript.

Get comfortable using Lein and editing your project.clj, then check out this plugin:

https://github.com/emezeske/lein-cljsbuild

It's a big investment but learning Lisp will repay you. There's tons of classic CS literature that you'll now be able to unlock and immutability really is the future, so it's good to start getting acquainted with it.

Post reply on HN