tgriesser's comments

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

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.

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#...

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

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.

I recently wrote two Node.js libraries that use promises extensively, an Active Record style ORM http://bookshelfjs.org and Query Builder http://knexjs.org. I actually didn't find a need for many of the higher level functions, outside of .then I'd typically stick to .all, .reject / .resolve, and occasionally .defer.

The source should be fairly annotated and is structured similar to Backbone.js, so it might be useful to take a look through and see where/how those functions are being used.

Bookshelf only focuses on the relational aspect of the ORM, sitting on top of an full featured underlying query builder, http://knexjs.org. It handles eager/nested eager loading properly, as you'd see in something like Ruby's DataMapper or Active Record. It also defines relationships with named methods on the model, which allows the creation of really dynamic relationship with different constraints, etc.

It also has support for handling database transactions, which seemed to be missing in any other libraries I had looked at, and also doesn't force you into a particular way of doing other things like validations or typecasting (though it does provide hooks/events for handling both).

The ORM is also just a single ~900 line file that takes a lot of inspiration from Backbone as being a library you can easily read through and understand, and focus on the important parts of database interaction, rather than trying to provide the kitchen sink.

Thanks for checking it out! While the view/history/router related code should be okay just sitting there unused, I agree that does seem like a bit of a code smell. I know Jeremy has been against modularizing Backbone in the past, and there is something to be said about keeping everything packaged nicely together in a single file - though maybe something like this would change his mind.

It's definitely something I'll begin to look into a bit, possibly splitting up the Backbone components into a separate library specifically for Bookshelf, similar to lodash's custom build process. If you have any ideas for a good way to go about this, feel free to open a ticket.

The underlying query builder - http://knexjs.org - is much more of a 1-to-1 port. Bookshelf shares a number of similar features with eloquent, such as the process of defining relations, and handling eager/nested eager loading, but it also draws a lot of inspiration (and code) from the Model & Collection patterns of Backbone.js.

I owe a lot of thanks to Taylor for writing Eloquent, he has been really helpful with any questions I've had in putting this together.

Thanks, you might also like to checkout the underlying query builder library at http://knexjs.org.

Promises, with q is my preferred method.

https://github.com/kriskowal/q

Yes - view.remove() calls "stopListening" - so when you use "listenTo" all listeners should be taken care of.

This doesn't account for any child-views, or views that don't use .remove(), so you'll need to make sure those are taken care of when a view is destroyed. But in most cases, the garbage collection issues that have been seen relating to views & events are taken care of.

As recurser mentioned, backbone.js tutorials might be a good idea. I'd also recommend reading the source of backbone.js to see how it works internally. It's around 1500 lines of well written and fully commented javascript, and will probably cover everything you're hoping to learn in a very concise and practical way.

With regards to view cleanup code in Backbone - in the github develop branch [1], the view is now a little more active in its memory cleanup. A dispose() function was recently added which removes any handlers added in the view's 'events' object, as well as any collection or model listeners where the view is passed as the third argument (callback context). This function is also called by the view's .remove(), taking care of the majority of basic memory cleanup needs when the element is cleared from the screen.

[1]: https://github.com/documentcloud/backbone/commit/3ae1af6df1b...

I recently came across http://amon.cx/ which does a few of the things you mentioned, and it's a one time purchase (with a free basic version) rather than a SaaS. Might be worth taking a look at.