I can relate 100%: I've been doing Java for 25 years (and C++ before that) and seen many "come and go" languages and frameworks.
Who could forget Java EJBs? Hot, hot, hot for a while - I took a look and went "yuck" and avoided any contract that even mentioned the word. A few years later having skills in EJBs was like having leprosy :)
In 2008 I went looking for a good Java web framework. I drew up a "short" list of about 30 alternatives (yes I know, you think that there's a lot of JS frameworks these days!).
Tapestry looked really nice but I didn't like that the page/component layout was specified in a markup language that was not pure HTML so I kept looking.
One caught my eye: An MVC framework that moved web UI coding away from request/response and the awkwardness of JSP based UIs like plain JSP and the extra awkward world of 'struts'. And it's markup language was pure, valid HTML. I was like "how do they even do that?"
It was component oriented, event driven (AJAX events, partial page updating all done with ease), and being proper MVC it had separate 'M'odels that provided the data to be displayed in the 'V'iews. Having been an MVC fan from 1990s when using C++ desktop frameworks and the ease of use and high productivity they brought I thought this framework was too good to be true.
I created a few trial apps using it and fell in loooooove as it was the kind of framework I felt I would write myself if I had the time to write my own! I then adopted it as my small company's official UI framework for all web apps.
The MVC framework is called Apache Wicket (wicket.apache.org/) and it has easily been the most productive, easy to use web UI framework I have ever encountered, way more productive that pure JS front end/UI frameworks.
In the interim I've contracted to other companies and saw them inflict us developers with "the savior" Angular 1 (the so called "Angular experts" hardly understood it - I, a lowly Java developer, had to fix bugs created by the so called Angular experts who couldn't work out why various parts of their UIs were not working!) then they tried to upgrade to Angular 2 (what do you mean by "the app needs an almost complete rewrite"?)
We also discovered that the JS library ecosystem is not at all like the solid, stable Java library ecosystem we had been used to. About 3 or 4 times a year our build would break because someone in some country I had never heard of did an incorrectly versioned, breaking release of their library that was a dependency of some other library we used "17 levels of dependencies down the tree". Arrrrrggggghhhh!!!
With each new JS framework the key players danced throughout the office with great enthusiasm and had no problem convincing upper management that this "new shiny thing" was going to solve ALL their productivity, reliability and maintenance problems ... until it didn't ... and then they went looking for the next "new shiny thing". Management start getting weary of that game after a while...
So, here we go, down the React path then the Vue path etc., There has probably been another new JS framework released in the time that it has taken to write this post :)
Anyway ... thousands of developer and tester days wasted and, therefore, literally millions of dollars wasted.
Meanwhile in my own small company our apps powered on using Wicket and Wicket continues to evolve and has a very active community and answers to any questions are quick.
Our apps using Wicket can do everything apps based on the JS based frameworks do and have all the AJAX powered interactivity they do because its components have a Java and a JS side - but, as Java developers, we only need to deal with the logical, typesafe, high productivity Java side with it's stable ecosystem of libraries "to do virtually anything you need". The Wicket devs have gone through all the JS pain so we don't have to! (Thanks guys for taking one for the team!). However it's always possible to enhance or create a new Wicket component with extra JS if needed. With so many existing components available I've rarely needed to do that.
My learnings from all this: "Well established, well engineered, high quality, high productivity frameworks can outlive that new shiny thing you're tempted by and you won't need to rewrite your UI layer every 2 years!" ;)
I am a Software Engineer from Costa Rica living in Berlin, with experience working in both, a fast-paced startup environment, and a global S&P 500 company.
I can relate 100%: I've been doing Java for 25 years (and C++ before that) and seen many "come and go" languages and frameworks.
Who could forget Java EJBs? Hot, hot, hot for a while - I took a look and went "yuck" and avoided any contract that even mentioned the word. A few years later having skills in EJBs was like having leprosy :)
In 2008 I went looking for a good Java web framework. I drew up a "short" list of about 30 alternatives (yes I know, you think that there's a lot of JS frameworks these days!).
Tapestry looked really nice but I didn't like that the page/component layout was specified in a markup language that was not pure HTML so I kept looking.
One caught my eye: An MVC framework that moved web UI coding away from request/response and the awkwardness of JSP based UIs like plain JSP and the extra awkward world of 'struts'. And it's markup language was pure, valid HTML. I was like "how do they even do that?"
It was component oriented, event driven (AJAX events, partial page updating all done with ease), and being proper MVC it had separate 'M'odels that provided the data to be displayed in the 'V'iews. Having been an MVC fan from 1990s when using C++ desktop frameworks and the ease of use and high productivity they brought I thought this framework was too good to be true.
I created a few trial apps using it and fell in loooooove as it was the kind of framework I felt I would write myself if I had the time to write my own! I then adopted it as my small company's official UI framework for all web apps.
The MVC framework is called Apache Wicket (wicket.apache.org/) and it has easily been the most productive, easy to use web UI framework I have ever encountered, way more productive that pure JS front end/UI frameworks.
In the interim I've contracted to other companies and saw them inflict us developers with "the savior" Angular 1 (the so called "Angular experts" hardly understood it - I, a lowly Java developer, had to fix bugs created by the so called Angular experts who couldn't work out why various parts of their UIs were not working!) then they tried to upgrade to Angular 2 (what do you mean by "the app needs an almost complete rewrite"?)
We also discovered that the JS library ecosystem is not at all like the solid, stable Java library ecosystem we had been used to. About 3 or 4 times a year our build would break because someone in some country I had never heard of did an incorrectly versioned, breaking release of their library that was a dependency of some other library we used "17 levels of dependencies down the tree". Arrrrrggggghhhh!!!
With each new JS framework the key players danced throughout the office with great enthusiasm and had no problem convincing upper management that this "new shiny thing" was going to solve ALL their productivity, reliability and maintenance problems ... until it didn't ... and then they went looking for the next "new shiny thing". Management start getting weary of that game after a while...
So, here we go, down the React path then the Vue path etc., There has probably been another new JS framework released in the time that it has taken to write this post :)
Anyway ... thousands of developer and tester days wasted and, therefore, literally millions of dollars wasted.
Meanwhile in my own small company our apps powered on using Wicket and Wicket continues to evolve and has a very active community and answers to any questions are quick.
Our apps using Wicket can do everything apps based on the JS based frameworks do and have all the AJAX powered interactivity they do because its components have a Java and a JS side - but, as Java developers, we only need to deal with the logical, typesafe, high productivity Java side with it's stable ecosystem of libraries "to do virtually anything you need". The Wicket devs have gone through all the JS pain so we don't have to! (Thanks guys for taking one for the team!). However it's always possible to enhance or create a new Wicket component with extra JS if needed. With so many existing components available I've rarely needed to do that.
My learnings from all this: "Well established, well engineered, high quality, high productivity frameworks can outlive that new shiny thing you're tempted by and you won't need to rewrite your UI layer every 2 years!" ;)
Thanks for sharing this! I find it incredible how you have been working consistently with the same tools for years and still love them!
They say "A bad worker always blames their tools".
That could be one possible explanation for the insatiable thirst for "new shiny tools" in the software world ;)
"When you're on a good thing - stick to it!"
It helps when the Apache Wicket devs are proper software engineers and each feature is properly thought out and each release is rock solid.
If I hadn't chosen Wicket in 2008 I would have probably had to rewrite my UI 3 or 4 times by now.