Java – Why is spring so good for Java middleware development

What does the Spring framework do? Should I use it? Why or why not?

Spring is a framework that helps you to "wire" different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments.

This is what I've always understood "dependency injection" to be.

I would suggest a different definition:

"Design your objects so that they rely on an outside force to supply them with what they need, with the expectation that these dependencies are always injected before anybody asks them to start doing their usual jobs."

Compare that against: "Each object is responsible for going out and finding everything and everybody it needs as it starts up."

it looks like it necessitates a whole bunch of XML configuration

Well, most of the XML (or annotation-based) stuff is telling Spring stuff like:

• When someone asks for "HammerStore", I want you to create an instance of example.HammerStore and return it. Cache the instance for next time, since there only needs to be one store.
• When someone asks for "SomeHammer", I want you to ask yourself for a "HammerStore", and return the result of the store's makeHammer() method. Do not cache this result.
• When someone asks for "SomeWrench", I want you to create an instance of example.WrenchImpl, Use the configuration setting gaugeAmount and put it into the instance's setWrenchSize() property. Do not cache the result.
• When someone asks for "LocalPlumber", I want to you create an instance of example.PlumberImpl. Put the string "Pedro" into its setName() method, put a "SomeHammer" into its setHammer() method, and put a "SomeWrench" into its setWrench() method. Return the result, and cache the result for later since we only need one plumber.

In this way, Spring lets your connect components, label them, control their lifecycles/caching, and alter behavior based on configuration.

To facilitate [testing] I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method.

That sounds like a lot of overhead for not a lot of benefit for me. Instead, make your instance variables have protected or package visibility, and locate the unit tests inside the same com.mycompany.whatever package. That way you can inspect and change the instance variables whenever you want during testing.

The JSTL syntax required to make highly-interactive pages via JSP's is getting awfully unwieldy. I'm worried that, when we expand our project and bring on more engineers, there will be a steep-ish initial learning curve, followed by a persistent slow-down in the dev process due to verbosity of JSTL.

That is a legitimate concern.

Using JSP's also seems like a less contemporary approach to front-end dev, in light of how many JS frameworks are popular. I'm imagining it'd be tougher to field a team of front-end or full-stack engineers if we build with JSP's.

If you choose technologies that are suitable for your particular task in areas like ease of use, maintainability, sensible management of complexity, flexibility, and appropriateness for your application's specific functional and non-functional requirements, you will find people who know how to develop and maintain software using them.

Server-side rendering has been great for my testing, so far -- but what happens when our app is a massive, historic, global success and downright phenomenon?

If, and when, that happens, it will be a good problem, because then you'll have the money to fix it. Every large company has had to do this; they built their product on a platform that got them to market quickly, and re-built it (in some cases, from the ground-up) when the number of users became enormous.

That said, I think you can make some sensible choices early on. Unless your system requirements demand large, overblown architectures (they don't), avoiding them and choosing more nimble and flexible technologies will generally give you better overall performance and better adaptability.

Pushing view rendering duties onto client browsers seems like a cost-effective strategy for a cloud-hosted app such as ours. Am I mistaken in that thinking?

No. However, have a look at this Basecamp article.

Our app will be marketed to clients who are unfamiliar with technology. I think it's reasonable to assume that such clients will be disproportionately likely to have out-of-date browsers. Old browsers may have compatibility issues with JavaScript rendering -- and ever worse issues with the most modern JS frameworks.

There's just no excuse for this anymore. If your clients want to use computers in the 21st century, they need a modern browser, and it's easier than it's ever been to get one and allow it to maintain and update itself automatically and indefinitely.

After doing some research on these issues, I've got four strategies in mind...

The way of the future is so-called microservices and client-side UI such as Angular. And no, I don't think this just a fad. Users demand high interactivity with their software applications, and this arrangement can give it to them. Your back-end JSON web services can be built with anything you like; Node.JS, ASP.NET Web API, whatever. Maintaining this sort of modularity will make it possible to change out one component without affecting the others.