Tactical Tech Decisions
A lot of frameworks begin with a hook: make an app in 5 minutes with a text editor, attach to a database, make a REST endpoint, talk to Facebook. It's the free bowl of soup offered in exchange for listening with an open mind to a passionate group. A lot of work goes into making these as smooth as possible, and as a pattern the software development world has learned from this to create command line interfaces with lasting usefulness.
The real test of frameworks comes after this stage. How does it match your ongoing requirements and future use cases. If you need to read 700 pages of a book to know how it all works, that might be alright, if enough people have found it worthwhile to read those 700 pages and the materials are available in the workplace. In other cases there isn’t a book, and you realize that's only because nobody wrote a book, and you find yourself cordially invited to read source code to know how it all works.
Popularity of a framework gets around some of this, because you can turn to the community. You quickly find the nuances of community solutions, from the positive extreme where people hurry to explain the logical reasons why an answer will work, to the other end where an online cargo cult is trying to guess why their code works for them, and wondering if anyone will hear from the original framework author again.
Realizing this difference between the "Hello World" that your first tutorial represents, and the resulting development lifestyle represented by adopting a framework as your technical solution, is critical. It's hard not to be swayed by peer pressure of what the current trends are, and as that relates to ongoing support, security updates, community understanding, and availability of expertise. It's also dangerous to be oblivious to it.
The many perspectives that developers have in relation to technologies are shaped by their own professional situations as well as the unique projects they work on. New developers are encouraged by what is current, makes logical sense, and doesn't come with a lifetime's worth of information to catch up on. With experience and an eye to career development, developers follow trends but also start to learn from good and bad experiences in the field from real projects. At this point they will be getting more detailed and opinionated stances on trends in the industry, some well informed and some inevitably skewed by the more anecdotal exposure they encounter through their work experiences.
At the point in careers when people become the ones to strongly influence technical direction, their stronger exposure may be technology which is losing the attention of the wider world. Technical leaders who spend decreasing amounts of their time (if any) in active hands-on development of code rely more upon community opinion or second-hand input related to ongoing trends. Even when strong past experience makes some directions seem a good or bad choice, the intervening changes in the industry force people to be skeptical of relying on those experiences.
A habit I’ve found increasingly useful is to differentiate using technology from a tactical focus. To choose direction from a personal preference or based on the resonances of specific past experiences can be the wrong starting point. By looking instead through the lens of what resulting tactical situations increase or decrease a company's readiness to accomplish specific goals, it helps to validate what is important in the technical domain. It also makes sure you are tackling the current challenge and not still fighting a technical battle from the past.
A looser structured language underpinning a large enterprise project could be injurious to the management and thus extensibility of the code. Applying rigorous patterns of design and scalability every time an admin interface or portal is needed could cripple the ability of a company to show customer empathy in its development. Much as a barbecue fork and a dinner fork could be forced to work in the same roles, different technical solutions will sometimes provide a vastly different level of ease for achieving the business' goals. When those aims are peripheral to the immediate feature set being worked on, the difference between uphill and downhill translates into a real difference in the strategic readiness of the business.
Asking a practitioner if a solution should use Java or Node can feel like asking someone their favorite music performer. For some situations, that's exactly the freedom of expression that's open to developers without negatively impacting the work, and is a real pleasure of our field. At other times it's a serious error that will cause pain and ineffectiveness later on, and negatively affect the business and its customers.