Removing User Interface Complexity, or Why React is Awesome • Hacker News Board

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

#191

Post by ebryn » Wed, May 14, 2014, 3:31 AM UTC

catshirt wrote: post #90

NathanKP wrote: post #31

Earlier quoted context omitted.

This comment from another HN poster does a good job of describing the difference between components in React and "components" in Ember and Backbone: https://news.ycombinator.com/item?id=7738511 Long story short, React has a much more graceful system of making the components generalized instead of the adhoc system that Ember and Backbone use. Ember and Backbone have features that are similar to components, but compone…

so as i understand, the benefit is that React encourages standard I/O. but i also understand that nothing is stopping anyone from using a standard I/O with Backbone or Ember (which i recognize is why you say "from different people"). my point is that it's a people problem as much as a tooling problem. or is it impossible to build incompatible React views? i'm currently working on a library that makes it easy to share…

Ember already has what you describe as "standard I/O."

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

#192

Post by possibilistic » Wed, May 14, 2014, 3:44 AM UTC

chc wrote: post #172

camus2 wrote: post #62

Earlier quoted context omitted.

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

As the famous quote goes, there are two hard things in computer science: cache invalidation and naming things. When I first heard it, I thought it was a joke; nowadays I feel like it's barely a simplification.

"And off by one errors".

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

#193

Post by scotty79 » Wed, May 14, 2014, 4:30 AM UTC

joshstrange wrote: post #15

derwildemomo wrote: post #2

As a recommendation to the author, it would make sense to show the example/demo area the whole time, not only once I scroll down. It confused me. A lot.

Agreed, I really like the demo area but it's a bit of a shock when it first shows up.

That demo area sliding out actually caused me to actually read the article. I was just about to close it with "meh, react"

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

#194

Post by grumblestumble » Wed, May 14, 2014, 4:34 AM UTC

camus2 wrote: post #32

adamors wrote: 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.

Angular solves more than the UI problem,React on its own doesnt solve the architecturing problem , AngularJS does. The big weakness of Angular is server side rendering,which involves heavy solutions like phantomjs,while you can render react components on the server. Angular is not very good at rendering/managing svg either,that's a fact. I would argue maintaining pure html templates is not that hard. But frankly Angu…

I'd be interested to know what problems Angular has with SVG. I'm currently working on a fairly large SPA and am using SVG fairly extensively, both for simple stuff like icons and for more complicated things like document annotation. I haven't run into any problems thus far.

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

#195

Post by nitrogen » Wed, May 14, 2014, 4:54 AM UTC

userbinator wrote: post #175

greggman wrote: post #96

Earlier quoted context omitted.

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 consuming 10-20% of CPU constantly It appears you're using a multicore machine with between 5-10 cores. A continuous loop is basically going to keep one core at 100%, which is only a bit of an annoyance with a multicore, but on a single or even dualcore machine (e.g. low-end mobiles), it will make everything else slow to a crawl. It's interesting to note that, were this done several years ago or earlier, it woul…

A continuous loop is basically going to keep one core at 100%, which is only a bit of an annoyance with a multicore, but on a single or even dualcore machine (e.g. low-end mobiles), it will make everything else slow to a crawl.

Not to mention that, even on a high-end laptop, that will drain the battery very quickly and burn your lap in the process.

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

#196

Post by shaohua » Wed, May 14, 2014, 5:07 AM UTC

mercer wrote: post #54

adamors wrote: 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…

I assume you just render a big json from the serverside and let the react component to consume it in getinitialstate() of the root component?

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

#197

Post by munificent » Wed, May 14, 2014, 5:26 AM UTC

nostrademons wrote: post #170

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…

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.

We reinvent C-style prefixes-as-fake-namespaces in HTML tag names when we have a perfectly good Turing-complete language with actual scoping rules sitting right here?

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

#198

Post by sytelus » Wed, May 14, 2014, 5:31 AM UTC

rdtsc wrote: 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…

Angular is huge bloat. Unfortunately Google's name is behind that mess so it will live for little bit longer before getting forgotten.

I myself prefer frameworks that are minimal, least invasive and plays nicely with pure JS/HTML instead of treating them as bug. So anything that requires me to call .createClass to create an instance is out. Personally I've used Knockout.js pretty successfully. I think any average js dev can understand that framework in 15 minute and be productive. Although it's not perfect if you you are looking for idealistic MVC implementation.

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

#199

Post by camus2 » Wed, May 14, 2014, 5:32 AM UTC

grumblestumble wrote: post #194

camus2 wrote: post #32

Earlier quoted context omitted.

Angular solves more than the UI problem,React on its own doesnt solve the architecturing problem , AngularJS does. The big weakness of Angular is server side rendering,which involves heavy solutions like phantomjs,while you can render react components on the server. Angular is not very good at rendering/managing svg either,that's a fact. I would argue maintaining pure html templates is not that hard. But frankly Angu…

I'd be interested to know what problems Angular has with SVG. I'm currently working on a fairly large SPA and am using SVG fairly extensively, both for simple stuff like icons and for more complicated things like document annotation. I haven't run into any problems thus far.

doing something like

doesnt work that well. Displaying SVG has never been a problem,they are like images. Unlike images they can be nested ,animated,modified at run time,scaled... if you think you can just create meta svg shapes with directives think again.

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

#200

Post by nostrademons » Wed, May 14, 2014, 5:40 AM UTC

munificent wrote: post #197

nostrademons wrote: post #170

Earlier quoted context omitted.

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.

We reinvent C-style prefixes-as-fake-namespaces in HTML tag names when we have a perfectly good Turing-complete language with actual scoping rules sitting right here?

I don't mean to evangelize Polymer here - I don't actually have a horse in this race, having recently left Google and being still undecided about which technology my startup will be based upon. I think that the prefixes-as-fake-namespaces approach sucks, but of all the things you can get wrong with your web framework, it sucks a lot less than many other things framework authors do. And it enables the abstraction of "Treat web components like any other HTML tag, except you get to define their object model", which is a really powerful concept, particularly when you consider the possibilities of building the most popular of them into the browser. The problem with all existing JS libraries so far is that they become obsolete as browser technology advances; Web Components is the first one where the components may become the browser technology advances.

To complete your C analogy - yes, C sucks a lot, and it's woefully incomplete in areas like namespacing and packaging. But people still use C, because if you want to do something native it's basically the only choice, and you know that it will interoperate with basically every other language out there. And those people have managed to build some pretty impressive things with C, warts and all, even though a lot of its design choices "will never work" when programming at scale.