What exactly is parse order and how does it impact my template code and whether I should use embedded templates, global variables, snippets, low variables, stash or any other method that I may not have heard of yet.
Specifically when would I want to use early parsing vs late parsing with Low Variables. Why not just have everything early parsed?
No one can be told what the Parse Order is, you have to see it for yourself.
Jest aside, parse order is a very tricky subject indeed. My PDF and blog article will help somewhat in grasping it, and some might find my Parse Order Pro sides helpful. But those only are pointers to a more general approach to EE's template parsing.
The point is, EE's parse order is linear; things happen after another. The things in this case is the replacing of tags and variables. The happen after another is the order we speak of. Things in the template are replaced, but can only be replaced if they are in the template. When certain tags or variables are put into the template after their parsing stage (according to my pdf) has passed, they will remain unparsed. This is the main reason parse order issues exist.
Now, the PDF and blog post only glances at module and plugin tags, but their parse order is intricate in its own. I tried to explain this in my Parse Order Pro slides, starting from slide #88. I could go on with explaining it, but this post might get too lengthy for that. Instead, I'll answer your last question.
Why not just have everything early parsed?
Main reason: security. The values of early parsed vars can be parsed by EE's template parser, which means they can potentially break the template. This is especially true if the variable type is a text input field or textarea. The user can put anything in there, including tags or even PHP if the template where the variable is present has that enabled. Developers who know what they're doing can use textareas with early parsing turned on (effectively Snippets), sure. But you can hide those, keeping the templates safe from your user's curious little hands.
So, keep your vars as late parsed vars, unless:
You could basically say: enable early parsing if you need the variable content in stages 2 to 8, leave it disabled if you don't.
Of course, you can also parse Low Variables during the Tags stage (#5), in which case having early parsing enabled is irrelevant.
Fleshing this out further to answer (in part) your question of what is parse order.
Essentially, all parse order is - is the 'order' in which ExpressionEngine takes to process (or parse) each aspect from a page being requested to the completion/render of the page to the browser.
The following is taken directly from Low's Parse Order:
Read URI to determine template
Get template from DB, check permissions & authentication
Get template from file
Return static template
1. Parse snippets / global variables, segment variables and embed variables *
Parse date string constants
Parse {template_edit_date} and {current_time}
If present, get cached template, then go to #7
2. Parse PHP on Input
3. Parse simple conditionals: segment, embed, global variables
4. Assign and parse preload_replace variables
5. Parse module and plugin tags
6. Parse PHP on Output
Write cache file
7. Parse advanced conditionals
8. Process embedded templates
Redirect
9. Parse User Defined global variables and others.
Here's a link to Low's foundational pdf -- it's got some more detail which can be useful, and it will am sure update as knowledge grows or EE is extended.
http://loweblog.com/downloads/ee-parse-order.pdf
Since he will likely not do it, I'll also give a link where Low discusses parse order in detail, and in relation to his very well regarded Low Variables, which allow you among other things to work positively with parse order.
http://gotolow.com/blog/parse-order-and-low-variables
These are all important topics, because as programmer-experienced person discover on encountering EE, it's not a conventional scripting language. That's very possibly some of its advantage for more pure designers, as was the original intention.
One reason to use late parsing is that early parsing adds slightly more overhead in a lot of cases. The usual thought is that if you don't need things to be parsed early, you should leave them late-parsed for performance. That said, it's a very minor bit of overhead.
It is also possible that you have some Low Variables and you want to use one of them as input into another one. In that case, using one early-parsed and one late-parsed would guarantee that they were processed in the correct order.
Extremely Contrived Example:
I have some low variables called {one_fish}, {two_fish}, {red_fish}, and {blue_fish}, one of which should run on the site at a time. I want to set up which one runs by using another Low Variable, {type_of_fish}, which is a dropdown with available options one, two, red, and blue.
In this case, I would set {type_of_fish} as early-parsed, and all of my various fish as late-parsed. Then in my template I can do the following:
{{type_of_fish}_fish}
If {type_of_fish} is set to one, the final output from the template parser will be the contents of {one_fish}. If it's set to red, final output will be the contents of {red_fish}.
If you're using Low Variable you can create groups to keep your variable in. These groups parse in the order they are listed. I find it helpful to have two groups, one on top called 'snippets early' and another just underneath called 'snippets later'.
