we are front-enders

I'm not going to discuss where and when you should or should not use semi-colons in javascript, I'm just not qualified enough to do that. I will however comment on some of the arguments that surfaced in this discussion, because the simply lack any longterm vision.

Let's be honest for a minute. Our industry is still young and we are allowed to make some mistakes because even the most visionary, talented people in the industry have a hard time predicting our future. But that is no reason to just do as we please and hide behind such flimsy excuses. Our industry is inexperienced, inefficient and too fragile for its own good and we have to work hard to fix that.

We got away with it for some time because the companies we worked for were equally immature. Slowly they are growing up though, learning the ways of the web and developing broad, overarching visions. Big companies don't just have "a site" anymore, they have 10, maybe 20, sometimes 30 different sites. They are becoming fed up with the fact that after one or two cycles they need an entirely new website, even though much of the new site is just a rehash of the previous one. Companies are starting to understand they need solid, extensible and future-proof frameworks that handle their sites, frameworks that allow for update cycles without having to start from scratch.

Future-proof is the keyword and as an industry we are royally failing at that.

keyword: robust

People's writing style may differ, draconian error handling may save our hides and context may clear certain things up in some situations. You may be coding according to the rules of the game, but if your code isn't sturdy, robust and future-proof you're still doing it wrong. This is not a matter of vision or personal interpretation, but a matter of doing the right thing. If not for yourself, then for the other people who make up our industry.

Robust code is code that survives change. It's code that's written according to best practices advocating future-proof ideologies. It doesn't care much about performance, about writing style or about minimalism. It cares about not breaking. No matter how hard you try to mangle the original code, it should survive those attacks. Nobody knows what the future may bring of course, but if you take into account some very simple rules you can get a long way.

keyword: unambiguous

One of the most important keywords in future-proof coding in ambiguity. Ambiguity kills. Sure enough you can rely on parsers to deal with ambiguity, but you cannot be sure that future or less-capable parsers will (in this case, the JSmin library clearly doesn't). This may or may not be a bug in the JSmin library, the result is that your code was just degraded to a liability. You may want to put the blame with the JSmin library, but it still reflects on your work.

The html5 parser may add closing tags in html for you, but in order to do that it needs complex algorithms that need to interpret the context. The next parser that comes along might lack those algorithms. Just by adding those closing tags you introduce consistency and you remove ambiguity. It's win-win.

If two equal weight css rules match a html element, the css parser will take the last one from the source file. You can exploit this, but this is almost always a sign that your css selectors could be defined better. Not made to be faster, but made to be more correct and precise. If you rely on source file order, you introduce ambiguity and you may ready yourself for some unexpected bugs two years down the line.

And if adding some semi-colons makes your code more robust, you just add the stupid semi-colons. I don't care how valid your code is or what parser is fixing things for you in the background, if you knowingly produce fragile code you're just not fit to be a front-end developer. You're actively hurting our industry and the trust some companies put in us.

conclusion

Killing ambiguity in your code makes it stronger. It helps the code to ready itself for an unknown future. The more you rely on exceptions, loopholes and fixes in whatever parser you're using at the time, the more fragile and less compatible your code becomes. This is not something you can brush away with arguments like "writing style" or "the parser will fix it". It's a reality that has tripped us up time and time again and will continue to do so if we don't change the way we write code.

The times that we could just start anew for each consecutive site update are over. We need to grow up, we need to make sure that the code we write today can still service us two or three years from now. It's a small effort really, but one that will pay off, sometimes in unexpected ways.