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

221–228 of 228 posts

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

#221

Post by baddox »

IanDrake wrote: post #212
baddox wrote: post #106

Earlier quoted context omitted.

Your comment implies that you recommend web apps never do any DOM generation or manipulation using JavaScript, and are instead purely static HTML documents. For that matter, your argument would logically extend to opposing backend HTML generation as well, like Rails templates.

>you recommend web apps never do any DOM generation Full stop right there and you're correct. I really prefer to limit code that looks like: element.innerHTML = ' Do you really like content in your JS like this? '; I'd rather have the HTML loaded as one file and have the javascript in another acting on that HTML. Right now my favorite library to use for this is Knockoutjs.

Knockout has HTML-esque template too, not unlike Ember or even React.

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

#222

Post by Raynos »

ufo wrote: post #216
Raynos wrote: post #201

Earlier quoted context omitted.

I have a similar frustration with React. The source code is very hard to read our follow. An ideal "barebones" virtual dom library looks like https://github.com/Matt-Esch/virtual-dom . The `virtual-dom` module was build out of frustration with the readability of react source code and is the minimal modular subset. I've also built a small framework on top `virtual-dom` to add in essentials like immutable state and eve…

Is there a single-file version of virtual dom available for download? I am not finding any instructions in the repo on how to build it. Also, why does it have so many files in the first place?

I opened this PR on virtual-dom ( https://github.com/Matt-Esch/virtual-dom/pull/67 ) to get a single file version into the git repo.

It has many folders because the `vtree`, `vdom` and `h` are fundamentally seperate concepts.

Again each one is seperated into it's own files, this allows you to just require the `is-x` functions or the `diff` function alone without having to depend on the entire implementation.

It's also easier to maintain code if it's not one big file.

There are plans to break vtree & vdom out

- https://github.com/Matt-Esch/vtree - https://github.com/Matt-Esch/vdom

Note `vdom` is an implementation detail, we could also write `vcanvas` or `vwebgl`

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

#223

Post by greggman »

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…

It's not really using 100%. rAF means they do their work, then it goes to sleep until the next vblank. They then get their rAF event, check if they want to make any changes to the DOM, queue another rAF and then go back to sleep. So it really is only 10-20%. But it's still 10-20% :-(

I would be curious why it's at 10-20% though. If they don't touch the DOM and their checks are quick (just a pointer as the article says) then there's some crazy serious overhead in the browser or somewhere just to call into JS once every 16-17ms and have it go back to sleep.

It would be interesting to look into where 10-20% is going. It seems like in a perfect impl, a mostly no-op rAF should take 0.001% or something along those lines.

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

#224

Post by slattery »

platz wrote: post #26

I was at a meetup where the speaker suggested react is great for business-like apps, but for things with an insane amount of dom objects like html games, it tends to get bogged down. Since React claims to be super fact, has done a performance comparison to see in what situations and how much better react performs in certain cases, compared to say, angular.js or more vanilla frameworks? (Also I hear that there is a re…

Check out this example of a 3D game using React: http://facebook.github.io/react/blog/2013/08/26/community-ro...

(Wolfenstein Rendering Engine Ported to React)

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

#225

Post by iamwil »

cnp wrote: post #187
iamwil wrote: post #177

Earlier quoted context omitted.

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

Cool, I'll give it a shot.

I checked out reactionary, why couldn't I just do:

{div, h1, span} = React.DOM?

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

#226

Post by krebby »

gooserock wrote: post #160

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…

I've been a longtime user of Chaplin and I love it, particularly when it comes to the Composer and Dispatcher. I've been experimenting recently with killing the view layer completely in favor of React templates, since I think react does a better job of managing view state, but doesn't include the rest of the stuff I need for my app like routing and data management.

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

#228

Post by redOctober13 »

Just want to say thanks to jlongster and everyone who's commented on here; I created an account just to say thanks. I'm an amateur web dev/designer trying to figure out how to move beyond static web pages, and have read what would probably amount to a literal ton of material were it printed out, on frameworks, libraries, and more acronyms than I could imagine. Outside of HTML, JS, and CSS, even "basic" things like Sass and CoffeeScript I hadn't heard of just a few months ago, and I've since been all over the world (wide web) looking for info on ASP.NET (which my group at work decided last year was what we should be doing "web-kinda stuff" in, as well as Angular, Ember, Backbone, Knockout, Node, etc etc, and everything new (to me) that research like that comes with.

The discussion here has led me to a few more things to research, but I feel it's been very helpful in helping me think critically about the vast array of possibilities a budding web designer has to deal with. I just wanted somebody to provide an objective view of "If you're going to be doing medium-complexity web apps end-to-end, then learn ______" and I still would love that, but don't think it's possible to get. The alternative, as I've been doing, is just to learn a little about everything, try to figure out the kind of things I plan to do, and then find the paradigm that works, be it vanilla technologies, something like React, Web Components, or a framework (and I've been trying to learn Angular and like it, but it's tough to grasp). It just seems like as soon as I've decided on what I want to learn, I read a new post with a title like "Why You Shouldn't Use and Why Is Really the Way to Go."

So anyways, a long-winded thanks, but a thank you nevertheless for the open discussion here; I feel better now that I'm not trying to find the one-and-done "best" thing for making web apps in general.

Post reply on HN