In JavaScript, everything is 'truthy' or 'falsy', and for numbers 0
means false
, everything else true
. So you could write:
if ($(selector).length)
You don't need that >0
part.
The approach you suggest is not guaranteed to give you the result you're looking for - what if you had a tbody
for example:
<table id="myTable">
<tbody>
<tr>...</tr>
<tr>...</tr>
</tbody>
</table>
You would end up with the following:
<table id="myTable">
<tbody>
<tr>...</tr>
<tr>...</tr>
</tbody>
<tr>...</tr>
</table>
I would therefore recommend this approach instead:
$('#myTable tr:last').after('<tr>...</tr><tr>...</tr>');
You can include anything within the after()
method as long as it's valid HTML, including multiple rows as per the example above.
Update: Revisiting this answer following recent activity with this question. eyelidlessness makes a good comment that there will always be a tbody
in the DOM; this is true, but only if there is at least one row. If you have no rows, there will be no tbody
unless you have specified one yourself.
DaRKoN_ suggests appending to the tbody
rather than adding content after the last tr
. This gets around the issue of having no rows, but still isn't bulletproof as you could theoretically have multiple tbody
elements and the row would get added to each of them.
Weighing everything up, I'm not sure there is a single one-line solution that accounts for every single possible scenario. You will need to make sure the jQuery code tallies with your markup.
I think the safest solution is probably to ensure your table
always includes at least one tbody
in your markup, even if it has no rows. On this basis, you can use the following which will work however many rows you have (and also account for multiple tbody
elements):
$('#myTable > tbody:last-child').append('<tr>...</tr><tr>...</tr>');
Best Answer
Your opening sentence was actually a very good statement of the differences between Backbone.js and jQuery, so let's unpack it a bit.
For one thing, the two libraries are not at all in competition--they are complimentary.
As an example, here are some things I would do with jQuery:
And some things that I might do in Backbone.js:
jQuery excels at the micro level--selecting page elements, smoothing out the differences in how browsers handle events.
Backbone.js is more big-picture. It helps you manage data and application logic. In the photo album example above, Backbone provides several useful structures: you'd have something to contain all of the data related to photos (a model), a list of all the photos in the album (a collection), and somewhere to put logic that determines what happens when a user clicks on a thumbnail (the view). Those are the main pieces in a Backbone control or application.
Backbone.js benefits from jQuery, though, or something like it, to help render the results of your application's data and logic into the DOM. It's common, for example, to use jQuery to select the element on the page that will serve as the container for your Backbone app. It's also common to use jQuery's
$(function () {});
to fire up the pieces of your Backbone control. You'd probably display form field validation error messages with jQuery as well.You can certainly build big, complex user interfaces in jQuery. We have a few in the app I maintain at work. But they are difficult to work with because jQuery isn't designed to provide structure to an application. In particular, jQuery's API, which is based around selecting groups of items and then passing callback functions that manipulate those items, isn't a good pattern to use in a large, complex control or app. You end up with a lot of nested functions and it's very hard to see what's going on.
I'm currently reworking one of those controls in Backbone.js. As a final example, here's a quick summary of how my thought process differs when working on the same control in both different libraries.
In jQuery, I'm worried about:
li
elements I want?input
elements on the page?In Backbone, I'm more focused on:
jQuery handles the nitty-gritty details, and Backbone is more high-level.
In closing, notice I've been using the words "control" and "app" when discussing Backbone.js examples. It's not true that Backbone.js is just for single page apps. It is true, though, that Backbone.js is good for building complex applications that manipulate data and handle a lot of logic. It would be silly to use it for small-scale UI elements--the extra structure it imposes isn't needed.
Update: On the issue of multiple pages, yes, Backbone does provide a powerful mechanism for persisting your data. Each model has a
save
method that will execute an AJAX call to store the changes on the server. So as long as you save your data as you go, you can have a multi-page app. It's a very flexible model, and it's how we'll probably end up using Backbone at work. While I would love to build a single-page app, we have 10 years of work in our existing multi-page application. We're looking to rebuild some of our more intense UI components in Backbone, then sync the changes to the server before the user moves to a different page.