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

201–210 of 228 posts

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

#201

Post by Raynos »

ufo wrote: post #179

I experimented with React a bit but I was a bit bugged by how large it was. The basic idea of rendering to a virtual DOM and having unidirectional data flow is really simple but I had trouble actually diving in to React's source code and seeing things under the hood (for example, I had to find a blog to see how the diffing algorithm worked). What are the other libraries out there that we can use for this virtual DOM…

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 event handling ( https://github.com/Raynos/mercury ). Whilst mercury might not be the best way to structure apps, it's an approach that is getting me far and I'm drawing strong inspiration from FRP and FP systems like Elm and om.

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

#203

Post by spankalee »

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?

There's a really good chance that we'll get scoping for element registration at some point, given that the shadow trees are natural scoping boundaries.

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

#204

Post by [deleted] »

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?

[deleted]

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

#205

Post by yazaddaruvala »

fourstar wrote: post #185
modarts wrote: post #136

Earlier quoted context omitted.

You'll find a surprising amount of it will simply disappear. I'm at the point where I removed my models and collections directories entirely; since the only feature they provide me at this point are getting data from the server (which I can do with just jQuery, superagent, etc.)

And then you manage it in what way?

In a simple React app (ie most apps), you end up storing all your models (as Javascript Objects/Arrays) in one single scope (the "App/Main Component"). As a result you don't need to share things around / access them / listen to them from many different files. They no longer need "managing". I hope that helps.

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

#206

Post by jonase »

camus2 wrote: post #199
grumblestumble wrote: post #194

Earlier quoted context omitted.

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.

I'm very interested in working with SVG in the browser and have found it to work pretty well with React. I built a demo (Code: https://github.com/jonase/elements, App: http://jonase.github.io/elements/) using one of the (increasing number of) React wrappers for ClojureScript (Chrome only for the moment I'm afraid)

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

#207

Post by yazaddaruvala »

pestaa wrote: post #161
vjeux wrote: post #92

Earlier quoted context omitted.

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.

While it isn't impossible for a complex library to become popular, I would be very surprised if a library/framework wasn't kept intentionally "newbie-friendly".

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

#208

Post by Raynos »

ThomasDeutsch wrote: post #46
malvosenior wrote: post #33

For those that haven't tried it, David Nolen's Om for ClojureScript is an excellent React framework. https://github.com/swannodette/om I've not used vanilla React, but Om is certainly fantastic and apparently adds a bunch of stuff that's not in the JS version. Also, a web framework written by the guy that wrote most of the language you're using? Win!

I would love to support a JS project that is something like a port of OM to JS.

I've been building a FP style framework very similar to OM & Elm in plain javascript ( https://github.com/Raynos/mercury ).

It has some of the core features

- immutable data - immutable vdom - global state atom, no hidden local state. - no manual DOM manipulation code (read or write). - a single top down flow of data from input to output - Events and Signals from FRP that can be manipulated using pure higher order functions.

etc.

As a bonus it's very modular, so if it doesn't fit your needs at least some subset of it will.

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

#209

Post by JonnieCache »

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.

I think coming to see that "joke" as deadly serious is a coming-of-age moment for all programmers.

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

#210

Post by mercer »

shaohua wrote: post #196
mercer wrote: post #54

Earlier quoted context omitted.

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?

Yes. Instead of passing the instance variables from the controller to the view, you instead send it to the client as JSON and basically replace the state of the relevant component(s) (through the ajax callback, or whatever method you prefer).

As your app grows, it might become inefficient to send down the now-huge JSON object, and you might want to add some client-side logic to deal with that. However, this might not even be necessary, as 1) even though you replace the entire state, React will only update what changed, and 2) by using optimistic updating on the client (or whatever the proper term is), the user might not notice that the actual data-syncing is a bit slower. Plus, it'll still be faster than a server-side-only approach.

The nice thing is that sending the total state (of the page or component) every time significantly simplifies matters, to the point where you might be able to keep relying on your server-side framework for most of the logic, at least until you need to start optimizing stuff.

Post reply on HN