He thinks the front end will start servicing itself and back end developers will disappear. He cites database services and HTML generation, but there is much more a server does; web services, legacy system intergration, report generation, file services, emailing, logging, data transformation and so on. So I think he is getting ahead of himself. What is your opinion?
I think the title is misleading. This really has nothing to do with any challenge to Java per se, but to back-end developers who may or may not work in Java.
But to the point that's actually being made, may answer is pretty much yes (although I disagree with much in the blog post when it comes to the nitty details).
I've said it elsewhere, and I'll say it again here. Anyone who is a back-end web applications developer (Java or otherwise) who only knows back-end development (Java or otherwise) is already seriously behind the eight ball*.
Things could change -- as they do rapidly in this field -- but it increasingly looks as if web applications are heading to the use of client-side MVC frameworks such as Ember, BackBone, or (what looks to be the up-and-coming front-runner) AngularJS, and getting data from JSON REST backends.
JEE for web applications is already a dinosaur and will soon be tomorrow's oil fields.
As you point out -- there's more going on on the servers than just web application back-ends, but for those working on web apps, it's high time to break out the books on client-side technologies, or risk becoming part of the tar pits.
* For those whom the idiom "behind the eight ball" is unfamiliar, it means to be in a weak or losing position.
More of my thoughts on the role of Java in all this:
Again, I think the title of this topic is off base. All this is little challenge to Java as a server-side language. What changes, is the role that Java plays in web applications and on the server. Even if the role of the server backend becomes relegated to merely providing a REST API, Java is still a strong choice for the development of such back ends.
What's quite likely, in my opinion, is that the days are numbered on lumbering behemoths like JSF, and other heavyweight technologies that straddle the HTTP divide. It's possible that even JSP will eventually be shouldered aside as templating moves to the client. Essentially I see the V and C of MVC moving to the client, and the role of the server being to supply the M (in the form of previously mentioned REST APIs serving JSON).
So, in my opinion, Java as a server-side language is not really in much danger. It's just that its overall role in a web application is likely about to get much much smaller.
And that is why I think that it is web developers who are just "Java jockeys" that are in trouble, as opposed to Java the language.
Having the logic on the client instead of the server sounds like 3-tier client-server. The corporate world was moving towards that, until the web became popular.
Of course, you're still going to have substantial logic on the server -- otherwise it will be like web-deployed TWO-tier client-server! Two-tiered client-server went out with Visual Basic 6.
I think his perspective is a little shallow. He seems to be talking mainly about relatively simple MVC applications where the server probably isn't doing a great deal (although if you're using Java EE it will still seem like a lot of work because of all that lovely JEE complexity), and he also seems to be ignorant of any technologies before Java.
But anybody who worked on pre-Java client-server systems probably switched regularly across the divide between "front end" and "back end" development e.g. I worked on Oracle Forms (a proprietary client-server GUI development tool for Oracle DB applications) for over 15 years, during which time I was responsible for doing everything from tweaking the screen layouts (admittedly, they always looked like crap) to writing the SQL to create the DB objects. Like a lot of client-server technologies, this didn't work so well when the web came along, and Oracle Forms never really succeeded in the browser-based world, although there are still tons of legacy systems around. And I still see job ads for things like VB, Visual C++ etc, so it's not just an Oracle thing.
Incidentally, the introduction of an increasingly bloated middle-tier, and the often rigid and arbitrary division of development teams into client, Java and DB developers has crippled a number of projects I've worked on in recent years. Anything that breaks down these barriers has to be a good thing.
So if we are shifting back towards a fat-client world (in the browser), then it's not really that big a deal. There's still going to be stuff that has to live on the server (good luck downloading your corporate data warehouse onto your iPad...), so there'll still be plenty for Java (or more precisely the JVM) to do. Meanwhile the client technologies have changed, but the basic concept of a fat client is no different from what it was 20 years ago. No news here.
But Bear's obviously right that
"for those working on web apps, it's high time to break out the books on client-side technologies"!
Java as the server language has a lot of baggage, its showing its age. It is possible to create well engineered, scalable, high performance servers in Java, but it takes a lot of work and requires lashing up a lot of components are disjoint.
Take JSP and EL. The syntax is absurd. How do you change a simple <c:if> block into a <c:if> <c:else>? You change the whole thing to <c:chose>. Bletch. What a hack.
Java has a fundamental problem that it is a procedural, sequential language that has mutex options added on. Writing solid Java code for multi-core CPUs is far harder than it should be. Fifteen years ago, this was not a critical flaw, as most CPUs were single core. Today, everything is multi-core. Normal laptops have quad-core, servers often have 8 or 16 cores. Even smartphones are shipping today with quad core CPUs.
So far, I haven't see a real challenger to Java. But I sure expect one.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com