File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Jobs Discussion and the fly likes Another challenger to Java? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "Another challenger to Java?" Watch "Another challenger to Java?" New topic

Another challenger to Java?

M Burke
Ranch Hand

Joined: Jun 25, 2004
Posts: 397
His opinion

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?

Bear Bibeault
Author and ninkuma

Joined: Jan 10, 2002
Posts: 63852

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.

[Asking smart questions] [About Bear] [Books by Bear]
Bear Bibeault
Author and ninkuma

Joined: Jan 10, 2002
Posts: 63852

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.

Are there challengers? Sure. Scala and the Play! framework is one example. Node.js and JavaScript, as mentioned in the linked blog, is another. Even in the face of these challenges, I don't think Java is going to be kicked to the curb anytime soon.

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.
Frank Silbermann
Ranch Hand

Joined: Jun 06, 2002
Posts: 1405
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.

What made the web popular is that is eliminate the problem of deploying clients. Some wanted the best of both worlds by deploying fat clients over the web as applets or via WebStart. That's what this sounds like, except that it's using HTML/CSS/JavaScript instead of Java. It's sort of like using GWT, except that instead of compiling to the machine language (HTML/CSS/JavaScript) you're coding _in_ the machine language provided by the browser.

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.
chris webster

Joined: Mar 01, 2009
Posts: 2289

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"!

No more Blub for me, thank you, Vicar.
Pat Farrell

Joined: Aug 11, 2007
Posts: 4659

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 agree. Here's the link:
subject: Another challenger to Java?
It's not a secret anymore!