3 ms·

>That said, this is very obviously a pride war between those who stick to convention and those who undermine it. I'd frame it as "a pride war between people wa

by batista 15y ago

>That said, this is very obviously a pride war between those who stick to convention and those who undermine it. I'd frame it as "a pride war between people wanting a sane codebase not based on fragile parser edge cases --include two that know the language inside out--, and the developer of some minor js code that thinks he's too clever for all that". That's no "undermining convention", that's juvenile bs. I know who I'd rather have on my team.

blasdel 15y ago
It wasn't a "fragile edge case", it worked just fine with no ambiguity in every javascript implementation. The problem is that jsmin is a naive pile of textual replacements (though not quite as abysmal as John Gruber's markdown.pl) instead of being a javascript implementation — something that actually parses javascript into an AST and compiles it to minified javascript. He left out cases for several unary operators so it broke perfectly valid code. After bitching at them he came to his senses and fixed it: https://github.com/douglascrockford/JSMin/commit/5ca277ea452beae1c25db3bc0ef5c81309a3daf4 https://github.com/douglascrockford/JSMin/commit/5ca277ea452... Unless for some reason you need your minifier to be trivial enough to be portable with no dependencies, you should really be using something along the lines of google's Closure Compiler, which produces far better output and even has stuff like tests!
- batista 15y ago
  >It wasn't a "fragile edge case", it worked just fine with no ambiguity in every javascript implementation. Yes, it worked according to how the parser was designed. But it depended on a frowned-upon parser feature (AST), that can lead to ambiguous or faulty results in similar cases, and for no good reason. When the creator of the language and its biggest guru disagree with your code style, well, there's no much room for an argument, even if all known implementations work fine with your code. He also did an idiotic ?: operator abuse instead of a clear "if" in the same exact line. He probably likes silly "succinct code" tricks, which even C people wouldn't touch with a large pole...

by batista 15y ago

blasdel 15y ago

It wasn't a "fragile edge case", it worked just fine with no ambiguity in every javascript implementation. The problem is that jsmin is a naive pile of textual replacements (though not quite as abysmal as John Gruber's markdown.pl) instead of being a javascript implementation — something that actually parses javascript into an AST and compiles it to minified javascript. He left out cases for several unary operators so it broke perfectly valid code. After bitching at them he came to his senses and fixed it: https://github.com/douglascrockford/JSMin/commit/5ca277ea452beae1c25db3bc0ef5c81309a3daf4 https://github.com/douglascrockford/JSMin/commit/5ca277ea452... Unless for some reason you need your minifier to be trivial enough to be portable with no dependencies, you should really be using something along the lines of google's Closure Compiler, which produces far better output and even has stuff like tests!

batista 15y ago
>It wasn't a "fragile edge case", it worked just fine with no ambiguity in every javascript implementation. Yes, it worked according to how the parser was designed. But it depended on a frowned-upon parser feature (AST), that can lead to ambiguous or faulty results in similar cases, and for no good reason. When the creator of the language and its biggest guru disagree with your code style, well, there's no much room for an argument, even if all known implementations work fine with your code. He also did an idiotic ?: operator abuse instead of a clear "if" in the same exact line. He probably likes silly "succinct code" tricks, which even C people wouldn't touch with a large pole...