It's classic: after introducing the concepts of transactions, isolation levels, XA-protocols, pessimistic/optimistic locking, eager/lazy loading and messaging, I hear often the following comment from Java / OO-programmers: Java EE is too complex, why not RoR or Servlet-Only?
The funny story here: transactions, XA (1980-90), messaging (started before RPC) etc. have nothing to do with Java EE, are even older than Java SE and come from the "big iron" legacy world. Once I had a non-Java-programmer (CICS/IMS developer) from a bank who was rather bored by my explanation. His comment was: "What you are explaining here is really nothing new. We used exaclty the same concepts in the 70's". Java developers were totally amazed by his comment (every single topic was new for them). After explanation of EJBs and connectors he said: o.k. I have to learn the syntax and the strange interfaces (it was the J2EE 1.3 time), but it seems to be easy comparing it to CORBA or other communication protocols and distributed components.
It is also my opinion: we have the same constraints for all distributed technologies. So you have to learn the complex (which are complex) principles. After learning it, you have to learn the syntax and philosophy of .NET, Java EE or CORBA. But comparing it to the principles, the technologies are relatively simple to learn. New hypes cause constant movement to new technologies. But: it is not possible to solve the "old days problems" without understanding the principles.
Conclusion (sad but true):
- New technologies cannot be really simple, or solve the problem. You have still to decide about your concurrency (or isolation of transactions), locking, caching etc. Ignoring the problem only works in really simple applications, which are irrelevant.
- Old school programmers (often non Java-programmers), have a significant advantage over "AJAX" programmers....