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

81–90 of 228 posts

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

#81

Post by Zelphyr »

aquark wrote: post #61
Zelphyr wrote: post #49

Earlier quoted context omitted.

You hit the nail on the head why these things are bad. You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality. These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of…

Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors. The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.

I disagree that its frameworks all the way down. There is a distinction between frameworks and libraries. React, Angular, et al are frameworks in the truest sense of the word.

Things like jQuery and Underscore on down to stdio.h are libraries. You can pick and choose from what they contain but they're not so tightly coupled that they get in your way.

They're a tool belt with tools that do one thing and do it really well. Frameworks are like having a tool belt with a hammer that also has a saw on the end but in order to use the saw you have to grab the screwdriver even if you're not actually using it.

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

#83

Post by mercer »

Zelphyr wrote: post #49
IanDrake wrote: post #34

Tester: The UI is wrong right here... Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.

You hit the nail on the head why these things are bad. You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality. These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of…

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 with javascript, the DOM, and how the web works.

If your point is to underline that using frameworks without understanding them is a bad thing, I fully agree. But arguing that 'these things' (frameworks) are bad just seems silly.

Clearly some clever people at Facebook found it useful to abstract certain things in a certain way, and many other people (some clever) like their approach. They've actively considered IanDrake's problem (in fact, they talk about this in their talk on React), and felt that their solution was good.

If I can build a performant client-side-heavy web-app in half the time because of React, I'm doing the client a service, not a disservice.

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

#84

Post by rimantas »

aquark wrote: post #61
Zelphyr wrote: post #49

Earlier quoted context omitted.

You hit the nail on the head why these things are bad. You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality. These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of…

Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors. The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.

The thing is, for the web you should not need frameworks at all. A couple of libs maybe, but what we are seeing now is getting ridiculous.

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

#85

Post by jlongster »

swannodette wrote: post #66
tomdale wrote: post #50

This is a really thoroughly researched post and jlongster has my gratitude for writing it up. I have two concerns with this approach. Take everything I say with a grain of salt as one of the authors of Ember.js. First, as described here and as actually implemented by Om, this eliminates complexity by spamming the component with state change notifications via requestAnimationFrame (rAF). That may be a fair tradeoff in…

To clarify, Om does not "spam" state change notifications via requestAnimationFrame - all rAF calls are batched. For example if a state change occurs we schedule re-render via rAF. If another state change occurs we will not call rAF since one is already queued. In fact no state changes can queue another rAF until all changes in the current cycle have been completely flushed.

I think I said that it did in my post, and I was wrong. Will update

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

#86

Post by mercer »

adamors wrote: post #76
camus2 wrote: post #32

Earlier quoted context omitted.

Angular solves more than the UI problem,React on its own doesnt solve the architecturing problem , AngularJS does. The big weakness of Angular is server side rendering,which involves heavy solutions like phantomjs,while you can render react components on the server. Angular is not very good at rendering/managing svg either,that's a fact. I would argue maintaining pure html templates is not that hard. But frankly Angu…

> Angular solves more than the UI problem Hence my question. I feel like for some apps I don't need 60% of what Angular has to offer (routing, controllers, modules etc.) I would be satisfied with just directives. Which are probably the part of Angular I like the least. For SPAs I see no other alternative to Angular currently. In instances where I need heavy JS only on some pages, I'm not sure.

React with a simple router and perhaps some help with your models (Flux or Backbone) might be enough for your needs. Any user behavior that requires new data could be an ajax call that passes back the entire state of the current 'page', which could then replace the state of top-level component (since you want most of your state to reside there anyways). React takes over from there. You'd be relying mostly on your server-side framework for the logic.

You could then incrementally add logic client-side to improve performance, if that's necessary (if the state object becomes too large, for example).

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

#87

Post by [deleted] »

DougBTX wrote: post #75
tomdale wrote: post #72

Earlier quoted context omitted.

I guess this discussion hinges carefully on our relative definitions of "spam." ;) What I mean to say is that, changes or not, the browser will be invoking your diffing algorithm every 16ms.

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.

[deleted]

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

#88

Post by asolove »

tomdale wrote: post #72
swannodette wrote: post #66

Earlier quoted context omitted.

To clarify, Om does not "spam" state change notifications via requestAnimationFrame - all rAF calls are batched. For example if a state change occurs we schedule re-render via rAF. If another state change occurs we will not call rAF since one is already queued. In fact no state changes can queue another rAF until all changes in the current cycle have been completely flushed.

I guess this discussion hinges carefully on our relative definitions of "spam." ;) What I mean to say is that, changes or not, the browser will be invoking your diffing algorithm every 16ms.

He's describing using rAF essentially as a form of throttling, to make sure you render at-most once per frame, but usually much less often.

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

#90

Post by catshirt »

NathanKP wrote: post #31
catshirt wrote: post #19

Earlier quoted context omitted.

what does React bring to the table here that Ember, Backbone, etc. don't? i could register my Backbone or Ember views with Bower all the same.

This comment from another HN poster does a good job of describing the difference between components in React and "components" in Ember and Backbone: https://news.ycombinator.com/item?id=7738511 Long story short, React has a much more graceful system of making the components generalized instead of the adhoc system that Ember and Backbone use. Ember and Backbone have features that are similar to components, but compone…

so as i understand, the benefit is that React encourages standard I/O. but i also understand that nothing is stopping anyone from using a standard I/O with Backbone or Ember (which i recognize is why you say "from different people").

my point is that it's a people problem as much as a tooling problem. or is it impossible to build incompatible React views?

i'm currently working on a library that makes it easy to share patches (GUI included) for audio applications. i'm using React. one problem i struggle with is that without my own additional standard, nothing is preventing anyone from making a component that can't patch in. which is the same problem i would have if i were using Backbone.

if you're looking for a "standard" way to share components you need to make assumptions about what type of GUI you are building- not just how you are building it.

Post reply on HN