|
I may be wrong, but I think it's a matter of complexity and speed. An efficient parser knows exactly what it is reading just by checking the next following word (token) and can act before it even reads the whole thing. Sass uses an "infinite lookahead" algorithm that makes it way slower (maybe doesn't matter for 1 file, it does for hundreds). With sass the parsing is made only when compiling the app, so it can afford the extra processing. On browsers, specially mobile, it can become a problem if you need to do it on all css of all pages. An example that I think it's easy to understand: suppose you are reading a csv string of numbers that can be in base 10 or base 2. Option a is something like "32, 101b, 101" (aka binary numbers have a "b" suffix, decimal numbers don't) Option b is the same but the "b" is a prefix "32, b101, 101" Now think that you can only "see" one character at a time, so you see "3", then "2", then "," and so on. Which of the two options is more efficient to parse? The answer is option b. With option a you could read a sequence of millions of 1/0 digits but you don't know if it's binary or decimal until you read the final "b" or a "," (or end of file) so you can't do anything but remember all the digits until the end, when you can finally do something with the number. With option b you know in advance if it's going to be decimal or integer (whether you receive a "b" or directly a digit) so you can do all the optimizations right away before even start reading the number! It's not a matter of whether it can be done or not (of course it can) but the complexity and slowness it can become. |