6 ms·

Almost everything I've seen about React makes me happy. However there are some parts for which I do not understand everyone else's excitement. This presentation

by chao- 12y ago

Almost everything I've seen about React makes me happy. However there are some parts for which I do not understand everyone else's excitement. This presentation contains a great example on slide 53 when it says: "No Templates!" With an exclamation mark, even! What it doesn't tell me, is what is wrong with templates in the first place? I happen to like them versus the feeling the alternative gives: Awkwardly-mixed-paradigms and using string concatenation while attempting to represent one language within another. Can someone who dislikes templates explain? Or maybe explain what a template means to you, as perhaps we're not all thinking about the same thing when someone says "No Templates!"

danabramov 12y ago
Have you seen Rethinking Best Practices video[1] from JSConf? I think it explains the point. [1]: http://www.youtube.com/watch?feature=player_embedded&v=x7cQ3mrcKaY http://www.youtube.com/watch?feature=player_embedded&v=x7cQ3...
- chao- 12y ago
  I have not. I will watch it soon and see if it changes my opinion. And I recognize it is just that: an opinion. A habit developed over time. But as a result, after all these years, I am also familiar with its advantages. The idea of "Data comes from X, gets passed to Y, and combined into a display", where "Y" gets stored in its own file somewhere, can be reused everywhere, and decoupled from whatever is passing it the data that will be displayed within.
  - plorkyeran 12y ago
    The general premise is that in practice templates usually end up very tightly bound to the view using the template, so you're not actually gaining anything by putting them in a different file and there's a lot of downsides to using a different language for templating.
    - chao- 12y ago
      Having watched the talk now, I see what he's getting at. I have maintained, at most, a small-approaching-medium-sized single-page app, and it was an internal tool. Clearly I have not felt any of the same pain that inspired React. But within that particular experience, despite my "underpowered" templating tools, I've settled on a style that very close to what he calls "components", built instead from pairs of one partial and one viewmodel. Tightly coupled (cohesive?) within each pair, but as a unit are reusable together elsewhere in the front-end app. So I can agree in theory, and see where my ideas have wandered close to the path that React takes. Really the only thing to do now is try it on a substantial project to see how it compares in experience. I suspect I'll still feel the urge to want the JSX in a separate file in some cases.
- xtrumanx 12y ago
  Wow, that was a great talk. I really didn't like React and didn't get why they've decided to mix concerns but I think I've understood their design decisions now. I think I'll go give it another try sometime soon.
nacs 12y ago
When I was first looking into Single Page App frameworks, I came across the usual Angular/Ember.js recommendations and tried to get started with them multiple times. I couldn't get myself to stick with them and always went back to mostly server-side rendering with jQuery / Ajax / Pjax tech until I tried React.js later. The primary reason for my dislike in using the Angular/Ember type frameworks is that they have their extensive custom template code and directives that to me was basically like learning a whole new language -- I had no desire to learn things like the framework's method of doing a foreach loop in their own custom way when I can just use JS' foreach with React. I was also not a fan of throwing in all the non-standard tags into my HTML. With React I can write the view in JS or, my preferred method, JSX which is basically plain HTML with curly brackets for variables that compiles into pure JS.
- chao- 12y ago
  I agree. While I'm not as familiar with Ember, one of the things that has kept me from using Angular on more than a few complex pages, is that I would have to rewrite all of the otherwise-functional Handlebars templates we have made thus far. I've even done six or seven custom directives now, and have a feel for "the power of directives" (having heard that phrase a lot), but it certainly isn't what I use most of the time. But this is all an aside from the point of "templates" in general. When I think "templates" I tend to think first of something lightweight like Mustache or Handlebars templates, that I can render client-side (and server-side!) without worrying about anything beyond decorating HTML with a few curly-braces.
  - steveklabnik 12y ago
    > While I'm not as familiar with Ember Ember currently uses Handlebars by default, and will be switching to HTMLbars[1] soon, so it's even better. 1: https://github.com/tildeio/htmlbars https://github.com/tildeio/htmlbars
- deleted 12y ago
  [deleted]
collyw 12y ago
Sounds similar to the "no schema" claims by the NoSQL crowd. I see good reason to have a defined schema in most cases.
DougBTX 12y ago
> and using string concatenation React.js uses a "virtual DOM" made up of JavaScript objects, so there isn't any concatenation of HTML strings, just generation of virtual DOM objects. The next step up from that is their JavaScript variant, JSX, which has HTML-like syntax for instantiating those virtual DOM objects. JSX looks quite like HTML templates, except the programming logic (which in a templating language might be {{if foo}} ... {{/if}} etc) is plain JavaScript. Introduction to JSX here: http://facebook.github.io/react/docs/jsx-in-depth.html http://facebook.github.io/react/docs/jsx-in-depth.html Slide 49 has a bigger example, and the slide before shows the plain JavaScript version: http://murilopereira.com/the-case-for-reactjs-and-clojurescript/#/49 http://murilopereira.com/the-case-for-reactjs-and-clojurescr...
zoomerang 12y ago
I agree very strongly, but I can understand the opposite viewpoint. For me, I like to write HTML in HTML. While I'm primarily a backend programmer these days, I've spend a considerable portion of my career writing HTML, so I'm very familiar and fluent in it. As such, to me, writing HTML as HTML with annotations for data bindings and loop is a much better approach. Anything else just gets in the way of my workflow. AngularJS is the only tool I've used so far that really nails this properly. (At least since Zope) However a lot of developers aren't HTML guys. They think in code, and to them HTML == DOM == a Tree structure. So it makes sense for them to be returning a tree. I quite religiously think the latter is the wrong approach and results in less maintainable code. Instead of having a single template with the entire page clearly laid out, you end up with small snippets of HTML rendered all over the place. This becomes even more jarring when you're working with designers that aren't coders. I manage a team of 7, and Using HTML-based templates means that my designer can write fluent AngularJS templates without developers having to do a thing. The alternative is for the designer to mock something up, and then for developers to cut it up into tiny little pieces and rewrite it in whatever DOM abstraction is the flavour of the month. Try reskinning a site made up of hundreds of small snippets of DOM vs a few complete HTML templates - the latter is far easier. Some developers like to write Dom in Javascript because they know Javascript and don't want to learn another language. To me, the idea that templates are bad because somebody doesn't want to learn another language just reeks of anti intellectual bullshit. Angular template aren't difficult. I'll finish off this post by adding that I much prefer reactive code over imperative observables or dirty-checking, but Angular templates work so ridiculously well it'd feel like a step backwards moving to another framework that didn't have them. My dream toolchain would use something similar to Angular templates, with FRP code behind the scenes. tl;dr To somebody used to writing HTML, building a page by emitting snippets of DOM inside Javascript is about as annoying as trying to write Javascript by emitting snippets of code in XML.
- 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
malandrew 12y ago
There are better templates approaches that don't use string concatenation like HTMLBars and Meteor's Blaze.

by chao- 12y ago

danabramov 12y ago

Have you seen Rethinking Best Practices video[1] from JSConf? I think it explains the point. [1]: http://www.youtube.com/watch?feature=player_embedded&v=x7cQ3mrcKaY http://www.youtube.com/watch?feature=player_embedded&v=x7cQ3...

chao- 12y ago
I have not. I will watch it soon and see if it changes my opinion. And I recognize it is just that: an opinion. A habit developed over time. But as a result, after all these years, I am also familiar with its advantages. The idea of "Data comes from X, gets passed to Y, and combined into a display", where "Y" gets stored in its own file somewhere, can be reused everywhere, and decoupled from whatever is passing it the data that will be displayed within.
- plorkyeran 12y ago
  The general premise is that in practice templates usually end up very tightly bound to the view using the template, so you're not actually gaining anything by putting them in a different file and there's a lot of downsides to using a different language for templating.
  - chao- 12y ago
    Having watched the talk now, I see what he's getting at. I have maintained, at most, a small-approaching-medium-sized single-page app, and it was an internal tool. Clearly I have not felt any of the same pain that inspired React. But within that particular experience, despite my "underpowered" templating tools, I've settled on a style that very close to what he calls "components", built instead from pairs of one partial and one viewmodel. Tightly coupled (cohesive?) within each pair, but as a unit are reusable together elsewhere in the front-end app. So I can agree in theory, and see where my ideas have wandered close to the path that React takes. Really the only thing to do now is try it on a substantial project to see how it compares in experience. I suspect I'll still feel the urge to want the JSX in a separate file in some cases.
xtrumanx 12y ago
Wow, that was a great talk. I really didn't like React and didn't get why they've decided to mix concerns but I think I've understood their design decisions now. I think I'll go give it another try sometime soon.

nacs 12y ago

When I was first looking into Single Page App frameworks, I came across the usual Angular/Ember.js recommendations and tried to get started with them multiple times. I couldn't get myself to stick with them and always went back to mostly server-side rendering with jQuery / Ajax / Pjax tech until I tried React.js later. The primary reason for my dislike in using the Angular/Ember type frameworks is that they have their extensive custom template code and directives that to me was basically like learning a whole new language -- I had no desire to learn things like the framework's method of doing a foreach loop in their own custom way when I can just use JS' foreach with React. I was also not a fan of throwing in all the non-standard tags into my HTML. With React I can write the view in JS or, my preferred method, JSX which is basically plain HTML with curly brackets for variables that compiles into pure JS.

chao- 12y ago
I agree. While I'm not as familiar with Ember, one of the things that has kept me from using Angular on more than a few complex pages, is that I would have to rewrite all of the otherwise-functional Handlebars templates we have made thus far. I've even done six or seven custom directives now, and have a feel for "the power of directives" (having heard that phrase a lot), but it certainly isn't what I use most of the time. But this is all an aside from the point of "templates" in general. When I think "templates" I tend to think first of something lightweight like Mustache or Handlebars templates, that I can render client-side (and server-side!) without worrying about anything beyond decorating HTML with a few curly-braces.
- steveklabnik 12y ago
  > While I'm not as familiar with Ember Ember currently uses Handlebars by default, and will be switching to HTMLbars[1] soon, so it's even better. 1: https://github.com/tildeio/htmlbars https://github.com/tildeio/htmlbars
deleted 12y ago
[deleted]

collyw 12y ago

Sounds similar to the "no schema" claims by the NoSQL crowd. I see good reason to have a defined schema in most cases.

DougBTX 12y ago

> and using string concatenation React.js uses a "virtual DOM" made up of JavaScript objects, so there isn't any concatenation of HTML strings, just generation of virtual DOM objects. The next step up from that is their JavaScript variant, JSX, which has HTML-like syntax for instantiating those virtual DOM objects. JSX looks quite like HTML templates, except the programming logic (which in a templating language might be {{if foo}} ... {{/if}} etc) is plain JavaScript. Introduction to JSX here: http://facebook.github.io/react/docs/jsx-in-depth.html http://facebook.github.io/react/docs/jsx-in-depth.html Slide 49 has a bigger example, and the slide before shows the plain JavaScript version: http://murilopereira.com/the-case-for-reactjs-and-clojurescript/#/49 http://murilopereira.com/the-case-for-reactjs-and-clojurescr...

zoomerang 12y ago

I agree very strongly, but I can understand the opposite viewpoint. For me, I like to write HTML in HTML. While I'm primarily a backend programmer these days, I've spend a considerable portion of my career writing HTML, so I'm very familiar and fluent in it. As such, to me, writing HTML as HTML with annotations for data bindings and loop is a much better approach. Anything else just gets in the way of my workflow. AngularJS is the only tool I've used so far that really nails this properly. (At least since Zope) However a lot of developers aren't HTML guys. They think in code, and to them HTML == DOM == a Tree structure. So it makes sense for them to be returning a tree. I quite religiously think the latter is the wrong approach and results in less maintainable code. Instead of having a single template with the entire page clearly laid out, you end up with small snippets of HTML rendered all over the place. This becomes even more jarring when you're working with designers that aren't coders. I manage a team of 7, and Using HTML-based templates means that my designer can write fluent AngularJS templates without developers having to do a thing. The alternative is for the designer to mock something up, and then for developers to cut it up into tiny little pieces and rewrite it in whatever DOM abstraction is the flavour of the month. Try reskinning a site made up of hundreds of small snippets of DOM vs a few complete HTML templates - the latter is far easier. Some developers like to write Dom in Javascript because they know Javascript and don't want to learn another language. To me, the idea that templates are bad because somebody doesn't want to learn another language just reeks of anti intellectual bullshit. Angular template aren't difficult. I'll finish off this post by adding that I much prefer reactive code over imperative observables or dirty-checking, but Angular templates work so ridiculously well it'd feel like a step backwards moving to another framework that didn't have them. My dream toolchain would use something similar to Angular templates, with FRP code behind the scenes. tl;dr To somebody used to writing HTML, building a page by emitting snippets of DOM inside Javascript is about as annoying as trying to write Javascript by emitting snippets of code in XML.

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

malandrew 12y ago

There are better templates approaches that don't use string concatenation like HTMLBars and Meteor's Blaze.