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

61–70 of 228 posts

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

#61

Post by aquark »

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…

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.

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

#62

Post by camus2 »

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…

> After all the excitement about Angular for example, I went to learn about it and just got lost with new concept DOM transclusion, scopes, services, directives, ng-apps, controllers, dependency inversion and so on. I can use it but need someone to hold my hand. It reminded me of Enterprise Java Beans.

AngularJS has a serious "naming" problem.

Most these concept are easily understood when explained the right away,what AngularJS doc doesnt do. The only complicated thing to grasp is the digest cycle. But anything else is trivials.It's nowhere near the complexity of Java EE.

Scopes are easy,like any composite structure you have nodes with children and parents ,what make scopes special is that they can inherit properties from their parent scopes.

Directives are just custom html elements/attributes where you should do dom manipulation,all other angularjs components should be free from any DOM manipulation,Directives are the closest thing to react components.

Controllers represent the state of the view,when the data in a controller changes, a view that exposes that data changes and vice et versa.

Services are dumb objects that can be shared between controllers and dependency injection is the way one share these services. Controllers can references services ,and services can reference other services. Services are singletons

So there is nothing really complicated with all these concepts,just that the doc sucks for some reason.

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

#63

Post by babs474 »

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…

In the case of Om, I believe the immutability of clojure helps out and makes the diffing of databound elements a simple (non-deep) compare.

You can end up making an app with quite a number of elements flying around.

A neat pixel editor example: http://jackschaedler.github.io/goya/

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

#65

Post by jlongster »

ben336 wrote: post #59
jlongster wrote: post #45

Earlier quoted context omitted.

It adds history?? What is the URL changing to?

URL doesn't appear to change in chrome, but the back button just cycles through the various demo screens after you've scrolled down for a while.

Oh, that's because the demos are loaded in an iframe. Not sure what the best solution is, but I'll think about it. Thanks.

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

#66

Post by swannodette »

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.

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

#67

Post by ThomasDeutsch »

malvosenior wrote: post #55
ThomasDeutsch wrote: post #46

Earlier quoted context omitted.

I would love to support a JS project that is something like a port of OM to JS.

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…

OM and ClojureScript are great - but it is all about choice. Sometimes i prefer/need JS as a language.

It would be great to get the AMAZING clojure-community ideas into the JS world.

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

#68

Post by camus2 »

malvosenior wrote: post #55
ThomasDeutsch wrote: post #46

Earlier quoted context omitted.

I would love to support a JS project that is something like a port of OM to JS.

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…

it's really unfortunate clojurescript is not written in javascript (or clojurescript, like coffeescript compiler is written in coffeescript ). I wanted to integrate a lisp to a toy jsbin app (https://mparaiso.github.io/playground/), but no way, right now i'm using outlet. See the use case? clojurescript is never going to be big in javascript land if one cant compile it in the browser.

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

#69

Post by badman_ting »

I recently watched a presentation about React's approach (I think from a recent JSConf) and it sold me, at least enough to try. The approach makes total sense to me, and I agree with many of its criticisms of Angular in particular. I really loved the reconsidering of our idea of "separation of concerns", that if we reconsider the scope of the concern, we can devise an approach where templating and logic go together. I'm excited by these ideas.

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

#70

Post by spicyj »

camus2 wrote: post #51
platz wrote: post #26

I was at a meetup where the speaker suggested react is great for business-like apps, but for things with an insane amount of dom objects like html games, it tends to get bogged down. Since React claims to be super fact, has done a performance comparison to see in what situations and how much better react performs in certain cases, compared to say, angular.js or more vanilla frameworks? (Also I hear that there is a re…

if you are going to update the DOM 60 times per second no databinding/reactive whatever framework makes sense. there is so much overhead with these solutions performances would just be bad. However it would be interesting to extract the virtual DOM from React to use it in the context DOM based games, being able to mark elements as dirty in order to redraw them is a usefull feature.One just doesnt need all the JSX/dat…

JSX is a build step and is completely optional. If by "databinding stuff" you mean React's setState and friends, almost all of React's code deals with the actual diffing and browser handling. Components are not much more than functions from props to a virtual DOM output. It's easy to use React without ever calling React.createClass (just pass the output of React.DOM to renderComponent). Still, we're looking at separating these parts of React so that you don't have to pay the file bytes but it's not a very significant difference right now anyway.
Post reply on HN