Answers.Body: <p>My gut says the first option (<code>.first()</code>) is going to be slightly faster, but in real world performance my guess is that it's negligible.</p>
  
  <p>Personally, I think I'd prefer the cleaner, more explicit, syntax of the first.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-21T02:05:45.307Z
Answers.LastActivityDate: 2016-03-21T02:05:45.307Z
Answers.UserDisplayName: Brad Bell
Answers.Body: <p>I noticed that there's quite a big difference in query performance between using <code>first</code> and <code>find</code> if there are many element models matching your criteria. See the example in this answer for some measurements:</p>
  
  <p><a href="https://craftcms.stackexchange.com/questions/12180/optimizing-pagespeed/12182#12182">Optimizing pagespeed</a></p>
  
  <p>In that example, there are lots of images related to each entry queried. It would be interesting to see how it would perform with eager loading. Might be that <code>first</code> is still faster, as you wouldn't get back all the models and you can't (yet?) query for the first element only with eager loading. Probably worth a feature request.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-21T18:50:23.690Z
Answers.Text: Right, the bottleneck with `find()` matching many elements is all of the model overheard when its populating all of those models from the element matches.  No longer an issue in Craft 3, but even on Craft 2 matching 1 element is trivial.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-21T08:06:26.413Z
Answers.LastActivityDate: 2016-03-21T08:06:26.413Z
Answers.LastEditDate: 2017-04-13T12:50:59.930Z
Answers.UserDisplayName: carlcs
Body: <p>With the addition of the null-coalescing operator (<code>??</code>) in Twig, it now appears that the following two examples both provide a way to retrieve the first entry and fallback to <code>null</code> if no entry exists:</p>
  
  <pre><code>{# Get the first entry using the `first` method on the ElementCriteriaModel #}
  {% set entry = craft.entries.section('news').first() %}
  
  {# Get the first entry by accessing it in the result array directly #}
  {% set entry = craft.entries.section('news').limit(1)[0] ?? null %}
  </code></pre>
  
  <p>It seems, with the addition of eager-loading and the alternative results syntax required for accessing eager-loaded elements in our templates, that the latter option may provide a consistent syntax to use throughout our templates vs. swapping between the former and the latter depending on which type of query you are performing.</p>
  
  <p>Aside from the uglier syntax in the option that uses the null-coalescing operator, are there any other tradeoffs to consider in choosing the first method vs. the null-coalescing method when retrieving a single entry?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-21T01:49:29.443Z
Comments.Text: Good question! Also, worth bringing this plugin in to the discussion as a sort of third alternative: https://github.com/marionnewlevant/craft-mn_eager
  
  Personally I would like some (ideally syntactically nice) way of dealing with eager vs. not eager that does not require a plugin...
Comments.UserDisplayName: Jeremy Daalder
Tags: <elementcriteriamodel><conditional><logic>
Title: Are there any tradeoffs if you use the null-coalescing operator in place of first()?
ThreadText: # Are there any tradeoffs if you use the null-coalescing operator in place of first()?
  
  (Asked by: username_0 on 2016-03-21)
  
  With the addition of the null-coalescing operator (`??`) in Twig, it now appears that the following two examples both provide a way to retrieve the first entry and fallback to `null` if no entry exists:
  
  ```
  {# Get the first entry using the `first` method on the ElementCriteriaModel #}
  {% set entry = craft.entries.section('news').first() %}
  
  {# Get the first entry by accessing it in the result array directly #}
  {% set entry = craft.entries.section('news').limit(1)[0] ?? null %}
  
  ```
  
  It seems, with the addition of eager-loading and the alternative results syntax required for accessing eager-loaded elements in our templates, that the latter option may provide a consistent syntax to use throughout our templates vs. swapping between the former and the latter depending on which type of query you are performing.
  
  Aside from the uglier syntax in the option that uses the null-coalescing operator, are there any other tradeoffs to consider in choosing the first method vs. the null-coalescing method when retrieving a single entry?
  
  **Tags:** elementcriteriamodel, conditional, logic
  
  > **Comments:**
  > **username_1**: Good question! Also, worth bringing this plugin in to the discussion as a sort of third alternative: https://github.com/marionnewlevant/craft-mn_eager  Personally I would like some (ideally syntactically nice) way of dealing with eager vs. not eager that does not require a plugin...  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2016-03-21. Score: 1
  
  My gut says the first option (`.first()`) is going to be slightly faster, but in real world performance my guess is that it's negligible.
  
  Personally, I think I'd prefer the cleaner, more explicit, syntax of the first.
  
  
  ---
  
  ### Answer by username_3 on 2016-03-21. Score: 0
  
  I noticed that there's quite a big difference in query performance between using `first` and `find` if there are many element models matching your criteria. See the example in this answer for some measurements:
  
  [Optimizing pagespeed](https://craftcms.stackexchange.com/questions/12180/optimizing-pagespeed/12182#12182)
  
  In that example, there are lots of images related to each entry queried. It would be interesting to see how it would perform with eager loading. Might be that `first` is still faster, as you wouldn't get back all the models and you can't (yet?) query for the first element only with eager loading. Probably worth a feature request.
  
  > **Comments:**
  > **username_2**: Right, the bottleneck with `find()` matching many elements is all of the model overheard when its populating all of those models from the element matches.  No longer an issue in Craft 3, but even on Craft 2 matching 1 element is trivial.  
  
  ---
  
  