On Thu, Jan 14, 2021 at 7:27 AM HRH <hrh...@yahoo.com.invalid> wrote:
> > However, an observation that caught my attention on StackOverflow is that > the highest percentage of the activities (post and replies) on the > technologies I mentioned earlier took place between 2009 to 2015, followed > by a drastic drop onward, so I am not sure how to construe this sharp drop. > Does this mean, the majority of the Java EE developers now have a matured > skillset and they do not need to ask those “how-to” questions anymore, not > many web-applications being developed across the board, Java developers are > shifting to other development areas like AI, standalone apps on small > devices, etc.—or they are gradually migrated/migrating to other non-Java > platforms (i.e. Python)? > The big move has been to Javascript top to bottom, using Single page apps in the browser and Javascript (ala Node) on the back end. I am not keen in that world. JS has been reinventing the wheel much like Java did in the 90's and 2000's. "Make the world JavaScript". I can't disagree too much with that call. Early on, when I originally chose Java for a project it was because of JSP and Servlets. Specifically, JSPs WERE Servlets, just in a different form. This universality was important as they could all be treated the same. Having a Java stack from top to bottom I felt was important to leverage the network effect of the staff. What I did not want was someone with a XXX problem unable to talk to someone else because they only knew YYY. This was my concern at the time with the Microsoft stack of mixing ASP and C++ and VB (pre .Net). I wanted the team to have the same footing. In fact, I was quite vocal, years later, when someone decided they "just had to" use Clojure for a component of the system. Now, I'm a Lisp guy, I like Lisp, I can see the charms of Clojure. But if we kept that, we would have had 20 Java folks, and 1 Clojure guy. Inevitably, the Clojure guy left, and we had 20 Java folks and no Clojure folks. And, naturally, we later had some issues with the Clojure code that took far too long to resolve because we didn't have the expertise in house. Whatever potential advantages that brought in development (which I assert were minimal, since I rewrote the Clojure code in Java, which I was told wasn "impossible" to "prove" that it could be done, and, no it was not as elegant as the Clojure was, but totally serviceable), were lost when we had to fight that issue later. So, I can understand the desire for consistency across the team and code sharing and reuse across the platform.
