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

101–110 of 228 posts

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

#101

Post by mbrubeck »

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…

That's a description of the examples that use "Bloop," jlongster's toy library. Those examples do run a continuous requestAnimationFrame loop.

Om, however, does not call requestAnimationFrame in a continuous loop; it calls it only when the state changes.

(To be fair, jlongster's article originally said that Om also rendered continuously, but that has now been corrected.)

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

#102

Post by stcredzero »

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…

I would be nervous about building a large-scale app

I have a Javascript game client that does rendering optimization by comparing a 79x25 grid of numeric values with JSON data it receives from a server. That is just short of 2000 items, and it is enough to stymie older versions of Firefox running on Core Duo machines. I also queue things, and in fact, the "diffing" and the rendering happen in two different rAF frames, and it's still a challenge for older versions of Firefox running on Core Duo machines.

I wonder if this sort of benchmarking been done on different machines and different versions of the various browsers?

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

#104

Post by Flimm »

Flimm wrote: post #11

Please don't break the back button (Firefox and Chrome). In Firefox 29.0 on Ubuntu 14.04, the left sidebar with the text of the blog disappears and is replaced with a white space. I do not experience this on Chrome.

The second bug I mentioned only happens when I'm zoomed in 120%, which I am by default. Here's a screenshot: http://imgur.com/eDvLdMK

(As someone who doesn't work much with Javascript I thought the explanation was enlightening, BTW)

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

#105

Post by davidgbeck »

badman_ting wrote: post #69

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

Seems like putting templates inside js is a step backwards. The advantage is that you can package templates together with js? That problem is still solvable while maintaining separation. For instaces with browserify tramsforms you can just require( 'my-template' ).

https://github.com/epeli/node-hbsfy https://github.com/rotundasoftware/nunjucksify

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

#106

Post by baddox »

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.

Your comment implies that you recommend web apps never do any DOM generation or manipulation using JavaScript, and are instead purely static HTML documents. For that matter, your argument would logically extend to opposing backend HTML generation as well, like Rails templates.

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

#107

Post by Zelphyr »

mercer wrote: post #83
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…

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 result is that all those speed gains you realized early on are completely lost (and then some) because you're fighting with the framework.

So sure, understanding the framework might help you with that last 10%. But I personally think you're better served mastering JS, the DOM, and how the web works. Which really isn't that hard by the way!

And anyway, if frameworks were so great why are there so many? It seems like a new framework gets announced every week here on HN. The shear tonnage of frameworks alone makes me question their value[1].

Now if none of that can convince you, consider this; the company I work for got rid of all their framework programmers and replaced them with me and a couple other software developers who have experience building products without using frameworks. And they pay us more money than they paid the framework programmers. Why? Because we did more work with better quality in the first six months than those other guys could do in 2 years of gluing framework code together. That last 10% hit them HARD and cost them their damn jobs!

1: I do recognize that frameworks provide value. My argument is that they are way overused. Great for building working or semi-working prototypes in order to test an idea in the market. Terrible for building anything that needs to be continuously maintained.

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

#108

Post by mercer »

Zelphyr wrote: post #81
aquark wrote: post #61

Earlier quoted context omitted.

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 w…

Thanks for pointing out the distinction. I forget about that sometimes.

That said, React is a "A Javascript Library for Building User Interfaces." And to me me it does feel more like a library than a framework.

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

#109

Post by davidgbeck »

NathanKP wrote: post #5

I really like the core concepts of React, especially the way it is designed to help you organize your code into reusable components. I think the key to making React take off is building a centralized repository for components that are open source. Then building your webapp would be as easy as importing the components you need: bower install react-navbar bower install react-signup-form bower install react-sso-signin-f…

Yes definitely, although I imagine most components will be internal to your own applications as opposed to shared publicly. Web Components is a great model for publicly shared components but not sure how much value it adds for private components. If you are into the component based approach see parcelify and / or cartero as those tools could simply your build process.

https://github.com/rotundasoftware/parcelify/

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

#110

Post by jlongster »

greggman wrote: post #96
jlongster wrote: post #58

Earlier quoted context omitted.

Thanks for the rational response, Tom. I hope this doesn't get buried (someone is going through and downvoting at least all of my comment to 0). Blog posts are best when they are sensational, and I try not to overdue it. I think React has a lot of good ideas, but "revolutionary" is a strong word. I think "refreshing" is a better word. Regardless, I think both React and Ember are the best 2 solutions out there right n…

I think this technique is really cool but I thought I should point out that although continuous rAF makes it easy (you can set state directly), on but FF and Chrome on my machine, even when your page appears to be completely static it's consuming 10-20% of CPU constantly. That's got a couple of issues. 1. It eats my battery 2. It DoSes my machine (10-20% not available for other things) So, please don't do that. Set a…

It's really not meant to be something to use in production. It was fun to run with it, but you're absolutely right. In fact, if you look at my Cortex example I do just that. You will most likely want to use a data structure that knows when something's changed anyway.

But it was a neat way to go from something very simple to more complex.

Post reply on HN