Hacker News Reader

Comment by swalsh | Hacker News Reader

I never played with React, I like the idea though... however when I looked at the github I pretty much closed the tab after seeing the javascript directly rendering HTML.

Does anyone know if its possible to seperate that in such a way that Angular or knockout works?

Or am I just not "enlightened" about the way it works? Which is also certainly possible.

View on HN

Your reaction is expected, because common experience among ui developers is that you should separate HTML from Javascript. This is supposedly called "separation of concerns".

I invite you to watch "Rethinking best practices", an introduction of what React is and why it was built so: https://facebook.github.io/react/docs/videos.html

You learn that separation of concerns is a good thing, but separating HTML and Javascript is not separation of concerns; it's just an arbitrary separation of technologies.

The mindset of React is that you build independent components, where each one contains everything to render information for the user. Whether you use 1, 2 or 3 technos (HTML+CSS+Javascript) for this component is not an issue and there's no reason to separate them.

also: using straight javascript for view logic versus some crippled template syntax is a huge win.

    for user in users
      UserComponent(user)

is much better than some combination of `ng-repeat`, `ng-repeat-start`, `ng-repeat-end`

Although I never used React, Angular has something similar to "components" called directives which you can configure into something similar to a component. The one issue I have with it is that if you want CSS compartmentalized into the directive it has to be inlined in styles attribute of your template string.

The phylosophy behind react is that you can use standard JS techniques to write your template logic. Since angular uses a fully separate template language then it needs to reinvent things like conditionals, loops, variable scoping, function definitions, function calls, etc.

Compared to other virtual-dom/js-as-a-templating-language tools, the most unique thing about react is the way they handle having a hierarchy of stateful components. Virtual dom is very simple if you only have state at the root level and rerender 100% of the page when something changes but it gets a trickyer if you want to distribute the state in a hierarchical manner.

I've used both and I found React's components much easier to understand than Angular's directives. If you want to create a reusable black-box directive in Angular, you have to understand all kinds of complicated stuff with scopes like isolate scopes and scope transclusion. To do the same in React is trivial because it just uses normal JavaScript functions and objects.

Maybe I'm misunderstanding; I'm not familiar with Angular. Surely with the right classes and ids you can put css anywhere that css can go? How could a framework limit that? Conversely, why would this sort of framework offer any other way to handle styles?

Its not that it's limited, there's just no feature added for styling. There's a place to add a template string in a directive but there's no place to add a "styling string". Typically you just put in classes and ids in your template string that references the global css file/s. If you try to reuse the directive in another project you have to move your css file over as well. The only way around this, or in essence to make a truly self contained and re-useable component is to inline the styles in the styles attribute. It gets a bit ugly in that case.

I would disagree that this is an issue of separation of concerns, but instead it is a self-imposed separation for developer sanity. They are two different technologies, so one has to do a mental context-switch every time they go from writing View code to DOM/template code. Regardless if they are writing them in the same place or not.

I'd also much rather use a restricted templating engine like Handlebars so that my templates are forced to be "logic-less". I really don't think my template should have access to all of javascript.

In my experience the jsx stuff works rather nice and looks like html where javascript just happens to be the templating language (apart from some gotchas listed here: http://facebook.github.io/react/docs/jsx-gotchas.html). And IMHO it pushes you to build small components which fit nicely together in the end.

But then, I like the full javascript approach from the mithril framework too and I haven't build something complex to date.

I agree it seems weird upon first looking at it, but after working with React for some time it feels absolutely sensical to do things this way as opposed to, say, moving your html templates into separate .hbs files.

You could take a look at [Ractive.js](http://www.ractivejs.org/). It's not quite caught up with other frameworks but it has a virtual DOM like React and mustache-style templating.

Reply on news.ycombinator.com