React, JSX, and CoffeeScript (opens in new tab)

Exactly what we do and it's eminently readable. Compnents as well end up looking good.

    div null,
      RadComponent onClick: @handleClick, model: @props.thing

and so forth.

I love destructuring in coffeescript, it's one of the best additions ever made to js.

Yup, I like that much better: https://github.com/phaedryx/react-tutorial/blob/master/app/a...

That changes the "feel" of composing without JSX more than anything I've seen so far. Trying to work JSX into my compiling pipeline was an uncomfortable hassle. I'm going to give this a try.

IMHO, that looks a little bit confusing, javascript or coffeescript are not lisp. But still i will give it a shot.

This point comes up often when talking about React. You can still put the templates in your own file that the view requires and renders in the `render()` function. No different than Backbone.

Enyo JS (http://enyojs.com/), which powered the later versions of Palm/HP/LG webOS, expresses its components in JSON as well. Having developed both for webOS and now in React/JSX, I can say JSX is the more easily understood of the two. JSX does enforce small oddities like camel case attributes and always-closed tags since it is XML in the end, but it's closer to HTML and that is reason enough for it to win for me.

There is DOMBuilder with the same array/object syntax and also it has the function syntax too. It can be used server-side and in the browser too because it builds a virtual DOM and outputs HTML string or just uses the browser's native DOM elements. https://dombuilder.readthedocs.org/en/latest/

> [ "div", { class : "a-class" }, [ "span", "you can use all of your json tools to edit the DOM" ] ]

So, that means

  <div class="a-class">
    <span>you can use all of your json tools to edit the DOM</span>
  </div>

, right?

A coworker made something similar that we all appreciated using: https://github.com/nanotone/js-templates

But it's not. JSON doesn't have closing tags, which makes it more difficult to read. JSON is for machines.

I write and maintain a large program written in coffeescript every day, and you're right to be worried.

Coffeescript is has a much trickier syntax than javascript, and if you use it all the time, then the brevity and reduced line noise is a slight win, but you never lose the downsides of the complex syntax.

If you're wondering what's wrong with coffeescript, it basically boils down to the fact that the syntax is chock full of unexpected exceptions. I notice that I and everyone I know sometimes get's surprised by what a piece of syntax actually compiles to (not a good sign).

Some examples:

    f 
      a: 1
      b: 2

compiles to

    f({ a: 1, b: 2 }); 

but

    f
      o

fails to compile (so whether you can break an argument onto the next line depends on whether it's an object literal)

Comma's to delimit multi-line arguments are usually redundant, but not on the first line, so...

    f 1,
      2
      3

compiles to

    f(1, 2, 3)

but

    f 1
      2
      3

doesn't compile at all.

Curly braces aren't entirely optional, so

    o = [ {
       a: 1
       b
    } ]

compiles to

    o = [ { a: 1, b: b } ]

but

    o = [
       a: 1
       b
    ]

compiles to

    o = [ {a:1}, b]
      

Note that this is particularly tricky if you have functions with complexly nested arguments, which is what the original artical is proposing to use for React. In JS that would be messy but unsurprising, but in coffeescript you will run into the occasional miscompilation, especially since it's indent sensitive but very flexible with those indents.

For example you may start out with:

    a 
      href: uri
      span
        className: "x"
        "content"

...then decide to remove the class, and end up with...

    a 
      href: uri
      span
        "content"

But the second example actually nests the content inside the <a>, not the <span> (and it'll crash at runtime since span is passed rather than called).

You can even have code that compiles & runs and just returns the wrong value:

    div
      id: "foo"
      span null
        "content"

vs.

    div
      id: "foo"
      span null,
        "content"

Both result in valid JS that would run and display a valid DOM using React, but that comma changes the generated DOM. No warnings, no errors.

All in all, I'd stay away from coffeescript if I didn't already have a large codebase to maintain. There are a bunch of other, better, compile-to-JS alternatives to make JS syntax less onerous - so you can get coffeescript's advantages without the nasty pitfalls.

I don't know if this is true for CoffeeScript, but sometimes an unfamiliar syntax enables something new and very useful. You won't experience that unless you embrace something very different.

eS6 will have fat arrows, but comparing CS today to JS today, I find the -> and => constructs are more than just an abbreviation, they make it radically easier to write AND READ code that makes heavy use of functions.

YMMV, of course!

It's inspired by a family of languages you probably aren't familiar with. My suggestion is to make simple projects with it, and start small using the features you clearly understand. Overtime you'll get more curious and want to learn the rest of the cool stuff and when you do you'll see ways to slash lines and lines of code from your old js or even cs.

There are better ways to learn new languages but cs is familiar enough to js that once you start coding you'll see it comes more naturally than you think.

The syntax we're talking about above is probably more confusing and less intuitive than 99% of the Coffeescript out there. Don't be alarmed. If you know Javascript, it's pretty approachable. The syntax is small, but all makes sense. You do need to give it a chance (read about it) and actually try it to really like it-- but that's true of any language. What's so amazing about coffeescript is such a small investment of time can payoff so strongly in terms of shrinking your code down it its purest, clearest form.

If you learned Objective-C, CoffeeScript is a walk in the park. A peaceful, elegant, enjoyable walk in the park.

There are actually two main React libraries for ClojureScript, Om[1] and Reagent[2]. There are also other libraries for doing the templating if you prefer hiccup[3] or enlive[4] style templates, which I find a bit more readable than straight function calls.

Overall though, React seems to be shaping up as a great solution for building reactive templates that isn't tied into larger frameworks like the solutions within AngularJS or Ember.js.

[1]: https://github.com/swannodette/om

[2]: https://github.com/holmsand/reagent

[3]: https://github.com/r0man/sablono

[4]: https://github.com/ckirkendall/kioo

There's also Om:

https://github.com/swannodette/om/wiki/Basic-Tutorial

All the parenthesis does not affect noisiness in any way. Common misconception. They actually make things much cleaner and nicer.

(I'm the post author.) Thanks for reading and commenting!

As I mentioned in the footnote, for my purposes (an app where I am likely to be the only user) I don't care about IE8 support, so it's kind of a bummer that I have to ship support for it. (In my day job I use Google's Closure library which has the same problem -- lots of additional complexity to work around IE bugs. I appreciate that removing this support isn't as simple as just compiling it out, too.) Similarly for the 300ms delay: the delay is gone on current Chrome on mobile (when you're using width=device-width; I only know this because I used to work on Chrome), which is the mobile browser I use.

Another way of saying this is that React is a combination of the virtual DOM stuff and a bunch of other "useful webapp stuff" like making events work across browsers and installing event listeners on the root element etc. I appreciate for you and the React authors' purposes those are the same problem and difficult to disentangle, but all I wanted to use was the virtual DOM part. (I guess the analogue would be like thinking Rails's ActionDispatch library is neat but then discovering you had to use their code-generation scripts and ORM library as well. Sorry if that metaphor failed, I'm not so knowledgeable about Rails.)

Anyway, since I'm mostly just tinkering with React etc. the size thing doesn't matter so much, which is why I put the comment way down in a footnote. But the whole "you must swallow the whole thing at once" thing is also the reason I've never looked into Ember or whichever other comparable framework. Maybe at some point, as a continued learning exercise, I'll attempt to reimplement the subset of React that I actually use to better understand the design space you already know.

huh, I don't find myself mental mapping to js. unless you're referring to during debugging.

The language offers features so that you can use them well. Any bit of syntax can be abused. `))))))`, for example ;)

Optional braces around object literals allow you to write lines like this:

    rectangle x: 10, y: 15, width: 500, height: 500

... and having newlines separate elements in lists makes a ton of sense in a language where whitespace is significant:

    requires = [
      "jquery"
      "underscore"
      "d3"
    ]

... and also helps with the famous trailing-comma-in-IE error and comma-first controversy.

If you're writing something that's convoluted enough that the features aren't helping you ... don't use 'em.

Have you considered adding a macro system to cs? I think it would eliminate the need for stuff like JSX which seems to get reinvented every so often.

Here's JavaScript vs CoffeeScript on the same graph: http://hntrends.jerodsanto.net/?q=javascript%2Ccoffeescript

Both have huge strange drop in Q3 2013. Problem with trends data?

it's an ugly pattern when you're inlining function strings as HTML attributes.

if you can reference functions directly as attributes of your views it actually makes perfect sense.

mixing your templates and your code sucks when you're working in 2 languages across 2 files and you have to glue everything together. as soon as you're writing them both to the same target it makes perfect sense. especially since react still uses the DOM event model behind the curtains.

Actualy is not, IMHO we are not writing templates but components that are meant to be insolate with a single responsability in mind, not more. There, with can start building higher components combining the lower one to make the app, the Reactjs approach hold separation of concerns but in a different way that maybe you are not use to.

If the jsx syntax is what is holding you back is actualy optional like the Reactjs documentation clarify , you can use browserify or requirejs to separate the React.DOM objects in a diffirent file from your logic too. Cheers :)

Exactly this. I feel more in love with TypeScript than CoffeeScript at this point. I think that part of it is that ES6 is absorbing a lot of the need for CoffeeScript.

> I love the philosophy about writing highly decoupled peaces to build a bigger one

Glad to see people are wising up to the benefits of minimal coupling.

For too long, web development seemed to revel in being a pig squalor of software engineering: "move fast and break things/just use Rails!/coupling doesn't matter anymore!" It's probably the influx of new developers. I don't mind that the mistakes are made as much as the collateral damage that occurred to analysis and design phases.

Remember that you can use Backbone Models and Collections and Router with Reactjs only caring for events and views. They really work pretty well.