Resources like this are exactly what I've been searching for while learning clojure(script). Really great work.

Many of the comments seem to be along the lines of "why create a markup syntax to build more markup and throw it in JavaScript" - In my opinion that's not the real benefit of JSX, but just one use case.

The great thing about JSX is that it doesn't build markup. It doesn't even need to be used for markup, it can be used for anything. It's frequently associated with markup because it has been used alongside React, but JSX standalone is a simple syntactic transform for XML-ish notation to JavaScript.

This is quite convenient in some cases, as you can elegantly write DSL's, where each of the tag names are JavaScript functions - and writing the equivalent JavaScript would look something closer to a lisp (moving the function name to the right of the paren).

This:

  <Database name="business">
    <Table name="user">
      <Column name="id" type='int' length={10} />
      <Column name="first_name" type='string' length={255} />
      <Column name="last_name" type='string' length={255} />
      <Column name="choice" type='enum' values={['a', 'b', 'c']} />
    </Table>
    <Table name="account">
      <Column name="id" type='int' length={10} />
      <Column name="first_name" type='string' length={255} />
      <Column name="last_name" type='string' length={255} />
      <Column name="choice" type='enum' values={['a', 'b', 'c']} />
    </Table>
  </Database>

run through the compiler[1] becomes this:

  Database({name: "business"}, 
    Table({name: "user"}, 
      Column({name: "id", type: "int", length: 10}), 
      Column({name: "first_name", type: "string", length: 255}), 
      Column({name: "last_name", type: "string", length: 255}), 
      Column({name: "choice", type: "enum", values: ['a', 'b', 'c']})
    ), 
    Table({name: "account"}, 
      Column({name: "id", type: "int", length: 10}), 
      Column({name: "first_name", type: "string", length: 255}), 
      Column({name: "last_name", type: "string", length: 255}), 
      Column({name: "choice", type: "enum", values: ['a', 'b', 'c']})
    )
  )

I find the first easier to read / reorganize in blocks, which can be useful in lots of situations... definitely not all situations - but having declarative markup while being able to imagine it executing as the latter, constructing actual JS objects with specific logic built in - rather than needing to "parse" the XML tree and deal with an extra step of execution, etc, etc.

[1]: http://facebook.github.io/react/jsx-compiler.html

I find the first to be much worse, if for no other reason because of the redundant closing tags.

We're not writing for the compiler. For humans, the "redundant" closing tags serve as excellent markers.

Still, I'm happy that the days of "ENDIF" are mostly behind us

This particular human dislikes writing and reading redundant tags.

I'd be much happier with s-exps and JSON is close enough.

> JSX standalone is a simple syntactic transform for XML-ish notation to JavaScript

But not necessarily the same translation as in your example (that is, tags to function calls and attributes to first arguments). Perhaps all existing implementations work like that, but the spec leaves the JavaScript representation undefined. The spec draws attention to this intentional ambiguity when it lists “a set of transpilers that all conform to the JSX syntax but use different semantics on the output”.

Browserify's --debug flag sets up source maps per-file and works just fine for me with transpiled CoffeeScript files (mapping to the original .coffee)

I'm not sure if there's something different about TS and React but I'd imagine if they have source map support it should work similarly?

"The Good Parts" is still a good one, but my recommendation these days now goes to Effective Javascript:

http://www.amazon.com/Effective-JavaScript-Specific-Software...

Outside of books, http://superherojs.com is another good resource to recommend.

Thanks!

http://superherojs.com look really good. I'll definitely check it out.

I think your best bet would be going with something like node.js' util.inherits, a standalone version for the browser can be found here:

https://github.com/isaacs/inherits

Disappointing that most promise articles/tutorials reference Q as the preferred promise library, rather than bluebird - https://github.com/petkaantonov/bluebird

Bluebird is not only so fast that it's almost on par with callbacks[1], but also innovates on the ability to filter on catching different error types[2], support for generators[3], context binding[4] among other things.

[1]: https://github.com/petkaantonov/bluebird/blob/master/benchma...

[2]: https://github.com/petkaantonov/bluebird/blob/master/API.md#...

[3]: https://github.com/petkaantonov/bluebird/blob/master/API.md#...

[4]: https://github.com/petkaantonov/bluebird/blob/master/API.md#...

We just started using Q for our all--aaaargh, motherfucker.

Great to see progress being made, I guess. :(

The important thing is you're using promises. The differences between Q and Bluebird are minimal, compared to promises vs raw callbacks.

I just found this after some cursory Googling and haven't tried it at all, but it appears to be a compatibility layer for Q on top of Bluebird (written by the author of Bluebird): https://gist.github.com/petkaantonov/8363789

Yeah, for the work we're doing, promises are awesome. I've been doing node work recently and really it's the only thing I've seen that makes sense to me for managing this.

It's interesting--I'd considered myself pretty OO in my style, pass a message, hope for the best, but the promises stuff is kind of taking that to its natural conclusion.

I would not say this[1] is a minimal difference :P

[1]: https://github.com/petkaantonov/bluebird/blob/master/benchma...

I am pretty certain he means in terms of code delta.

yes! I recently switched from Q to bluebird and it's been great, and really is exceptionally fast. Also the source code is a work of art - extremely highly optimised.

Bluebird is definitely the way to go, we recently introduced it to an existing 100K LoC code base and we couldn't be happier.

The stack traces and error management is amazing and everything is very fast.

That library looks pretty cool and is fairly popular , i will give it a try.

There's actually already an open source blogging platform called Wardrobe: http://wardrobecms.com using the Laravel PHP framework, it has support for plugins, and is actively under development.

https://github.com/wardrobecms

https://github.com/wardrobecms/wardrobe

"blogging platform" - "wardrobeCMS". Uh, what now?

I'd actually created Bookshelf after seeing a lack of good support for SQL abstractions in javascript, especially comparison to other languages and frameworks.

In terms of maturity, Bookshelf & Knex are still definitely young and a work in progress, but fairly mature in the sense that they are both heavily inspired (and in Knex's case, mostly copied) from the excellent Laravel PHP framework's query builder and ORM. Bookshelf also adapts different conventions I found useful from Backbone.js' Models, Collections, and Events - I'm also aiming to eventually make the libraries usable outside of Node (webSQL or otherwise).

I've been looking to take the best from other languages' data interfaces and try to adapt them into a few great packages for javascript, as opposed to completely re-inventing the wheel.

Some of the differentiating features include eager-loading and nested eager-loading relations, the ability to constrain those relations[1], polymorphic relations, a distinct separation between the ORM and the query builder layer, and until recently transactions (which from what I've heard, sequelize has begun to add to the library).

Some things that Bookshelf doesn't have out of the box are explicit typecasting (hooks exist to handle this if you need, but most times the db takes care of this for you) or validations (IMO out of scope for Bookshelf/Knex, but something I'll have incorporated in my next database package), and static finder methods `User.find(1)`, `User.findOrCreate({...})` - easily added but these will also come in the next package in progress.

Bookshelf aims to be a simple Data-Mapper, rather than a full out Rails ActiveRecord style ORM... This is something that will be a different project entirely which I'm actively working on building out. Sitting atop of Bookshelf, it will include scopes, validators, callbacks, helper methods, etc.

[1]: https://github.com/tgriesser/bookshelf/issues/69#issuecommen...

Well, in that case you'd lose the stack trace. If you just set the object's prototype to Error.prototype, and you add additional properties to the object's prototype you'd be modifying the Error's prototype as well.

The aim of this helper is to create a custom object which has the same functionality as a traditional Error object.

Shouldn't be tied to SQLite (the underlying query builder/orm support Postgres), it's just not "officially" supported yet.

So in theory putting in the correct connection config should allow you to use Postgres.