Slashdot Mirror
Java Vs. Node.js: Epic Battle For Dev Mindshare
snydeq writes While it may have been unthinkable 20 years ago, Java and JavaScript are now locked in a battle of sorts for control of the programming world. InfoWorld's Peter Wayner examines where the old-school compiler-driven world of Java hold its ground and where the speed and flexibility of Node.js gives JavaScript on the server the nod. "In the history of computing, 1995 was a crazy time. First Java appeared, then close on its heels came JavaScript. The names made them seem like conjoined twins newly detached, but they couldn't be more different. One of them compiled and statically typed; the other interpreted and dynamically typed. That's only the beginning of the technical differences between these two wildly distinct languages that have since shifted onto a collision course of sorts, thanks to Node.js."
Java = back end
JavaScript = front end
Need both to do useful things, no?
Hipster Crap vs Crap. Fight!
That's all I can think.
Are probably better than javascript/node.js (MEAN stack?), and, imho, just as easy to implement, if not easier. I think the "battle" is java enterprise usefullness versus whipped up but very nice javascript/node.js. Those that make nice websites prefer to do so in javascript/node.js but I don't know why how any enterprise problems can be properly solved with that technology.
>speed
>JavaScript
These two do not belong in the same sentence. JavaScript makes your 8-core i7 run like a 486.
.
Computer media are usually pretty dull, so there's nothing like a supposed battle to up the interest.
Node.js and Java couldn't be much more different in the types of programmers/clients that each attracts. A typical Java client would be a somewhat stodgy to extremely stodgy company where the programmers are completely wild and out of control because they don't wear ties with their dressshirts. These same programmers either work in large pools of programmers for the company or are doing contract work for a large stodgy consulting company.
A Node.js programmer might not own a dress shirt and works for a company that mightn't have ever printed an org-chart. The only stodgy companies using node.js would be where they completely outsourced their web infrastructure to a young hungry up and coming development company that has another decade or two before it becomes fully decrepit and stodgy.
There is no competition for mindshare between these two. Maybe, just maybe, there are a tiny few companies right in the middle of these two extremes that would go one way or the other but in all probablity these middle companies are using PHP, Ruby, or Something Microsoft.
But the reality is that Java is competing with Microsoft's C# and maybe other JVM languages such as Scala. Whereas Node.js is competing with PHP, Ruby, Python.
All I could say to product/project manager at a fortune 500 company who wanted to switch their system from Java to Node.js is "Good Luck." And the same with someone who proposed Java at a young startup that had a successful Node.js codebase. In the later I could maybe see a switch to Python but the first would and will potentially not be switching from Java for the next decade or three.
1) Languages aren't compiled or interpreted: implementations are. Java has had a decent optimizing compiler for a long time, but JVM 1.0 wasn't exactly a speed daemon. JavaScript was a dog for a long time, but modern engines like V8 compile it to native machine code.
2) Node.js isn't fast. It's concurrent. You can handle many thousands of simultaneous requests, as long as none of them are working particularly hard.
3) Exactly what collision course are we talking about? I can't imagine many situations I'd consider Node.js for that I ever would have though about Java for in the first place. If anything, I see Node.js as more of a competitor to Python for building scalable backend services.
Dewey, what part of this looks like authorities should be involved?
https://iojs.org/ IO.js is the current fork of node.js, but controversial as it may be to say this java has been a trainwreck for a decade or more. Running a full size java weblet, bean, or whatever the hell its called requires tomcat, which requires mod_jk if you want it to scale past a webserver written in, well, Java. this stateless proxying between a java process, tomcat, apache/nginx, and the load balancer/user is a hellish nightmare to debug. tomcat caches DNS entries which means the whole service has to restart to avoid insanity during renumbering, and if its tied into mod_jk tomcat generally will not gracefully stop or restart. jk workers, true, can be pointed to a load balancer but load balanced tomcat? now youre writing lockers and working out 4j unified logging either in catalina or perhaps as a syslog service. And what about connectors? if underlying database calls for some reason in connectionfactory cant be made, connectors will not start and a cryptic glob of errors is excreted into catalina for review by qualified madmen.
Good people go to bed earlier.
Node.js - I don't want to pay my programmers
Java - I don't want to pay microsoft
Java = back end
JavaScript = front end
Need both to do useful things, no?
Node.js is an event driven framework for build web/network apps. It doesn't run in the browser, it is the server fulfilling browser requests. It just happens to use the javascript language.
http://nodejs.org/
While it may have been unthinkable 20 years ago, Java and JavaScript are now locked in a battle of sorts for control of the programming world.
Hyperbolic much? Ya, no. It's still unthinkable.
It must have been something you assimilated. . . .
That is a "battle" nobody with real skills cares about. "Dominance" at the low end, at best. But in keeping with the theme of incompetence, Java is actually mostly back-end these days, while JavaScript is decidedly browser-only, so the whole comparison is nonsense.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Node is fast supposedly because it uses low-overhead single-threaded asynchronous calls, instead of threading. So if that is such a fast paradigm, why don't we build a low-overhead single-threaded asynchronous Java or Python or C# engine? Eg: Node.java, Node.cs, and Node.py?
People love to praise the speed of Node.js. The data comes in and the answers come out like lightning. Node.js doesn't mess around with setting up separate threads with all of the locking headaches. There's no overhead to slow down anything. You write simple code and Node.js takes the right step as quickly as possible.
With so much on the Net and 99.999999999999999999999% of it total shit, hyperbole is the ONLY way to get through the noise.
And considering that most "articles" on the Net are written by mentally challenged people, the Internet will be totally written by retards in order to drive advertising for complete crap that is sold on the Internet.
Let's face it, the Internet has jumped the shark, is completely worthless, and is populated by the lowest forms of humanity on Earth.
You and I are the exceptions, of course.
Well, at least I didn't lower myself and actually register for an account - what kind of moron falls for that bullshit.
We know this by all the people who refer to Javascript as Java. You know who you are (#businesspeople).
When the reverse starts happening, I'll change my mind.
Damn, this is both +Funny and +Insightful. Wish I had mod points, and the ability to assign two of them to your post.
-kgj
Neither is needed in a non-Facebook, non Web-2.0, non-sizzle-over-steak Web.
Instead of writing JS both on client and server, the Node.js approach, you can write Java on both - that's how Vaadin Framework approaches web applications, by using GWT Java-to-JavaScript compiler for the client-side part. And usually you don't need to write ANY client code, and all client-server communications are completely invisible. You're just writing a UI in Java and can forget most of the client-side peculiarities.
Vaadin is also pretty flexible and allows mixing the approaches to a great extent, allowing JavaScript client-side widgets and other JS integration. You're also free to use other languages than Java for many client-server tasks, such as for REST services.
Not to mention that you can just as well use Scala and such for the server-side.
>> Java and JavaScript are now locked in a battle of sorts for control of the programming world.
Whatever. Wake me up when you can write a (good) device driver in either then I'll take your claim a little more seriously.
I realise that the internet is a massive source of employment, but believe it or not, its not the only thing out there. There are acutally a few of us software developers left that do not do web stuff (and actually like it that way).
The same meaningless "head-to-head", the same completely mistaken fake contrasts, same shit, same site, different day.
Oh wait, that was "PHP vs. Node.js". Then this is completely different, of course. Carry on.
Javascript, despite it's popularity, is a terrible language. It's popularity is due to one thing, it is embedded in the browser. If you could just pick your own language to embed in the browser, you'd never hear of it. The entire level of popularity from Node.js has come from 3 things:
1. Frontend (read, client side, not "PHP") developers who get the idea in their head that they already know javascript so wouldn't it be great to use it on the server too so they don't have to learn another language
2. Non-blocking I/O, which is admittedly very worthwhile on the server side...however, Java still blows it out of the water for concurrency and Go is currently doing everything that Node does here, but better.
3. AJAX development, making JSON popular, leading to JSON based NoSQL databases like Mongo (which is great at what it does) and then uses Javascript for processing in the database too because of JSON
There's a 4th reason that gets tossed around that I've never seen actually validated with the idea of "reusing code on the backend and the front-end" but I've never seen a case where that was actually a good idea since it involves exposing so much logic.
On the frontend, yes, Javascript everything...because you have no other option. That's like saying black was beating green for mind share with the Model T Ford.
On the backend, you have Java, Go, .NET, Ruby, Python, PHP, Clojure, Groovy, Erlang, Perl, Scala...all of these languages exist with different benefits and different trade offs.
If anything, a huge piece of Go's skyrocketing popularity is people wanting the non-blocking I/O perk of Node for certain use cases without all of the pain that comes from dealing with Javascript.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
Every few years, we have a new latest and greatest. A few years ago it was ruby on rails, then it seemed python was starting to come into it's own, and now it's node.js. At one point in time, in the mid 90's, it was actually Java. If you can imagine, Applets were actually a big deal.
Programmers flock to these in droves because, being new(ish), it attracts proselytizers who overhyper and oversell it, authors to write about it, articles about it, speakers to present it, a race to be seen as an expert in it, etc. New means 'new opportunities' so there's a rush to fill this hole that's already been filled in other languages/frameworks. Lots of activity.
All this attention, and it being new makes it a toy to play with and something to trick the boss into agreeing to use, so you have an excuse to use it. Some small number of folks will end up dealing with it for a bit, but then they drop it when something newer - and thus more interesting and exciting - comes out. Check out the TIOBE index for what's happened to Ruby lately.
But here's the real reason this isn't a battle. Java was not a language, it was a product. Every part of it was made to sell - not to developers, specifically - but to businesses. Here is an end-to-end solution, with certification, a training program, literature, professional advocates that will travel to conferences, your company, programming competitions, and local java users groups - in fact, they'll sponsor them. They'll pay for flashy commercials, and take out ads in trade magazines, and get companies to include the java logo on their software. They'll provide support contracts and expert help, and they'll push Java as a brand.
It's not a toy. It doesn't stick because it's cool and new and neat, it sticks because now there's money behind it and it's cheaper not to change much. That's why we still have Cobol around, isn't it?
So, Java's already been sold to the big dogs, the guys with money who make decisions. It's embedded into the corporate hierarchy, and outside of a few side projects and startups, it's not competing with Node.js at all. Node.js will make it's splash, and in 2 years, we'll all be jazzed about something else, while the cobal, c, c#, java, and other legacy frameworks just keep chugging along with the majority shares.
In a related story, experts agree that a professional mechanic's rollaway tool chest is much heavier than a children's toolbox with a plastic hammer.
Javascript on the server-side is total bollocks. Now that the client has gone smart again, because the browser *is* the client-side env, therefore Javascript has clearly won as *the* client-side language, and this means the server may become lean and mean again, because it can dispense with all the GUI, HTML, etc.. nonsense. And that means it can be done in real programming languages again. The kind where mistakes will cause a crash, not just inefficiency, unreliability and an entire generation of ops that think "just restart" is "normal". Which means that bad developers are filtered out, not saved by a nanny language and environment. Which means there will be less, but far better developers. And good developers can make good code in any language. Whatever I may have said and thought about JS in the past decade or so, I changed my mind since owning Crockford's "Javascript: The Good Parts". ON THE CLIENT SIDE, that is. I have never like anything but C(++), on the server side, and experiencing J2EE Containers, PHP, RubyOnRails, and various python frameworks there has only entrenched me more into thinking there is not one among them that I ended up respecting. If I could do a full e-commerce solution in serverside C++ in 1998, and get excellent performance from the cheap boxen of that time, imagine what you could do today by doing it right, on the server-side, by not wasting CPU cycles on another interpretative layer and letting some dumb algorithm mis-handle your memory management for you.
Seen both flavours of web frameworks. For comprehensibility to on-board new devs to unfamiliar code, I'd go with something like ExpressJS any day. This is from comparisons with Java and PHP web frameworks I've encountered on projects. Suspect that many who pontificate haven't actually used this stuff for real, as the lack of a type system has had F all impact for me when working on real NodeJS projects.
Information wants to be beer.
See the Titan that is Javascript take on the Giant that is Java, making them both seem normal size!
systemd is Roko's Basilisk.
After 20 years in development and more specifically web development, it never ceases to amaze me how retarded this same old argument can get.
My answer to this question has always been whichever technology allows me and those in my company to most efficiently develop and maintain projects leading to the most $$$ in my pocket and most value for my customers.
Religious wars regarding technology are for academics...
This would be a much more interesting battle. Java, Node, [Name your lang here] is just a vehicle
No matter who wins, developers lose.
Those days are dead and gone and the eulogy was delivered by Perl. --Rob Pike
Node.js has some appealing features. The more important is simplicity. Java in the other hands can do things that are impossible in Node.js. From the hardware point of view, Node.js is an old technology. With multicore architecture makes no sense to process everything using one thread. This will be worst because the number of core by CPU will grow with the time. Perhaps in 5 years we will enjoy of 48 or 96 cores by CPU. Node.js' One thread execution model makes not too much sense in that context.
I use Java and Javascript every single day. Are new programmers simply not able to learn more than one language? My work is primarily on a webapp, so its the classical Java backend Javascript frontend. However if our platform was different we would be using different tools.
What the hell they teaching kids in school these days? Back to the "Java is a hammer" days? Or is this the "outsourcing, so only one language for your entire end to end on every system"?
But, my guess that the article is clickbait trolling, and real architects actually know to use the best tool for the job.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Whenever I think about this difference given for java and JavaScript given on SO One is essentially a toy, designed for writing small pieces of code, and traditionally used and abused by inexperienced programmers. The other is a scripting language for web browsers. http://stackoverflow.com/quest...
I could go into a dozen technical reasons why javascript is a terrible, horrible, outrageously bad language here but this post would be TL;DR; for most people. Lets just settle for goggling "javascript terrible" and reading the first couple links.
Or for some silly (not not really deal killing) things watch https://www.destroyallsoftware...
The fact that there are actually people who think using in on the server is a good idea, proves there are insane or completely incompetent developers out there. If someone actually approaches me with this idea, I immediately think they are an idiot.
See, on the browser we basically have to deal with javascript because there aren't any real alternatives. But things that are just "issues" or "irritations" in the browser quickly blossom into product killing problems when used on the server.
Oh, and yes, I've written my fair share of javascript (and other languages), so don't think i'm talking out of my ass here.
Here's something I noticed that bugged me in the article.
It claims that Node.js wins for build process because Java's popular build processors require you to write XML.
Which makes me think they're not aware of what Apache Maven actually is.
Maven is much more than just a build tool. It not only is used to control the build order of a multi-project build, but it also downloads and installs your project's dependencies from the Maven Central repository.
You need a JSON parser in your project? Easy, just add a dependency reference with groupId com.google.code.gson and artifactId gson . Need version 2.2.1 specifically? That's alright as Maven allows you to specify a specific version.
GSON probably has its own dependencies... which Maven will also download for you.
Having said all that, if you want a build system closer to Java, you could always use the Gradle dependency manager, whose configurations are written in Groovy (a JVM language). Incidentally, you can configure Gradle to look at Maven Central for dependency resolution, too.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Sun Microsystems should not have allowed Netscape to name their new web page scripting language "JavaScript".
no, I don't have a sig
Repost of the exact same link from last month?
Did a new editor come on and not search prior posts?
Only people sucked into "internet programming" bother with in either java or node.sj
I never want to begrudge people for earning a living and at least it isn't php.
I've never seen elegant javascript - I have seen extremely elegant perl and fortran. Java is plagued by memory suck and slow implementations. My systems only have 16G of RAM, so I can't load eclipse to work on java.
No Its real I just punched someone for using javascript.
They're both C languages with automatic garbage collection that can be used to build browser based applications.
I think they *could* be a little more different...
So if you can no longer install / update Java with IE11, is Java still a contender ?
https://community.oracle.com/message/12902862
It is badass rock store technology
http://saveie6.com/
http://vertx.io/
like node.js but for the jvm and good.
I was originally attracted to Node.js because, well hey, it's one less language you need to know if the backend is written in JavaScript, right?
However, I found that frontend and backend programming require very different mindsets--so much so that the one-language-in-front-and-back purported advantage is nearly nil.
However, however, the event-driven nature of Node.js is tres, tres cool. That, for me, is its real selling point. And it's baked in from the start, not half-baked with a library or extension.
"did you just say lisp?" XDDDD
I cannot image writing a production worthy server side application on top of a code base that people have been ruing for the past 10 years. Javascript has a bad rep for a reason; it is a dirty and poorly designed language. And despite the claims here, it is not particularly fast. Node can scale well to many concurrent requests, but it doesn't execute those requests that fast unless we are talking about the simplest of responses. The concurrent support within Node is also someone moot these days, as virtually all of the J2EE containers now support NIO anyway. It also has the major disadvantage of being being tied at the hip to browser implementations, which means making significant changes to the language to improve its structure will be very difficult.
My company uses JavaScript and Java together, which is where I believe the sweet spot is. We take advantage of the new development frameworks on the client side (angular) and expose REST interfaces from a Java server. We do run some Node instances for prototypes REST endpoints, but as an architect for my company, Node is a long way from being something I would build a long term strategic server side app on top of.
Learn our language so you only have to learn one language and not learn the 2 others that you already know. oook. lol
I fail to see the benefit of "non-blocking IO" when it is database concurrency that is the issue for most applications that are used to update information. So what if your first fragment of HTML can be shipped back to the client before you finish processing the page? If your servlets are taking so long to run that network IO blockages are "important to performance", you have some serious problems with your application logic.
I do not fail; I succeed at finding out what does not work.
At first it was the other way around, but: Java was always in a no-mans land: too low level to have the high level features of Js, too high level to have the power and speed of C/C++. What is needed is a data-structure based language for low level programming that is accessible to Js so that Js code can create and manipulate low level programs and request their compilation. Appropriate compilers then simply need to be made visible to Js in a natural way. If you want a bytecode vm, implement it using the low level side of this, then control it from Js. Of course python3 style features should be worked in, and whilst v8 is great if you're on an x86 or x64 machine, a llvm or something based backend for other machines needs sorting out. But then js is clearly the better language. If you want type safety, you want something like Haskell, and that is a descendent of lisp, so is best represented as data structures again, not necessarily text. Bridging the gap back to the programmer is the bit Lisp screwed up, and hopefully we can get it right this time around.
John_Chalisque
I don't care what they call it, just don't make it goofy, like they did with JS. Round-about OOP, overloaded concatenation operations, goofy hidden-flag type system, no optional parameter type checking, no optional named parameters, and a goofy CASE statement (copied C's stupid BREAK approach).
Table-ized A.I.
Ok, I've had enough. Where all those who're shunning java come from exactly? How on earth can someone still spew stupidities like "compiled java executes slowly" or "generics are stupid"? What the fuck are you doing as a living to be so out of the usual programming practices?
Next, you'll tell us that Design Patterns are bullshit and statically typed language are dead?
No, sincerely, I HAVE to know!
Just look at John Allsup, comparing oranges to apples, putting side to side Haskell, Javascript, Java and Python?! At least Java and Python are natively object-oriented... Haskell is in a totally other alley - and I personally believe that functional languages are vastly underrated - and then, boom, javascript. Seriously?
So please, just tell me what you do for a living and your past experience in programming/software architecture, because I really want to understand the background that makes you express these opinions.
It's insecure ON THE CLIENTSIDE. Nobody uses it on the client-side any more. Applets are dead and have been for years. Clientside features are still around only to support some crap legacy apps which should have died years ago.
And on server-side, it's as secure as anything. Probably more secure, as you get none of the memory issues or buffer overflow issues or other issues C/C++ has had for years.
--Coder
There is actually one example of code reuse (4th reason) that I'm aware of: TiddlyWiki 5, http://tiddlywiki.com The same TiddlyWiki 5 core as well as the extension modules runs both in the web browser as well as on Node.js. The deployment here is that you first start a Node.js-based TiddlyWiki 5 instance which also runs a local web server. Next, you point your browser to this web server and get a TiddlyWiki 5 clone delivered right from the running server instance. The in-browser TW5 instance then syncs automatically with the Node.js TW5 instance which in turn, for instance, syncs with the file system or does other advanced stuff.
well, maybe in the numbers, but def. not in the ease-of-installation ... having package managers by default is just awesome
Google Web Toolkit is java that gets um- mogrified into
browser-specific javascript. Pretty slick really.
Java:
+ Huge amounts of infrastructure in place for just about anything you want to do
+ Mature frameworks
- Still have to program in Java
Node.js:
+ Quicker to program simple apps in
+ Simpler deployment (again for small/simple apps)
- Still have to program in Javascript
In reality, all systems/frameworks/whatever all suck in their own unique ways. All that matters is matching the tech to the project.
Besides, the leading edge has moved to Clojure and ClojureScript already.
That is all.
Sure, Node.js and Java are competing in the same space; the bigger question is how? The answer to that question is Single Page Applications, or SPA. Single Page Applications are becoming very popular with new developers (I believe) because they just make better sense. For FAR too long, Java EE architects have done their very best to mitigate the separation of Client & Server. Take JSF, for Example: the entire JSF UI development experience almost lets you forget that the UI and the server context are in the same memory space. But reality frequently comes crashing down the moment you step off of the beaten path.
Enter the SPA! Angular, Backbone, etc. all rely on RESTful API's, and DO NOT CARE if it is Node.js, Java, .NET, etc. SPA’s make a full and clean break between the Client and Server realm, then only thing they share is the common midpoint of the RESTful interface; making fight less about Node.js vs Java, and more about distinguishing what you need from a back end server.
My general assertion: Node.js will continue to gain popularity and displace many competitors. Java will going to continue to dominate the enterprise market for years to come, especially with the support of specialized frameworks and utilities like Spring, Maven, Hudson, and Junit. (honorable mention for gradle)
I've never really worked with Java, but I wanted to give my perspective as a Node developer.
Better IDEs:
WebStorm, by the same people who make IntelliJ, is a fantastic IDE, so I'm not sure how this is a negative, except in numbers (3-1). If you're running WebStorm, you have excellent debugging as well. Between WebStorm and Chrome I can debug my Node-based webapps very well.
Libraries:
This is a big one. NPM has a huge collection of libraries for almost anything you can imagine, all easily accessible through the npm client tool. Good package management with NPM makes bringing in and maintaining dependencies easy and painless, while the Java world as far as I know lacks any such thing, making this a much more difficult process.
Threads:
Node.js uses threaded, non-blocking I/O, so most of your trouble is already handled. As far as threading your own code, you've got me there - the Node community has solutions for parallelization, but they're still a bit clumsy.
Tomcat, Glassfish, IBM WebSphere, BEA/Oracle Weblogic, Jetty, JBoss those are the ones I can name right now, but surely there are more, each one with their own bugs and unique features that makes porting an application from one to the other a nightmare.
Seriously you can make a whole career path being an "Certified WebSphere Application Server Developer", that is how complex each application server can be.
From the perspective of a stodgy enterprise java developer, I don't find the 'common language' argument compelling. The advantage is limited to common syntax and runtime model of the javascript/node environment. However, the problem space is quite different: on the client the task is user interaction, user interface design, translating user requests into backend data requests which can block and call back. On the server side, ACID data persistence and business logic including backend service integration. I think these problems create a greater separation of client and server developers than the programming language. Someone very good at user interface design may not have the chops for ACID data persistence, and vice versa, EVEN IF the programming language and runtime model are the same. After 15 years programming java, I picked up javascript rather quickly. I can do the transactional business logic development in jee with cross concerns of security and concurrency, but if I used javascript to write a user interface, I need more learning beyond javascript. I think 'full stack' developers are quite rare. Declaring oneself as such would be a mistake if one's ground to say so is only the programming language is common to both by happenstance.
Correction: "To be frank".
I would also like to add that many of the arguments used by Node.js proponents resemble those used by assembler language proponents when higher-level languages started eating into their profession. I'm not betting on a pro-hardware stance for most development tasks.
Table-ized A.I.
Java vs anything... Java is controlled by Oracle, therefore Java loses.
Seems quite simple, really...
How is this a contest? If I'm doing anything on a server, the last thing I'm going to reach for is Java. Java is slow, bulky, contains more overhead then functionality, eats memory for breakfast and basically breaks all concepts of what a good programming language can be. Servers need speed and reliability, well I can't argue about reliability, I can about speed. I don't care if you're stable, if you eat 20% of my system memory and make my server feel like a sports car in mud.
When NodeJS (Which Google doesn't care about enough to maintain) and Java (which Oracle doesn't care about enough to maintain) battle for the server, Go will win.
Science & open-source build trust from peer review. Learn systems you can trust.
Thanks. I don't know why I didn't think of "lack of support" as a viable reason for Java web-apps to be dead or dieing. Now, Oracle claims that JavaFX is very web-app-able. However, it doesn't seem that very many people at all are making use of JavaFX. One thing is for sure, JavaFX is entirely dependent upon Oracle continuing to support it, whereas JavaScript and related web technologies aren't going away any time soon.