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

151–160 of 228 posts

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

#151

Post by kadhjasdkj »

Zelphyr wrote: post #127
kadhjasdkj wrote: post #115

Earlier quoted context omitted.

So if i may ask, what do you use? Just raw DOM manipulations? I feel like your argument is partially valid, but your argument also sounds like it effectively argues for pure Assembly. Anything ontop of that costs you a ton at the 10% mark. Now, i understand there's a difference between a Framework and a Language, but i hope you can understand my point. I feel like you're going to one extreme, and arguing against anot…

I prefer libraries. I'm partial to jQuery[1] for DOM manipulation, simple effects, and AJAX. I love Underscore. Both libraries allow me to pick and choose which parts of them I can use without imposing on me to do it The $FrameworkName Way. That said, when I can use pure JS I do. Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maint…

Thanks for the additional insight, appreciated :)

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

#152

Post by peterhunt »

spankalee wrote: post #143
jlongster wrote: post #137

Earlier quoted context omitted.

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

HTML is a great DSL for creating static HTML.

When you start to bolt on features for dynamism in HTML you end up with Angular. The reason that it has all of those complex features is because it needs them to build real world apps. I'm sure once people have built more stuff with Polymer you'll start to see similar "feature creep".

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

#153

Post by natural219 »

nostrademons wrote: post #124

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 javascript and DOM is registered is entirely up to the library developer.

In my ideal world, I want the performance of the Virtual DOM / rAF batching described in the blog post, I want web components as the underlying DOM / markup that represents my views, and I want to wrap them with Ember-like computed properties and routing structures. But hey, while we're asking for everything, I'd also like universal flexbox implementation, Clojure-to-asm.js compilers, ES6 generators to finally come out...

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

#154

Post by __david__ »

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?

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

#155

Post by spankalee »

peterhunt wrote: post #152
spankalee wrote: post #143

Earlier quoted context omitted.

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

HTML is a great DSL for creating static HTML. When you start to bolt on features for dynamism in HTML you end up with Angular. The reason that it has all of those complex features is because it needs them to build real world apps. I'm sure once people have built more stuff with Polymer you'll start to see similar "feature creep".

I've worked with a number of very complex Polymer applications, probably the most complex Polymer applications in existence right now, and the template features have been sufficient so far, and there's always the fallback to code if necessary.

I can think of very few common feature requests (mostly on Shadow DOM, actually), and they don't being to approach the complexity of Angular, which concerns itself with so much more than templating. Angular's complexity is not simply an unavoidable consequence of being used for real world apps - it's just complex.

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

#157

Post by cnp »

__david__ wrote: post #154

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?

The latter. You would use html5's draggable, then update on complete.

Check out http://webcloud.se/sortable-list-component-react-js/

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

#158

Post by cnp »

malvosenior wrote: post #130
cnp wrote: 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!

It's definitely a lot to take on. I'd probably start with just plain Clojure to learn the syntax and how to do functional programming, then look into ClojureScript. Get comfortable using Lein and editing your project.clj, then check out this plugin: https://github.com/emezeske/lein-cljsbuild It's a big investment but learning Lisp will repay you. There's tons of classic CS literature that you'll now be able to unlock…

Totally. Since I started following React and digging into various links and resources the FP paradigm is really starting to make sense in terms of long-term benefit. Time for the next step, however.

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

#159

Post by elwell »

vjeux wrote: post #92
embwbam wrote: 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.

Yes + Instagram web (which is of course part of FB)

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

#160

Post by gooserock »

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 default render automatically without you having to call anything. But if you did, you'd write @render() (because hey, Coffeescript saves keystrokes and sanity). That automatically renders the component in the place you've already specified as its container attribute, or if you haven't it renders to the body by default.

Whereas in React, you have to write this garbage: Bloop.renderComponent(Box(), document.body);

WHY. Can't we write a framework that intuits some of this crap? Shouldn't we use a framework that reduces the time we spend writing code?

Post reply on HN