I'll start off by saying that I absolutely love the concept of coding towards the specification of a language. Language specifications aren't an opinion. It is an actual fact that you can point to and say, "That's what you are suppose to do according to the specifications. If I do that and it doesn't parse correctly then the parser is a broken tool and needs to be brought up the the standards of the specification." It is a wonderful concept that allows one to write code according to the language and not the tools that use the language.

But sadly, even that isn't enough to bridge the divide between real life people, their interactions with each other and their opinions which inevitably are tied to their feelings as well. (I would like to say that I'm NOT a Vulcan and I suffer from the same human conditions as everybody else, if I talk about problems people have in a generalized sense I am absolutely including myself.)

And even more sadly, is the fact that even the most noble and pure of ideals tend to crumble once exposed to the harsh reality of life.

"That's what you are suppose to do according to the specifications. If I do that and it doesn't parse correctly then the parser is a broken tool and needs to be brought up the the standards of the specification."

-Damn straight!

But... What if that parser (or browser or whatever) is still the best tool? What if its the only tool?
well poo... Sure didn't take long for that ideal to not work out...

What if the specification gives you a choice? For instance.

INFLAMMATORY TOPIC # 1
SEMICOLON DEBATE!
The nature of the problem of using or not using semicolons in your javascript is that both sides of the argument are correct. And for the most part, an individual's preferences, experiences and opinions are not only what drives them to the choice they make in the matter but also perfectly valid and reasonable.

I have exhaustively researched the matter, including reading the ES6 documentation (not all of it, its hundreds of pages long!). The specification of the language itself states that semicolons are optional. I personally love to not use semicolons in my javascript. They are only required in a handful of situations (a for loop is a good basic example) and most of the fears about difficult to track down bugs from not using them just simply aren't realistic. (And carried over from a time when parsers DID create errors more often from omitted semicolons. But that is no longer an issue.) Also, there are a few parsing errors that occur when you do use a semicolon and it doesn't do what you think it does. Those are just as hard to figure out. Either way, abstract semicolon related parsing errors are very few and far between and you won't always escape them regardless of the path you choose. For me it isn't worth it to use them. I love how shaving a character off of every statement subtly cleans up the code and makes it easier for me to read.

I delved into the whole semicolon thing when I was first learning to code because I looked at my javascript one day and said to myself "I think I'm using too many semicolons. It is clear that I don't understand when to use a semicolon. I need to look this up and find out what the rule is." Much to my chagrin there wasn't a real answer. Instead I discovered a battlefield of nebulous standards based on peoples preferences. I continued to use the semicolons religiously because "You're supposed to". But I was still trying to figure out what was the best rule of thumb for when and where to use them. I invested waaaaaay too much time researching the subject. Then I tried to intentionally create errors in lines of code by leaving them out. Surprisingly difficult actually... So I started using them less and less. Then one day I decided to write code complete void of all optional semicolons. It felt gooood... and a little naughty. Like I was Darth Vader all of a sudden. Or maybe Darth Vader skinny dipping while still wearing the helmet...

Its hard to go back once you've tasted the dark side

INFLAMMATORY TOPIC # 2
Sass sucks. And bootstrap sucks. And typescript sucks. Etc.
So I just wanna throw this out there, I'm not a huge fan of the stuff I just listed. Especially bootstrap. But I also wanna say they are in fact pretty cool and I understand why people like them.
I don't like bootstrap... Just 'cause...
If I'm developing stuff on the front-end I actually really enjoy the CSS part of it. And CSS natively supports grid layouts now. Plus flex-box is the shiznit. (Are kids still saying that kinda stuff now days?) If you don't like spending time on CSS and layouts etc. Or have a huge workload constantly demanding 100% time efficiency. Or just need to produce tons of prototypes during a sprint. Or whatever. Then by all means bootstrap up and bang it out. But if you're good at CSS are you really saving that much time?

Good ole' Sass. It fixes all your CSS woes! Well, actually it just compiles (yeah, technically transpiles) into pure straight CSS and I'm not sure it actually fixes anything at all.
But you can nest your CSS!
Well whoopty doo...

// Sass
$blurple: #7b2be2;

.someClass {
    background: green;
    .innerClass {
        border: 12px solid blurple;
    }
}

What? Blurple should be a color, just sayin'.
Also, compare that to the CSS below

/* standard CSS */
.someClass {
    background: green;
}
.innerClass {
    border: 12px solid #7b2be2;
}

Now lets compare these two examples

// Sass
$blurple: #7b2be2;

.someClass {
    background: green;
    div {
        border: 12px solid blurple;
    }
}

Uh-oh. Without a specific selector to reference looks like Sass works better!
But not really though...

/* standard CSS */
.someClass {
    background: green;
}
.someClass div {
    border: 12px solid #7b2be2;
}

That's because Sass transpiles to CSS. So there isn't anything Sass does that CSS can't other than use variables and allow you to @import 'anotherSassFile'. (Well, those things are kinda cool actually...) But you can also simply use multiple CSS files to help break up and organize your code into smaller chunks. The one thing CSS really can't do, is make up for variable values. But honestly I haven't found the whole variable thing to be that amazing or time saving.
To me Sass is a lot like that band Creed. (Are they still around? Do youngsters recognize that name?) I like hearing their stuff on the radio, but I would never buy one of their albums. Sass is pretty fun to use. But I would never buy the album.

(Post Script Edit. That wasn't true. https://caniuse.com/#search=css%20variables , this was up for a while, somebody should have called me out... Just sayin')

TypeScript
Similar to Sass. I actually work with typescript every day. On a huge angular app for a massive company with maybe 200+ devs around the world total. It is literally the exact scenario that advocates of typescript say it is perfect for. And so far I have not witnessed static types prevent any problems caused by poor coding practices that slip through the cracks. Is it possible that it has prevented problems and I just haven't seen it? Sure. But in real world application I just haven't found it to be any kind of actual improvement over vanilla JS. Ultimately, typescript just seems to be for all the developers out there that are very familiar with <insert name of a generic statically typed object-oriented language here> and don't like JS simply because it behaves differently than what they are comfortable with. Honestly, if typescript were a stand-alone language specifically for back-end and middleware I'd like it a lot more. But the simple fact that it is just a superset of JS makes me feel like I don't understand why it exists. Maybe if I hated JS and wanted it to not be JS I'd like typescript more...

INFLAMMATORY TOPIC # 3
THOSE DAMNED VENDOR PREFIXES!
This one goes back to my love of language specifications. Luckily the prefix craziness isn't as bad anymore. And even more luckily I got into dev work recently enough that the big browsers where already working towards fixing the non-sense vendor prefix problem.

Do you wanna type

div {
    display: flex;
    align-items: center;
}

Or would you rather type

div {
    display: -webkit-box; 
    display: -moz-box;
    display: -ms-flexbox;
    display: -webkit-flex; 
    display: flex;
    -webkit-box-align: center;
    -moz-box-align: center;
    -ms-flex-align: center;
    -webkit-align-items: center;
    align-items: center;
}

Yeah I know, its a tough call. But don't worry, you can use a Sass mixin for that! (sigh...) There are also auto-prefixers you can use to insert all that extra goodness. But that isn't the issue with vendor prefixes. The issue is that something good grew out of control to the point people started making extra tools just to handle them. The language specification allowed for the use of vendor prefixes so browsers could use all the newest proposed things before there was any kind of standard. This allows browsers to not only implement new concepts that they propose but also be a live testing grounds for experimental stuff as well. It was a great idea that also wound up being a bit of a bad idea. IMO, the problem with vendor prefixes is that it hearkens back to a darker time. The very nature of having browser specific tags goes against the ethos of honoring the specification of a language over the needs of the tools using the language. If browser makers get to choose everything they want to do and demand custom CSS values, you very quickly run into a fractured environment where you essentially write css over and over again for each different browser. And it gets worse and worse as browser makers try to out do each other by having more and better features that only their browser does.

And that is basically what vendor prefixes turned into... Except this time around all the different browsers were a lot more friendly with each other and acknowledged the problem while working towards a solution. Cool beans! The nature of the prefix topic though is multi-faceted. On one hand, you have developers that want to honor the idea that there is a standard code specification and we should follow that and not really allow for much (if any) deviation. On the other hand, you have developers that totally want to have access to what the latest generation of browser rendering engine is capable of, even if what it is capable of exists outside of what the specifications state. Which of course leads to the third hand, (that's right three hands,) browser makers need to continue moving forward and progressively changing the very landscape of how we perceive and interact with the web. And browsers are responsible for the growth and development of CSS standards in the first place!

THE FINAL AND PERSONAL FAVORITE INFLAMMATORY TOPIC
JQuery IS DEAD! (Long live JQuery.)
Bwahahahaha. I love making this statement and waiting to watch people squirm and freak out. JQuery is fading people. And for good reason. You don't need it any more.
As quoted on official JQuery website, "it is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development". Cool beans!

BUT.....
Document traversing isn't an issue anymore. Event handling is simpler now. Animating is CSS-ier now. Ajax calls are simple fetch requests now. All the things JQuery fixed aren't the same anymore. There was a time, when these problems were very real. And JQuery truly saved the day. JQuery ruled the inter-web with a kind benevolent hand showing grace and kindness to devs. But times change.

We probably will still be writing JQuery for the next 10+ years for legacy purposes. But there isn't a valid reason now days to use JQuery on a new project. At this point, any time spent learning and using JQuery is better spent learning and using javascript. JS was there before the libraries and frameworks and will be there after the libraries and frameworks. Eventually JS may be replaced, but that is much further down the road and a firm foundational understanding of JS helps you jump from the newest greatest front-end library to the next. It doesn't matter how good you got at using JQuery. If you can't do all the same stuff without it at relatively the same speed, you are simply holding yourself back.

We should all just chill
So, while I did just shamelessly use this post as an opportunity to voice my opinions on a lot of stuff. The primary purpose of all this was to demonstrate examples of common inflammatory topics. Show some of the reasoning (, in this case mine) that is often behind a person's decision on which side of the fence they stand on. And then finally to say that most arguments AGAINST any of my opinions are probably perfectly valid and reasonable as well. If somebody wants to use semicolons in their JS. They are in fact ALSO honoring the specifications of the language and have good reasons for choosing to do so. If somebody absolutely loves Sass or bootstrap. Well, they are in fact right. If I'm starting a new project with a team, you can bet your last dollar that I'll voice reasons for doing things the way I prefer. But I won't get bent out of shape if nobody wants to do it my way. AND I'll even go as far as to enjoy working with everybody and doing the project their way. One of the most important things somebody can do in this life, is learn to recognize that just because your opinion or perspective is valid and reasonable, it DOES NOT automatically mean that the opposite opinion or perspective is not. Often times, trading the "either or" mentality for the "both and", will lead to a larger, richer and more beneficial perspective for both yourself and others.

One person believes he may eat anything, while the weak person eats only vegetables. Let not the one who eats despise the one who abstains, and let not the one who abstains pass judgment on the one who eats, for God has welcomed him. Who are you to pass judgment on the servant of another? It is before his own master that he stands or falls. And he will be upheld, for the Lord is able to make him stand. One person esteems one day as better than another, while another esteems all days alike. Each one should be fully convinced in his own mind. The one who observes the day, observes it in honor of the Lord. The one who eats, eats in honor of the Lord, since she gives thanks to God, while the one who abstains, abstains in honor of the Lord and gives thanks to God.
Romans 14:2-6