I saw someone mention that ACF2023 was in Alpha 2. Can anyone from Adobe speak here about the status of this issue, what the state of "cfscript 2.0" is, and whether it's going to be part of 2023? https://tracker.adobe.com/#/view/CF-4210829 @priyank_adobe @Mark Takata (Adobe)

There are no changes or updates related to "cfscript 2.0" in this release (alpha2) nor is it a planned functionality for CF2023. I'll ask the team to review that FR.

I'd dearly love to understand why anyone thinks that's a valid suggestion before you invest time bugging the CF Team about it, @Mark Takata (Adobe)

Well, to be fair, WE are the ones that announced that "CFScript 2.0" was coming and would be ECMA compliant. Like in... 2016? Something like that. So at this point I think we drink or wash the glass. But old tickets by their nature annoy me, I'd like to close it if we think it will never happen.

IMO, that would be one of my favorite features. I have been working with TypeScript in the last few months, and it has great benefit. ECMA is closer to reaching that goal.

I mean, since cfscript itself is currently syntactically closer to JS (insofar as it's not CFML tags), it makes a lot of sense to say "hey, let's leverage some language features from there, like destructuring, rest/spread operators, etc." It's an entirely different animal to say "let's implement the ES spec". My hope with the ticket is mainly to get clarification. imho, if you get something for free and there's transparency about the development process (FOSS), a paid thing should have at least as good transparency and communication about the roadmap and progress. To the credit of Adobe, having Mark and Priyank active in this Slack is worth a lot.

It comes in layers. Here is my thinking, not saying anyone else is right or wrong. • Code Hinting, etc. in the IDE change the user experience. If CFML, with or without script doesn't help the IDE help the developer... the CFML experience will be a legacy coding experience. • People are learning other languages, not advancing feels legacy. • Full stack devs are in both worlds. They feel the gap. P.S. The language experience I get in TypeScript, Vue coding is very different than CFML at large. Linting being a strong example of the gap we have felt for years. It is also how we can explore related code in JS/TS, hinting, etc. The issue is people feel the issue where they feel the issue. It is a tradeoff decision always for all of us. The most dangerous position is when the primary tradeoff is the cost of leaving what we have.

Just because CFScript is a C-ish language and has curly brace and semi-colons and stipulates a similar syntax as JS does with flow-control structures etc doesn't mean it has (or should have ~) anything to do with the the ECMA specification. The ECMA specification is for JavaScript. Which is a completely different language. This is really embarrassing thinking on the part of ppl that advocate this.

John, thinking CFML is legacy is not solved by "cfscript is now es6 compliant". It is a lack of knowledge on the parts of the leadership at those companies. They made a statement which was, clearly, wrong and then acted on it. ACF is a modern language built on modern underpinnings. Just because it is named the same thing for 26 years doesn't mean it is "legacy". That's like saying "Windows is legacy" or "The Ford Mustang is legacy". Also, a move towards ES6 compliance would play merry hell on backwards compatibility, and the only other option is to have yet another style of coding optionally supported inside CF. I don't see the value, and frankly I think the vast majority of CF developers would agree. Now, a method to crosspile from typescript to CFscript? Maybe. There might be something cool there.

If CFML used a flavour of JS as its scripting language, but it had some non-standard implementations, then having a ticket saying "make it ECMA-compliant" would make sense

Agree with Adam, the IDE integration and linting are bigger points of interest.

"adopt this cool feature from JS, and use the same syntax"? Yeah, cool. Suggest that.

I'd like to suggest adopting the feature of JS where the batman symbol is true.

@Mark Takata (Adobe), they did make a statement that is wrong. I think we respond as developers defending our product instead of hearing their concerns. They don't care if ACF is legacy. What do they care about? It's like that book, question behind the question. When they say legacy, what is the particular concern?

Don't get me wrong John, this story is as common as rain in January. I hear it constantly, endlessly. Sometimes I manage to get there before they jump. But too often, I don't.

I think the things that make ACF appear to be "legacy" are maybe not even the language (or its syntax). People probably have looked at things like the debugger/Eclipse IDE, the bug tracker (slow as anything, clunky UI), docs (perennial pain point for me personally, especially the nav and information hierarchy), roadmap (lack thereof), paid license model, etc. There are plenty of things other than "is it ECMA yet?" that are integral to the optics of the platform overall. For my original question of "what's the status of this ticket", I'm pretty well satisfied that the answer is, essentially "we wanted to bring destructuring and some new operators and member functions over from JS, but misspoke. cfscript is maybe still of interest internally, but we shouldn't have announced it til it was in, like, at least alpha - sorry about that. ECMA compatibility, at very least for reasons of case-sensitive identifiers and 0-based arrays, is just never going to happen, though we'll certainly continue to improve and add features to cfscript itself." (truth be told, when I heard the announcement of ECMA compat at first, then thought about back-compat issues, all my words on the subject since have essentially been a passive-agressive "are you... sure about that?" 🙂 though not in a mean-spirited way, and hopefully it wasn't taken as such.)

Mith, you mention "road maps". What kind of road maps would you envision seeing? Can you point me, for example, to publicly available road maps for other language/frameworks? We provide road map sessions for customers when they ask for them, but we generally do not post them up, as often things are being planned years in advance and it would be a competitive disadvantage to share things of that nature.

One that I've been impressed by is the open development and roadmap recently begun by the Remix team. They stream their planning sessions where they discuss what to put on the roadmap and why, and the roadmap itself is hosted publicly in github. They also have a discord chat channel for their roadmap livestream that users can ask questions and participate in the discussion on during the YouTube stream. Short of a full-blown open process like that, a regularly updated public web page that lists all features slated for development and their status and what version they'll be released under would be great.

I heard a senior developer tell me that when things are hard to find, it helps them figure out who the better developers are. They might see this as a good thing.

re: competitive disadvantage in sharing, from a customer perspective, I kinda feel it's a competitive disadvantage to not share

We happily share with customers in a controlled environment. I can see the value of open-source projects sharing their road-maps. But like... it is unlikely you'll see, for example, Microsoft SQL Server having a "here's all the features we are working on and will be releasing over the next few years". I think there's a bit of dissonance that comes from ACF being one of the few paid development platforms. I think even Lucee doesn't have a TON of roadmap info (as things are sort of shifting and changing). That said, I agree that more transparency could be a good thing, and could help with folks feeling like "Adobe ColdFusion isn't being actively developed" which is a thing I hear far too often for my blood pressure lol.

lol, gotcha. but, only sharing things that reach a certain point - sure. in fact, definitely

I don't think Zend has a detailed roadmap either.

and it can totally change, as the release goes from alpha to RC - but just to let people see what's happening as early as Adobe is comfortable sharing, and have it be consistently updated at least once per major release

Id rather see a small sub-feature "standard" license for a single user, single domain, low use single site, for 100 than this, well you want 2 processors and standard, that's 2600.. You want 8 processors and to generate a PDF while having it yodle, that will be 9800. In a world dominated by Opensource, its hard to tell a customer, Why yes, this can be done in half the time, half the effort, and will do what you want but the internal cost is 9800 + server hw/sw and explain why AFC is the best thing EVER, or the client will just blankly look at you and go, WTF, Python, ASP, java, (a billion other languages and buzzwords they picked up watching CNN ) and ask, do that as it will ultimately cost less. Fortune 100s, great, perfect dont ever change, Everyone else, stop painting the product into a small corner as even Microsoft and Oracle caught up with modern culture and marketing.. For the love of god, do the same.