4 ms·

Have you looked at JSX[1] yet? Because I feel it was invented exactly to address your tl;dr - you're writing something that is very close to HTML inside your Ja

by joshma 12y ago

Have you looked at JSX[1] yet? Because I feel it was invented exactly to address your tl;dr - you're writing something that is very close to HTML inside your Javascript, so it definitely seems easier than writing JS snippets in XML. Also, although I've found that ReactJS tends to encourage a more modular component structure (which I'm personally a fan of), there's nothing stopping you from laying out large chunks of a template instead of small snippets. [1] http://facebook.github.io/react/jsx-compiler.html http://facebook.github.io/react/jsx-compiler.html

zoomerang 12y ago
Yep - JSX solves many of those complaints. (My post was more of a reaction to the 'templates are bad' tone than React itself). I'm not a fan of JSX as a templating language, but it's good enough. I still feel that React encourages a style of development that pushes small snippets of HTML rather than full-page templates. Depending on your development style and the type of application your building, this may or may not be desirable. (If you're building something that's inherently component based, then it's good. If you're building something that's not, then it just adds boilerplate). I'm working on a pretty large Angular project at the moment - it's been utterly fantastic, although it does have its warts. (Primarily around maintaining state ). React.JS claims to solve many of these issues, although I'm not entirely sure it solves them in the right way. (I'd prefer to aim for a more FRP approach personally).
- thatguy15 12y ago
  I think the argument React.js and other component-based frameworks like Polymer and Brick are pushing is that you should always be building your application out of self-contained components that have a defined a defined set of inputs. They would argue (and I would agree with them) that "building something that's not" is a code smell. This (in theory) helps code maintainability. The challenge then becomes designing components in such a way that code paths do not need to cross lines between these things.
  - zoomerang 12y ago
    I'd agree, except that I consider the level of granularity to be too fine the way React does it, resulting in too much boilerplate to do simple things.
- Myrmornis 12y ago
  I still feel that React encourages a style of development that pushes small snippets of HTML rather than full-page templates. I work with Django currently. For dynamic content, in order to avoid repetition, we use includes and template inheritance. So that goes in the direction of small snippets rather than full-page templates. Do you not have to do anything similar with your angular templates?
  - ludwigvan 12y ago
    Don't forget inclusion_tags. They are really poorly named though, they would have been much more popular had they been called "components". The primary difference between an inclusion_tag and an include is that with an inclusion_tag, you can define the interface of your component with much more granularity. By default, each inclusion_tag is passed an empty context, whereas an include accesses all the data in the current context. This way, an inclusion_tag provides a much better isolation. One other advantage is, this way, if you need to include some Python logic, you don't need to do all in a single view function. So, assume that your view function responds with a page with 5 components in it. If you follow the include path, all the data preparation goes into the view. With inclusion_tag, you can basically drop to Python at any level. For example, let's say you are viewing a list of questions and answers. Views do not allow you to attach Python code at the question or answer level. You can do it, but you have to traverse inside the data for the whole feed. With an inclusion tag, you can "attach" to the processing at the question or answer level. For Angular folks, an inclusion_tag is very much similar to an angular controller. The primary difference there is again by default, Angular components inherit all the scope (similar to JS scope or Django's include scope), whereas react by default does not pass any variables, you need to pass them explicitly as props to the children (in angular, you need to add some information at the "directive" level to achieve this level of isolation). One alternative for keeping the scope clean while using include is to use the "only" flag though, so if you are not going to do any data processing, that is easier. That said, the use of inclusion_tags is a bit cumbersome, and I'm not making much use of it lately since I have switched to react.js and basically building my components in JS instead.
    - deleted 12y ago
      [deleted]

by joshma 12y ago

zoomerang 12y ago

Yep - JSX solves many of those complaints. (My post was more of a reaction to the 'templates are bad' tone than React itself). I'm not a fan of JSX as a templating language, but it's good enough. I still feel that React encourages a style of development that pushes small snippets of HTML rather than full-page templates. Depending on your development style and the type of application your building, this may or may not be desirable. (If you're building something that's inherently component based, then it's good. If you're building something that's not, then it just adds boilerplate). I'm working on a pretty large Angular project at the moment - it's been utterly fantastic, although it does have its warts. (Primarily around maintaining state ). React.JS claims to solve many of these issues, although I'm not entirely sure it solves them in the right way. (I'd prefer to aim for a more FRP approach personally).

thatguy15 12y ago
I think the argument React.js and other component-based frameworks like Polymer and Brick are pushing is that you should always be building your application out of self-contained components that have a defined a defined set of inputs. They would argue (and I would agree with them) that "building something that's not" is a code smell. This (in theory) helps code maintainability. The challenge then becomes designing components in such a way that code paths do not need to cross lines between these things.
- zoomerang 12y ago
  I'd agree, except that I consider the level of granularity to be too fine the way React does it, resulting in too much boilerplate to do simple things.
Myrmornis 12y ago
I still feel that React encourages a style of development that pushes small snippets of HTML rather than full-page templates. I work with Django currently. For dynamic content, in order to avoid repetition, we use includes and template inheritance. So that goes in the direction of small snippets rather than full-page templates. Do you not have to do anything similar with your angular templates?
- ludwigvan 12y ago
  Don't forget inclusion_tags. They are really poorly named though, they would have been much more popular had they been called "components". The primary difference between an inclusion_tag and an include is that with an inclusion_tag, you can define the interface of your component with much more granularity. By default, each inclusion_tag is passed an empty context, whereas an include accesses all the data in the current context. This way, an inclusion_tag provides a much better isolation. One other advantage is, this way, if you need to include some Python logic, you don't need to do all in a single view function. So, assume that your view function responds with a page with 5 components in it. If you follow the include path, all the data preparation goes into the view. With inclusion_tag, you can basically drop to Python at any level. For example, let's say you are viewing a list of questions and answers. Views do not allow you to attach Python code at the question or answer level. You can do it, but you have to traverse inside the data for the whole feed. With an inclusion tag, you can "attach" to the processing at the question or answer level. For Angular folks, an inclusion_tag is very much similar to an angular controller. The primary difference there is again by default, Angular components inherit all the scope (similar to JS scope or Django's include scope), whereas react by default does not pass any variables, you need to pass them explicitly as props to the children (in angular, you need to add some information at the "directive" level to achieve this level of isolation). One alternative for keeping the scope clean while using include is to use the "only" flag though, so if you are not going to do any data processing, that is easier. That said, the use of inclusion_tags is a bit cumbersome, and I'm not making much use of it lately since I have switched to react.js and basically building my components in JS instead.
  - deleted 12y ago
    [deleted]