Can AppleScript now be replaced with JavaScript?

JavaScript for Automation (JXA) 1.0 is sufficient if you are willing to be flexible in what implementation approach is taken. With JXA 1.0, you may need to do things like:

1. use the JXA-to-ObjC bridge when the JXA-to-traditional-AppleEvents* bridge does not work,
2. create a JavaScript filter when the JXA 1.0 whose bridge query does not work,
3. think clearly about when to use the Objective-C side, the JXA-new-stuff-bridge, the traditional-AppleEvents-bridge or the JavaScript side

* Apple events scripting has been around since the early 1990's starting with Classic MacOS 7. Since around 2006, Apple recommends to considering non Apple event mechanisms.

Note: Apple events are not always the most efficient or appropriate mechanism for communicating between processes. OS X offers other mechanisms... [Apple, "Open Scripting Architecture"]

Both AppleScript (AS) and JavaScript for Automation (JXA) suites have similar automation coverage. AppleScript bridges are more mature. JavaScriptCore engine has more built-in capabilities. For example, capabilities like regex, encodeURI, JSON.stringify are already build into JavaScriptCore.

|  Feature                     |    AS     |    JXA    |
|------------------------------|-----------|-----------|
| Scripting Dictionary         |     ✓     |     ✓     |
| Standard Scripting Additions |     ✓     |     ✓     |
| JavaScriptCore               |     ‐     |     ✓     |
| Apple Event Scripting        |     ✓     |     ✓     |
| Cocoa Scripting              |     ✓     |     ✓     |
| C function binding           |     ‐     |     ✓     |
| Automator Support            |     ✓     |     ✓     |
| #! shell runable             |     ✓     |     ✓     |
| Debugger                     | 3rd Party |     ‐     |
| Language Popularity          |  Niche    |   Broad   |

Does this mean that I don't have to learn AppleScript anymore to do scripting ... ?

Maybe yes.

Sometimes it's helpful to read an existing AppleScript example. Though, sometimes it's more productive to toss the AppleScript file and start without a pre-conceived approach.

BTW: You will still need to understand the Scripting Dictionary for any scripting language used.

from the perspective of the app user who wants to make the app do things automatically?

As an app user, JavaScript for Automation will work with the previously noted caveats. Particularly, consider using more JavaScript & Cocoa features and less "Apple Events" features.

For example, "The traditional "System Events" approach has the merit of simplicity, but using $.NSFileManager gives noticeably faster performance." In one use case $.NSFileManager was 300% faster than "System Events". [JXA-Cookbook Wiki : Getting a List of Folder Contents]

... with respect to the app developers (Cocoa)? Can they get away with not learning AppleScript if they want to make their apps scriptable?

Yes and No.

What the developer controls is the object & methods exposed via the Scripting Dictionary. This Scripting Dictionary (.sdef) must be done for access by any scripting language including ones like Perl, Python and Ruby.

So, behind the scenes the developer provides an application scripting gateway which is Objective-C/Cocoa centric and generally scripting language agnostic.

What developers do not control are the scripting bridges (e.g. Cocoa Scripting, Apple Events, ObjC, C Function Binding). Report scripting bridge bugs to the Apple Bug Reporter.

A conciencious developer will have a test suite to exercise the application Scripting Dictionary via all scripting language of importance to their customers. A good test coverage would be automated and likely use multiple scripting languages.

... already know JavaScript, is there any good reason I should learn AppleScript anymore?

Until more JXA documents are produced, some existing AppleScript materials can be helpful to explain various aspects of the scripting architecture.

Existing AppleScript automations, with skilled AppleScript expertise available, in revenue gerenating workflows, may wish to be conservative on when to adopt JXA.

If you already know JavaScript and the automations are for you personally, then JXA (with the noted caveats) seems like a reasonable choice.

Update: Apple has now generally published a Mac Automation Scripting Guide

Revision 2016-10-27. New document that provides an introduction to using AppleScript and JavaScript.

Revision 2018-06-07. New document that provides an introduction to using AppleScript and JavaScript to streamline workflows and increase productivity in OS X.

Update 2019: The Mac Automation Scripting Guide is now an archive document.

Can AppleScript now be replaced with JavaScript?

For trivial stuff, probably. Beyond that, probably not.

1. Too many Apple event/OSA features are crippled, broken, or missing entirely in JXA. It works up to a point, but beyond that you're stuffed. For serious or production work, when needing features that JXA screws up, or when dealing with applications that make JXA run away and cry, you will have to stick with AppleScript: it's the only currently supported solution that actually does this stuff right.

2. You still need to understand how application scripting works, for which you'll have to read the AppleScript literature. JXA's own documentation is pathetic and misleadingly wrong, so you'll be none the wiser from reading that. There's no 3rd-party JXA literature that explains the concepts, and any that does appear in future is likely to be misleadingly wrong too. (Heck, even the current AppleScript books tend to fudge/lie/get it wrong.)

3. You also need to understand how to script specific applications, and application dictionaries are notoriously incomplete and insufficient on their own. Which means you're reliant on supplementary documentation (if any exists), sample scripts, and more experienced users of those applications. And all of those are AppleScript-based, so you'll need to know some AppleScript in order to understand and communicate with them.

4. App developers should continue to develop and test their applications against AppleScript - it is the de facto specification against which all scriptable applications have been developed and tested over the last twenty years, and this will continue to be the case. Even if JXA wasn't such a sack of knackers, devs would still need to test against AS just to be sure they've not overlooked any quirks there.