Can somebody tell me the difference between these two statements. They return the exact same results, but I was wondering if there was a preferred method or if there was any difference in performance.

SELECT [Comment], [CommentDate], [UserName], [Avatar]
FROM [Comments]
INNER JOIN [Users]
ON [Comments].[UserID] = [Users].ID
WHERE [Comments].[BlogID] = 1
ORDER BY [CommentDate] ASC

SELECT [Comment], [CommentDate], [UserName], [Avatar]
FROM [Users], [Comments] 
WHERE [Comments].[BlogID] = 1 AND [Users].[ID] = [Comments].UserID
ORDER BY [CommentDate] ASC

The first method is preferred, but there will probably be no difference in performance.

David

I do not think there would be any performance difference.

however, I would prefer the first method since it is very apparent to the programmer

SELECT [Comment], [CommentDate], [UserName], [Avatar]
FROM [Comments]
INNER JOIN [Users]
ON [Comments].[UserID] = [Users].ID
WHERE [Comments].[BlogID] = 1
ORDER BY [CommentDate] ASC

the second method is a cross join but since had the condition in where clause - it will  return only the cases where both the userid m

Using the second method, it's too easy to miss/fail-to-add the join predicates and running cartesian product queries, which means "users X comments". However using the first method you can not make this mistake, query parser fails and warns you.

Re performance..  Where you have joins it is advisable to have indexes on both columns

Just a note on the second solution as "old fashioned joins": OUTER JOIN's by using *= and =* are deprecated since long time and Discontinued Database Engine Functionality in SQL Server 2014

So better use the first solution.

Note, however, that the OP question was about inner joins. The old-style syntax for inner join is not deprecated. It is indeed alive and kicking, in both SQL Server and ANSI SQL.

Having said that, I fully support the usage of new-style join syntax. I never use the old-style myself. :-)

Can somebody tell me the difference between these two statements. They return the exact same results, but I was wondering if there was a preferred method or if there was any difference in performance.

Frankly, both are pretty bad and violate all kinds of ISO-11179 rules and best practices. Let me get some of those out of the way first.  

You have a magical "id' that changes into a "user_id" in violation of the Law of Identity from freshman logic. We do not put an ORDER BY on a query today. We do sorting and presentation work in a presentation layer. In fact, this is often done on a report server with special hardware for the sorting, so that the database does not have to carry that load. 

Identifiers are not numeric; we do no math with them. You failed to use aliases, so your code is hard to read. Here is a re-write and back on topic:

SELECT comment_txt, comment_date, user_name, avatar_img
  FROM Blog_Comments AS C
       INNER JOIN 
       Users AS U
       ON C.user_id = U.user_id
 WHERE C.blog_id = '001';

The FROM clause is executed first and in theory materialized to be handed to the WHERE clause to be filtered, and finally the SELECT clause is executed. The truth is that the optimizer can re-arrange the code anyway it wishes. This should also work: 

SELECT comment_txt, comment_date, user_name, avatar_img
  FROM (SELECT user_id
          FROM Blog_Comments 
         WHERE blog_id = '001') 
       AS C
       INNER JOIN 
       Users AS U
       ON C.user_id = U.user_id
 WHERE C.blog_id = '001';

Internally, this is probably how the optimizer did this query. In the case of INNER JOINs, this does not matter until you get to really complex, long queries. But with OUTER JOINs, it is totally different. 

Infixed JOINs are executed in left to right order, the ON clause is associated with the nearest JOIN. It can get messy, so use parens and alias thing. 

The infixed notation has an interesting story from that X3H2 meeting when I was on the committee. I will see if I can find an old article I did on this. 

The noobs use INNER JOIN because they cannot think in sets yet. Their mindset is still a step-by-step, linear process model of computing.   Experienced SQL programmers prefer the original notation. We re-arrange the tables in the FROM clause, and the search conditions in the WHERE clause to expose relationships. I use it  as a code smell when I  am fixing bad SQL code. 

If you try this with the infixed notations, it is a mess:

SELECT ..
  FROM Alpha AS A
       INNER JOIN 
       Beta AS B
       ON A.x = B.y
       INNER JOIN 
       Gamma AS G
       ON A.x = G.z;

Or do you put them at the end?

SELECT ..
  FROM Alpha AS A
       INNER JOIN 
       Beta AS B
       INNER JOIN 
       Gamma AS G
       ON A.x = B.y
       ON A.x = G.z;

How much high school math do you remember? You first wrote addition with an infixed +, but when you got to series and sequence, you used notation on a possibly infinite set of addends. 

SELECT comment_txt, comment_date, user_name, avatar_img
  FROM Users AS U, Blog_Comments AS C 
 WHERE C.blog_id = '001' 
   AND C.user_id = U.user_id;

Infixed operators are binary, but RDBMS allows n-ary relationships. Try writing all of the possible infixed versions of this skeleton:

SELECT ..
  FROM Alpha AS A, Beta AS B, Gamma AS G
 WHERE A.x BETWEEN B.y AND G.z;

See also somewhat similar thread

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/ffa69f26-dd25-4a38-a29e-653825f5f062/basic-question-on-joins

Note, however, that the OP question was about inner joins

Tibor, I know, that's why I wrote "Just a note"; in common outer joins are also often used and with the old style join syntax you would have a problem here.