Hacker News Reader

Comment by danabramov | Hacker News Reader

Oh my, it is beautiful on the inside. Check out the source.

They're totally showing off the power of React component model even when it doesn't render directly to DOM tree: https://github.com/Flipboard/react-canvas/blob/master/lib/Su...

It's about describing nested side effects in time, really.

View on HN

Looking at the author, not surprising. I was an intern in Yahoo! Mobile's web team in 2009, and sat beside Michael Johnston. He was incredibly productive and talented, and was the backbone of the whole mobile team. Everyone came to him for advice. I remember he wrote a sophisticated color picker in an afternoon, and the code was a work of art.

It's worth mentioning that much of the code that integrates with React internals is based on the work in react-art: https://github.com/reactjs/react-art

This is the same technique used by Netflix for their React-based television UI.

https://www.youtube.com/watch?v=eNC0mRYGWgc

Is this faster than the react-art canvas renderer? Why use one vs the other?

Can you point out to what exactly is notable about this code? I don't see anything special.

React is traditionally used for outputting DOM, but in this case components are overriding its hooks to perform another side effect—updating the canvas. This just shows the power of the component paradigm. Just like React Native does it with iOS views. Other view frameworks (Ember, Angular, Riot, whatever) don't even come close to being able to express this, because they're so tied to DOM itself.

Is it possible -- literally -- to write more clear code? Stunning implementation

I have generally done systems and backend work, so usually C/C++/Go/Python. React is making me extremely excited to do some frontend work!

Is React a good introduction to the land of frontend programming? Or do I first need to familiarize myself with vanilla JS and go bottom up to React?

You should def know JS prior to learning React.

This is a pretty great book

http://eloquentjavascript.net/

Both.

Alternate your time spent learning.

Sometimes study high-level, sometimes low-level. (Low-level, tongue-in-cheek, as in "JS is the bytecode of web applications.")

I have a similar path, and honestly found the FE dev tools being the slowest thing to learn about (too many, too frequently updated/breaking things).

I think you can build a lot on top of React with minimal knowledge of js (so, yes, start), but you definitely want to go deep and understand how it works inside (so, yes, also study js).

There's no need to go deep diving on learning JavaScript.

As you're using a high level framework, you're interacting with that more than the details of JavaScript. So in essence you're learning 'React' not 'JavaScript'.

So just start building in React and the JS will come along naturally.

That's not really true. You really need to understand JS to work with React, especially since you need to combine it with other libs since it's only the view layer.

You need to know Javascript's quirks. I generally recommend [1] for experienced developers. Everything on that page is important to know (edit: except the perf stuff, which changes as the js engines get better). I'll second the Eloquent Javascript recommendation in another comment if you're looking for a more involved book.

[1] http://bonsaiden.github.com/JavaScript-Garden/

With the JS quirks out of the way, I would recommend building something in React and muddle through things with SO/google.

The hardest part of frontend dev for an experienced backend dev is the CSS. CSS is conceptually simple but there's a LOT of random domain knowledge you need to get layouts you want. You can bypass a lot of it by using a sass framework (e.g. foundation or bourbon) at the cost of adding a build step and another abstraction layer on top of CSS.

I actually wonder if it can be done even more elegant with RxJS?

You may want to take a look at elm-html.

Also Cycle (virtual-dom + Rx)

Thanks for the heads up about RxJS, didn't know that existed.

Seeing as one of the benefits of React is in server-side rendering, and now with the new OSS nature of .NET, it's worth considering standard Rx as well ( https://msdn.microsoft.com/en-gb/data/gg577609.aspx ).

Rx is very new to me, so I may have this description wrong, but it essentially seems to be well-supported event-driven programming library. Worth a look if you're interested in FRP.

Rx isn't FRP, and doesn't really solve the same problem that react does (view management). Its grew for pushing discrete events around, but doesn't provide for any signals and continuous binding.

Rx programming is so great. It's one of those things that you seldom find a use case for but when you do it leads to 50x easier and more readable code. It truly is for events what Linq was for collections Mostly only useful with more advanced ui and network programming though

Reply on news.ycombinator.com