Live data from Hacker News

Removing User Interface Complexity, or Why React is Awesome

jlongster.com

141–150 of 228 posts

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

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

Libraries like angular and ember are for programming in the large, with lots of code and lots of developers sharing that codebase. They trade simplicity for scalability. You should use them if you know you need them, and if you need them you'll know.

I went through this transition in late 2007, where the app my team was building gradually outgrew simple javascript libraries, and i ended up adopting extjs (the ember of its day) at great cost, but to great benefit. It is 600 kb of js code uncompressed just for the framework, and we not only ended up using all of it, but building a ton of code on top. We needed all that complexity to build the app we work on, but then it is over half a million lines of code by now. If you don't have those needs, the big js frameworks can be more trouble than they're worth, sort of like j2ee vs php.

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

#142

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…

Thank you very much for making the point I was about to.

I was very confused about the Web Components criticism, it seemed like the author didn't understand Web Components at all. My first thought was, "Why would you want to import your element into JavaScript, unless you're going to be doings something scripty with it?"

What you really want to do in a custom elements world, is embrace HTML, as opposed to JS, as the place to build your DOM. Instead of:

    Bloop.renderComponent(Box(), document.body);
do:

    
Then I don't get this paragraph at all:

  > Aren't you tired of having to query the DOM tree and manually manage the structure do 
  > create UIs? Web Components doesn't solve this at all, it just tries to encapsulate the
  > work. The problem is that building apps is building components, so you inevitably are
  > forced back into the manual DOM management to create your app-specific components (like 
  > how you constantly have to create directives in Angular). You also need to jump into 
  > JavaScript to configure and wire up any Web Components you used. It's a very messy 
  > abstraction, and fools you into desiring a pure HTML-based declarative way to write 
  > apps, which like wanting steak but eating liver.
What?

Of course the point of Web Components is to encapsulate the implementation DOM and the work of manipulating that DOM, and not prescribe how it's done, because you can do it in many ways: manually use DOM APIs, use templating like in Polymer, or even use React if you want.

The author then mixes criticisms of Angular with Web Components. Angular doesn't produce Web Components, has far too many complex concepts IMO (like the $scope.$apply example), and so far has rejected a Web Components centric approach (see their 2.0 design docs). You have to create many directives in Angular because it doesn't support standard 2-way data binding to properties out of the box: without directives you can only bind to attributes. Polymer, for instance, doesn't have those problems, and very complex widgets are built with templates.

And the complaint about needing JavaScript to configure Web Components seems to be completely without merit. Web Components imported with HTML imports are fully capable of registering themselves, so the import is all you need. Yes there's some JS under the hood, but you don't see it, and all of "Bloop" is JS anyway, so I'm really lost on this point.

React may be great, but the future is exactly in encapsulating away the work of building custom elements so that an application can be built of elements sourced from different vendors using whatever tools they want to implement them. I would have no problem using custom elements built with React, but at this point I am not interested in components that force me to use a particular framework. Trying to proclaim that all apps should be built with this or that awesome framework, is a quickly aging point of view.

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

#143

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…

Using JavaScript is fine for things that need script, but ultimately, if I'm building HTML, I'd rather do it in HTML. Put another way: HTML is a great DSL for creating HTML.

As for scoping of imports, you do have a point there in theory, but in dealing with quite a few complex Polymer applications at this point I haven't seen that be an issue in practice. The scoping issue is well known among the people working on Web Components, and AFIAK there are plans to address it.

I'm not sure why you think conditionals are complex in templates. Your example might look like this in a Polymer template:

  
    
  
Yes, there's some token overhead, but in the context of a larger template it pays off to have the entire HTML specified in one place, and in a way that mirrors it's output structure, not spread out over often hard to follow imperative code.

However, as you point out, Web Components doesn't prescribe how to manipulate the DOM, so if you still prefer to do it in script, go ahead!

The point is to produce an element where the browser, developer tools, and your users don't have to care what choice you made.

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

#145
post #81
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…

React is a library, plain and simple. It has literally no opinions on even basic stuff like routing, or how to manage application data.

It takes your data as an input and by some mechanism lays out a visual representation of it defined by your components render methods, being sure to update the visual representation as the data changes. The rest are implementation details.

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

#146
post #93

Earlier quoted context omitted.

I agree that a self-hosting ClojureScript compiler is desperately needed and highly desirable.

We'll get there (we're not so far as it is), but it's just not high enough on anyone's priority list yet.

Looking forward to that. I'm a JS dev who learned Clojure through Clojurescript (and D.Nolen's blog). In trying to entice my colleagues to try it, the JVM bit seems to be a bit of a barrier... but the LightTable development loop blows them away.

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

#147
post #72

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.

[deleted]

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

#148
post #97
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…

Your conclusions about how Om works are still inaccurate :)

There is no such limitation about what data structures you can use. There is no state change notification interface for data. Components can update their local state - no notification required here. Updates to global information (the application state) triggers a re-render from the root component of the application. Because of persistent data structures these updates can be done in logarithmic time as we never compute React UI subtrees that depend on unchanged data - it's just a reference equality check (JavaScript ===) in ClojureScript for any given piece of data to know whether it's changed or not.

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

#149
post #62
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,wha…

Great explanation.

Angular attribute directives would map well to React Mixins. They take more work to set up, but with mixins code can at least be reused outside of the inheritance tree.

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

#150
post #91
post #82

Earlier quoted context omitted.

Javascript doesn't inherently break the back button. Sloppy developers do.

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)
Post reply on HN