(enlarge)
In the year 2000, I started writing code professionally while at university; before that I wrote 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 unobtrusively; I shouldn’t put database business logic in my code, because I would violate the separation of layers and mix business logic with database logic; and so on. Fast forward two decades, and I have learned to take everything I hear with a pinch of salt.
The Do It, Don’t, Do It, Don’t Approach
They tell you to do it; it is good. Then they tell you not to; it isn’t. Then they change their mind a few years later, and 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 wrote a bit of HTML tangled with a bit of code, and life was cool.
ASP.NET Webforms came along and the major advice was, 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 about the previous advice, but don’t overdo it and be a good boy.”
Single Page Applications (SPAs): DO NOT write any code in your HTML. Better not to deal with it at all, 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. This was one of the reasons applications such as MS FoxPro and MS Access failed. Writing stored procedures for your business logic is even worse (please don’t shoot the messenger) because you are scattering your business logic on multiple layers (and a million other reasons).
Later on, object-relational mappers (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, or 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 CSS became better supported and the advice changed: DO NOT use tables for layout. You could find blogs listing over ten reasons why you shouldn’t do it.
Then Bootstrap, and later CSS Flexbox, came along. You know what? They have Grid, not Table, and grids are fine — even though the CSS classes are called row and col.
Unobtrusive
When Netscape introduced JavaScript, developers used to write JavaScript events mixed into HTML: the button would 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 don’t you dare tell 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 and so on) have come to the rescue. And guess what? You are better off using JavaScript or framework-specific keywords inside HTML, and now it is OK. Think (click)="onClickMe()" in Angular, we were kidding when we 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, and I would not encourage using them. Years later Web Assembly (new tab) came along.
Did you know you are allowed to write code that executes as WebAssembly? All the stuff we said about plugins is 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 makes sense to me. Today, what I’ve learned is to always have an open mind for change where it makes sense and to have a more flexible opinion in my technical discussions, as everything will change later on.