Live data from Hacker News

Removing User Interface Complexity, or Why React is Awesome

jlongster.com

161–170 of 228 posts

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

#161
post #92
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…

React has been designed to work in Facebook's codebase, to build large features worked on by many experienced developers. The fact that it is intuitive for beginners is a side-effect, not the primary objective.

Don't forget that Facebook invested a what I would call inproportionally lot in the PHP ecosystem primarily to let new employees pick up the pace as fast as possible.

I wouldn't be surprised if React was kept intentionally newbie-friendly, too.

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

#162

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…

According to the Web Component spec a custom element must contain a dash. Also the convention is to use lowercase. http://w3c.github.io/webcomponents/spec/custom/#concepts

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

#163
post #54
post #8

Would you recommend using React instead of Angular for JS heavy areas of a website that is built with a server side framework (like Rails, Django etc.)? I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.

Based on my initial explorations using React with Rails, I'd say React might even be better when used with an existing server-side framework. With React, you can basically store all you data (state) in the root component (which could be the root of your entire page), and replace that with new state without thinking too much about the DOM updates and view changes that result from this. This is perfect for a server-sid…

Can you please explain how to store data from the server on a "root component"?

The data portion is the main reason I was looking at Angular.

Thank you.

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

#164
post #144

Damn, Javascript is only becoming messier. I think I'll just watch it from the distance and wait until someone figures out the best way to deal with it.

That might take a few browser generations sadly. HTML6 anyone?

edit: HTML/next apparently: http://www.w3.org/wiki/HTML/next

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

#165

I like the state and property features of React, but I still don't understand why more people aren't using Chaplin instead. Because quite honestly, the syntax of every other framework - React, Ember, and especially Angular - is complete gobbledygook by comparison. Example: in Chaplin, components are views or subviews (because it's still an MVC framework, which is another discussion for another time). The views by def…

Automatic rendering is fine in small projects. Seemingly random appearance of widgets would, however, drive the debugging person crazy.

Comparing this.render to Bloop.renderComponent is superficial. If rendering needs to have a handle on different resources, you'd either violate the encapsulation in the former example, or write a service to couple them on a separate layer -- that service might as well be called Bloop.

Some of this crap makes hard things possible.

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

#166

So I'm curious how one would implement something like drag and drop in a React app? Would you model the drag in the main data model somehow? Or would you do that all externally (with traditional DOM manipulation) and then update the model when the drag is complete?

I wouldn't use the DOM. To "embrace" React you really need to forgot the real DOM exists and instead track the drag in the components state and handle moving the items around in the render function.

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

#167
post #30
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 feel your pain. I'm a backend guy who has to learn front end all of the sudden. To my mind, React just makes sense . I understand that other modern frameworks like Angular and Ember "make sense" as well, in that they're current best implementations of well-understood best practice, but from my outsider perspective, it looks as complicated and baroque as Catholic theology. Yes, it's all very beautiful and such, but…

If you're a backend person, thinking about Ember as being more of a Smalltalk MVC than a Rails MVC helps a lot.

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

#168

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.

Exactly. React is a fairly simple library that can play well with other libraries, including on the server-side. Angular and Ember are complex frameworks.

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

#169

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…

According to the Web Component spec a custom element must contain a dash. Also the convention is to use lowercase. http://w3c.github.io/webcomponents/spec/custom/#concepts

I know, but I wanted to make the correspondence between the examples as clear as possible, including using the same names. In practice it'd be something like and . (Well, in practice it'd be something like and , but hopefully people get the point.)

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

#170

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…

The problem is that it doesn't scale complexity-wise. You miss a key point with imports: A ` ` imports something into the global scope. There's always one global scope. In my example, I was able to rename Toolbar into MyToolbar and use it in my scope. You lose so much using the DOM as primitive and JS as artifact. And the second you start doing conditional elements (like the tabbed example), Web Components gets prett…

In practice you'd be namespacing your tags, so it'd be things like , , , etc. At scale you want this, as reading the code becomes quite confusing when you rename each component to your own custom name. It does make typing them out quite a pain (as anyone who's worked with YUI or Google Closure can attest), but that's the price you pay for large-scale development.
Post reply on HN