Live data from Hacker News

Removing User Interface Complexity, or Why React is Awesome

jlongster.com

181–190 of 228 posts

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

#181

Earlier quoted context omitted.

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.

There's really nothing to 'master' about react, that's the beauty of it really. You just learn about react's view of how data flows through an app with props and state; and that's pretty much it.

Yes that is, I guess, what I like about!

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

#182

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.

I feel kinda bad that you're being downvoted. I also felt the presentation was a little jarring. The right panel seemed to change at strange times related to the content I was reading. Perhaps it was an overuse of the "change things while the user is scrolling to make it seem cool" theme I've been seeing a lot.

On the other hand, I actually found the content pretty great, but I'm not a web developer so take that with a grain of salt...

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

#183
post #91

Earlier quoted context omitted.

Certainly, but sloppy developers using Javascript makes it way easier to break the back button than server-side rendering.

You can break the living hell out of the back button with server-centric solutions (hello asp.net, and POST's for everything)

Fair point. I feel like us server folk have figured that part out by now at least, the Javascript stuff is still quite the wild west on the client.

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

#184
post #179

I experimented with React a bit but I was a bit bugged by how large it was. The basic idea of rendering to a virtual DOM and having unidirectional data flow is really simple but I had trouble actually diving in to React's source code and seeing things under the hood (for example, I had to find a blog to see how the diffing algorithm worked). What are the other libraries out there that we can use for this virtual DOM…

While the basic idea of rendering to a virtual DOM is simple, making it work well for large applications require a lot more than a toy implementation as described in the article.

In order to get adopted, React needs to coexist with existing applications/third party libraries that do manual DOM mutations. The life cycle methods are there to deal with this.

React implements its own class system that supports mixins and type annotations. The plan is to change the API to use ES6 classes (we're working to improve the standard to support all React use cases).

React re-implements its own event system in order to make it fast, memory efficient and abstract away browser differences.

Making composable components is not as straightforward as it first seems. There are a lot of edge cases like refs, owner/parent to be handled.

Then, as you mentioned, there's the diff algorithm and batching strategies which need to be implemented in a performant and memory efficient way. And provide hooks for the user to be able to give it hints via shouldComponentUpdate.

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

#185
post #74

Earlier quoted context omitted.

That's a very good point. I've currently settled on Backbone to give my stuff a bit more structure, but I suspect some of the complication of construction might actually disappear when using React. Not all of it, of course, but some of it.

You'll find a surprising amount of it will simply disappear. I'm at the point where I removed my models and collections directories entirely; since the only feature they provide me at this point are getting data from the server (which I can do with just jQuery, superagent, etc.)

And then you manage it in what way?

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

#186
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…

The trouble is that many devs can't see past that 80% to see the 20% that's left. They whip up a little app at night, it works really nicely and they assume this means the app they're working on during the day should be "rewritten" in the framework-du-jour. Then they hit that 20% "wall", blame the framework as "lame" and start hunting for an alternative. Rinse and repeat.

Last year I got excited about NodeJS and started working with it quite heavily. Then I started to see holes - difficult debugging, so-so tooling for development, mixed bag of JS components, and so on. I then stepped back and realized that although it was interesting, and I can see it useful for some specialized server-side development, I don't see it as compellingly different than current alternatives (Rails, .NET, PHP, etc) to try to build a whole web app with it.

To extend your argument, I would state that frameworks are only about speeding up the initial creation of an application that fits into a narrow set of assumptions. Frameworks, by their very nature, capture a set of decisions by their designers about how an app should work (or behave). As long as your app fits nicely into this box and you can live with the downstream risk that maybe it won't one day, then go for it.

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

#187
post #177
post #118

Earlier quoted context omitted.

There's this: https://github.com/mereskin/jsxify But really, once you get used to keeping everything together it really does feel better . You just have to try it out. Personally, since I use CoffeeScript, I like this lib: https://github.com/atom/reactionary which, since it strips out the required `null` or `{}` first parameter, feels very much like haml or jade.

I use coffeescript too, so I should be able to use reactionary to write the dom helpers it exposes in my JSX. So then the coffeescript -> jsx on server side, then jsx -> javascript browser side, is how it works, right? I think I'm slowly being convinced putting it together in the same file makes sense, since it's a single component, and the what's being displayed is coupled with what you'd do with it, so I guess it s…

Well, the way you should do it is abandon .jsx completely, and just stick to .coffee.

Something like this:

React.createClass

   render: ->
 
      {div, h1, span} = require 'reactionary'

      div class: 'home',

          h1 "Hows it going!"
Clean and simple, particularly with CoffeeScripts default return.

As far as templates go -- and this is what I always tell people -- structure your code in a clean way which makes the render function pop out and you might as well be working with a separate file! It really does make more sense after a while.

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

#188
post #116

Earlier quoted context omitted.

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!

I've been learning CLJS for a couple months. Here's a syntax guide and a list of resources I've used: https://github.com/shaunlebron/ClojureScript-Syntax-in-15-mi...

Thanks so much for posting this! I haven't found anything this concise before, with such a specific target.

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

#189
post #116

Earlier quoted context omitted.

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!

I've been learning CLJS for a couple months. Here's a syntax guide and a list of resources I've used: https://github.com/shaunlebron/ClojureScript-Syntax-in-15-mi...

After browsing around, you're GitHub repo is a learning treasure. Thanks for posting all of that stuff in such a clear way.

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

#190

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…

In Ember, for instance, it's perfectly easy for a "computed property" on a View object to return the value of an attribute on a DOM node. In this model, the DOM is the "canonical" representation of state (also fulfilling HATEOAS if "real REST" is your thing). This is a perfectly fine way of doing things, and is possible in Ember or React or any of the above frameworks as far as I'm aware. How the binding between java…

I think you'll be happy with the stuff I've been working on. Should have something to show off in the coming weeks :)
Post reply on HN