In year 2000 I started writing code professionally while at uni, before that I was writing code as a hobby. I was fascinated by all the best practices I should follow: I shouldn’t use HTML tables for design; they are horrible, I shouldn’t write JavaScript inside my HTML I should do it obtrusively, I should not do database business logic in my code, I would violate the separation layers and I will mix business logic with database logic etc… Fast forward two decades later, I learned to take everything I hear with a pinch of salt!
The Do it, Don’t, Do it, Don’t Approach
They tell you do it; it is good; they tell you not; it isn’t then they change their mind a few years later, then again and again.
Writing server-side code in your HTML
When I was a hobbyist, I liked ASP and how you can write some code that is then transformed magically into HTML. You write a bit of HTML tangled with a bit of code and life was cool.
ASP.NET Webforms came along and the major advice, DO NOT write code in your HTML, write it in the code-behind otherwise you would be violating the separation of concerns!
ASP.NET MVC came with Razor pages and the advice was “write a bit of C# code,” it is ok, sorry for the previous advice, but don’t overdo it and be a good boy.
Single Page Applications (SPA), DO NOT write any code in your HTML, better not even dealing with that, let the client deal with it, what were you thinking?!
Mixing database queries with business logic
Writing database logic inside your code would violate the separation of concerns. One of the reason of failures of applications such as MS FoxPro and MS Access was this. Writing stored procedures for your business logic are even worse (please don’t shoot the messenger) because you are scattering your business logic on multiple layers (and million other reasons).
Later on, the Object Relational Frameworks (ORMs) such as Hibernate (Java), Active Record (Ruby on Rails) and Entity Framework (.NET) came along! Now writing database logic inside your code is fine again! But you don’t call it “database operations” anymore, otherwise you become uncool.
Designing with tables
Prior to 2003, if you were to write a web page, you probably would use HTML tables to control your layout. Then the CSS started becoming more supported and the advice changed; DO NOT use tables for layout and you could find blogs of over 10 reasons of why you shouldn’t do it.
Bootstrap and later on CSS Flexbox came along, you know what, they have Grid, not Table, Grids are fine, even though the used CSS classes are called row and col and now grids are fine!
Unobtrusive
When Netscape introduced JavaScript, developers used to write JavaScript events mixed with HTML, the button will have an onclick and then the JavaScript code. Then jQuery came along with the unobtrusive concept (I like this keyword and I learned to pronounce it quickly without stuttering) and now dare you say to a front-end developer to write JS code inside HTML.
Years went by, jQuery became uncool and now the Single Page Application frameworks (React, Angular, Vue, etc…) came to the rescue. And guess what, you are better using JavaScript or framework-specific keywords inside HTML and now it is ok, think (click)="onClickMe()" in Angular, we were kidding when we’ve said obtrusive JS is bad!
You should not be using Flash or Silverlight, or else!
Flash and Silverlight suddenly became bad practice, as they require a plugin to work in the browser and the advice became not to use them because you should be using HTML5. Ok, I got it, plugins are bad, I would not encourage using them. Years later Web Assembly came along.
Did you know, you are allowed to write code that executes as a web assembly, all the stuff we said about plugins are no longer relevant. Writing non-JS code in the browser is fine again, such a wonderful world :)
Conclusion
The irony is that I agree with the logic change and why things went in the other direction, it all make sense to me. Today, what I’ve learned is to always have an open mind for change where it makes sense and to have more flexible opinion in my technical discussions, as every thing will change later on.