I'm glad you asked , LOL. I worked as a professional React dev for about 9 months ( part time ) and I've been a professional Angular dev for over a year.

I hate React, and JSX the primary reason. CSS in JS is another ( not required for React, but prominent ). First, however let's talk about JSX.

Separation of concerns was the ENTIRE reason we decided to put controllers, HTML, and CSS into different files. JSX muddies the waters so much that there are some JSX novels that I've seen and worked with that read very much like a horror story.

Heiker's example is a good example of this. What I love about Angular is that your component's html file is, well, an HTML file. Sure, it uses structural directives and some minimal ( very readable ) interpolation, but it's nothing compared to the spaghetti mess the JSX usually becomes.

When it comes to very complex views, nothing is worse than having to mentally map your way through a React component with endless JSX acrobatics that you have to translate into your mind into a coherent web page. For simple views, it's fine. But in some of the more complex views that I've seen, it's just ridiculous.

There's a reason why Angular tends to be the framework of choice with much larger and robust enterprise applications. It scales better, and it's easier to deconstruct and refactor the architecture as things grow and change. To me, React is beautiful , fast , and elegant for smaller and medium sized projects, but once the projects scale, it can become a Frankenstein very quickly. There's no real universally agreed upon pattern for how React should scale. ( Not to my knowledge ) , where Angular's structure is baked into the framework.

I didn't bring up TypeScript because technically you can use TypeScript with React, but TypeScript being in ALL Angular projects is the other major reason that I love it.

I was once a diehard Linux user. I had to stop because I realized I was spending more time tweaking and distro hopping than I was actually working. It also didn't help that I was developing commercial desktop software, for which I couldn't get a market on Linux.

Now that things have shifted to more web-based apps, it's a great option for developers. For me, I still find myself working around little things to improve the desktop experience, things I don't have to mess with on Windows or MacOS. So for me, I'll continue to play with it in the hopes that someday it will meet my needs.

What you call less noise I call more information.

The first SQL Query is using what's known as an implicit join (A.K.A comma join).
The join clause is replaced by a comma, and the join criteria is specified in the where clause.

The second SQL Query is using what's known as an explicit join.
The join criteria has it's own dedicated clause (the ON clause).

BTW, these queries are not the same: The first is an inner join and the second is a left outer join.

Implicit joins requires a little less typing, but that's probably the only benefit over explicit joins.

Explicit joins are a part of the ANSI standard for almost 30 years now, and with good reasons too:

1. Explicit joins provides a clear distinction between join conditions and filter conditions.

2. Inner joins can easily be replaced to an outer (left, right or full) join simply by replacing (or adding) a keyword - implicit outer joins are no longer supported at least on one major rdbms - SQL Server. (they where deprecated in 2008 version, which ended it's extended support in July 2019).

3. Explicit joins are far less error prone - since the join condition is in the on clause, the compiler will not let you run a join query without specifying a join condition.

4. Explicit joins are far more readable and maintainable.

5. With multiple joins in a query, explicit joins provides a very easy way to distinguish which condition belongs to which join.

Design It!

Currently reading this. It gives a lot of insight in the process of software design. It also helps me to formulate better arguments on why I make certain decisions. A lot of the things discussed where things I was already doing to some degree.

Additionally, it also contains a bunch of procedural tools which can be used during design.

Your Code as a Crime Scene

I'm always interested in improving code quality. The premise of this book sounds interesting.

Software Design X-Rays

The follow-up to Your Code as a Crime Scene, so why not.

Unicorn Project

The sequel to the Phoenix Project. I want to read how the story continues.

Coders: The Making of a New Tribe and the Remaking of the World

It sounds interesting, and I wanted to read something which was more reporting about rather than instructing to.

The Pragmatic Programmer, 2nd edition

I read the original. It's a really good book. I mostly want to read this new version to freshen up, and find out about the new things.

Future reading list

The next few books might be added to my reading list in the future.

Refactoring Databases

I assume this is like the Martin Fowler Refactoring but for relational databases. So it is mostly interesting to get to know about various refactoring activities which can be applied to databases.

Smalltalk Best Practice Patterns

DHH mentioned this book to be worth reading, even when not using Smalltalk.