I do not think this is an original thought.

But it seems to me that javascript (and the ecosystem around it including typescript and node) has evolved to fulfill Java's original promise better than Java ever did.

In the introduction of the whitepaper "The Java Language Environment" [link] , written by James Gosling and Henry McGilton in 1996 ( the same year as the introduction of Java 1.0), Java is marketed with the following section

The Better Way is Here Now

Now there is a better way -- the Java ^TM programming language platform from Sun Microsystems. Imagine, if you will, this development world...

• Your programming language is object oriented, yet it's still dead simple.
• Your development cycle is much faster because Java technology is interpreted. The compile-link-load-test-crash-debug cycle is obsolete--now you just compile and run.
• Your applications are portable across multiple platforms. Write your applications once, and you never need to port them--they will run without modification on multiple operating systems and hardware architectures.
• Your applications are robust because the Java runtime environment manages memory for you.
• Your interactive graphical applications have high performance because multiple concurrent threads of activity in your application are supported by the multithreading built into the Java programming language and runtime platform.
• Your applications are adaptable to changing environments because you can dynamically download code modules from anywhere on the network.
• Your end users can trust that your applications are secure, even though they're downloading code from all over the Internet; the Java runtime environment has built-in protection against viruses and tampering.

You don't need to dream about these features. They're here now. The Java programming language platform provides a portable, interpreted, high-performance, simple, object-oriented programming language and supporting run-time environment. This introductory chapter provides you with a brief look at the main design goals of the Java system; the remainder of this paper examines the features of Java in more detail.

The last chapter of this paper describes the HotJava ^TM Browser . The HotJava Browser is an innovative World-Wide Web browser, and the first major applications written using the Java platform. It is the first browser to dynamically download and execute Java code fragments from anywhere on the Internet, and can do so in a secure manner.

These were fantastic features for 1996.  I think looking in the lense of time, it's undoubtable that Java represented a great combination of attributes, despite it's haters decrying its verbosity or excessively OOP nature [ both quite minor problems more related to certain enterprise design pattern trends or fads rather than major flaws in the language IMO ] .

However, in 2025, is Java the environment that best fulfills its original selling points, or has another runtime environment / language surpassed it?  Also has Java positively transformed and added new significant selling points in the years since?

I would argue that it is Javascript/Typescript that is better at Java's design goals than Java is at this time.  Let's walk through the selling points and see how the languages compare:

• Your programming language is object oriented, yet it's still dead simple.

Javascript has grown from an at-times awkward scripting language into a flexible and powerful language.  With Typescript added to the consideration, I would say the JS/TS language platform often enables more expressive programming than Java does (think about defining JSON data in line, features of the TS type system like algebraic data types that surpass what is available in Java (albeit only at compile time), or the built in and comprehensive support for Promises and async/await programming).  At the same time, the entry point for JS is still more "dead simple" than Java ever was.

• Your development cycle is much faster because Java technology is interpreted. The compile-link-load-test-crash-debug cycle is obsolete--now you just compile and run.

JS has always done the "interpreted" part of this.  However JS used to be much slower at runtime.  With the immense investment in JS runtimes over the last couple of decades, the performance gap has massively shrunk however, and depending on the benchmark and benchmark implementation, one or the other language can often come out in the lead [1] [2] . 

• Your applications are portable across multiple platforms. Write your applications once, and you never need to port them--they will run without modification on multiple operating systems and hardware architectures.

This is where modern JS starts to leave modern Java in the dust.  The web browser has become pretty the much the universal cross-platform runtime installed on every phone, tablet, and personal computer.  JS supports instant and easy distribution to this very important platform.  Java, not so much.  The Web platform has also evolved into a very advanced user-interface framework.  In comparison, the Java platform's alternatives are either dated or not really that competitive on mobile platforms.

• Your applications are robust because the Java runtime environment manages memory for you.

Great selling point when compared to systems languages.  But not a selling point compared to JS which does the same.

• Your interactive graphical applications have high performance because multiple concurrent threads of activity in your application are supported by the multithreading built into the Java programming language and runtime platform.

This one is a mixed bag.  I think Java still holds the general lead in multithreading support vs JS at least when comparing vs the web platform + JS.  However the quick-startup time and lower overhead of running a JS interpreter relative to Java enables efficient use of newer concurrency patterns like horizontal scaling easier than is possible for Java. 

• Your applications are adaptable to changing environments because you can dynamically download code modules from anywhere on the network.

I think this feature is commonly used for JS today but is pretty much not used for Java today.  

• Your end users can trust that your applications are secure, even though they're downloading code from all over the Internet; the Java runtime environment has built-in protection against viruses and tampering.

This is one where Java essentially has given up and which JS has taken up the mantle and fulfilled in full.  Java incorporated a feature called the "Security Manager" [link] which basically was an integral part of the "sandbox" system that was designed to support applets. It theoretically supported fine-grained access control to various system resources including the filesystem and network resources.   In reality, my perception is that the security sandbox was never really that great and there were a number of exploits over the years.  Eventually, applets got a bad reputation and were phased out.   Around that same time, people generally stopped installing the global java runtime on their machines -- instead the expectation became that the JRE would be bundled with apps that were written in it.  More recently, Java deprecated then discontinued the "Security Manager" feature completely [link].  The argument being that you could now use external containerization or vm technology to accomplish similar purposes. 

While Java gave up on fine-grained access control and sandboxing to run untrusted code, the Web leaned in to this, leading to the situation where now a great deal of functionality can be accessed by applications built on the Web platform, all with high-quality sandboxing/access control in place and provided by the browser.

The end result of the changes with the deprioritization of Java as a client-computing environment, retreat from interactive Web applications [no more applets], and retreat from security sandboxing, while the Web platform doubled down on each of these, means that the Web implements the design goals of allowing distribution and running of untrusted code over the internet to a far greater extent than Java does today.  

Other strongpoints of the Java environment have become more liabilities than benefits in this day and age.  For instance, the JVM has been regarded as an engineering marvel underlying Java's strong support for easy-cross-platform development.  But now, thanks to certain design choices made in its implementation, it can seem rather heavyweight in memory utilization (I think due to certain choices about memory layout for objects and GC overhead), and sometimes slow to complete start up of an application (I think in large part due to the classloading process), when compared to languages like nodejs, or even more direct competitors to the JVM such as C#/.Net.

I don't think Java has really followed through on any compelling new features to draw developers on the client or the server in the last 15 years or so.  JavaFX was a cool technology but I don't think it ever really matured as a very competitive option on phones and tablets.  Project Valhalla, which is intended to enable more efficient memory layouts in Java through introduction of value types similar to what is possible in C# (or C++ or Rust for that matter), has been incubating pretty much my entire career with nothing much to show for it on the ground. Project Loom / Virtual Threads is a cool feature, albeit late, and I'm not convinced it's a huge advantage in practice vs the long preexisting async/await support in other competitve languages including JS.  The various syntax and usability improvements of Java over the years have mostly just been partial catchup efforts and Java remains generally more verbose than TypeScript for instance.

In conclusion, I think that while Java/the JVM was the only platform in town that delivered well on its original marketing promises of an internet-connected universal client computing platform for probably around 10 years after its introduction, Java retreated on most of those promises and today the Web platform does a far better job of implementing Java's original marketing goals.  On the server side, the competition between Javascript runtimes like Node or Deno and Java/the JVM is much more competitive. And I think Java is still a strong choice.  But sometimes some of its onetime benefits (such as the JVM) have turned more into liabilities.  And without convincing new arguments for writing applications in Java, I suspect the balance of new line-of-business software development will continue to shift towards other runtimes including TS/JS runtimes and away from Java.