I would presume that any work as significant as porting the CFML dev editor from Eclipse to VSCode would have gone through vigorous user testing before release, yeah? Cos it'd be daft if it hadn't. Right. Right?

wait, nobody in the community has been asked to test it?

So far as I know, it's still under development and therefore there's noting to test yet

I'm gonna stand by my observation.

If it's just not far enough along to begin having anyone outside the dev team look at it, I'm good with that (other than waiting on pins and needles). I agree, though - I'd think it wants poking at by people who didn't code it (but will be using it to code for their livelihood) before it's even released as a beta.

I can't remember what Adobe said was the justification for producing their own CF editor, given the community plugins available (for Eclipse, when Adobe went after that with CFBuilder, and now for VS Code). I use the regular community extension for VS Code and it satisfies my needs. Seems like a lot of work for Adobe to produce something that is worthwhile/better than the community stuff... and then, really, why would anyone pay for a VS Code extension?

it can go in the same bin with the CLI nobody uses?

It would definitely have to be super exceptional for me to even consider paying for it. Last I heard it wasn't a plugin but was going to be vscode extended like cfbuilder was to eclipse. I could be very wrong about that.

OK a lot to unravel here. Lemme go down the line: 1. User testing. We should be opening beta soon. Currently no one in the community has been asked to test it. That will change soon (tm). 2. Its a big, big beastie. The port from Eclipse to VS Code came about due to the vast, VAST majority of CF users moving away from both Builder & Eclipse over to VS Code. I know which IDE you use is basically like arguing about religion or politics (I ain't convincing anyone of anything) but it was clear that most of our users had made their choice and it was decided (long before I joined) that we would sunset Builder. a. It should also be noted, from the very start the idea that the extension HAD to be free was basically the driver. I wasn't there, but apparently this was a hard fought thing that both Elishia & Rakshith got approval on a long while back. Whether or not people would pay for an extension (people pay for Builder & this would be superior) was not the point. This is a "for the community" thing, and one that I'm putting my weight behind internally. The launch in Q122 will be just the beginning. 3.

apparently this was a hard fought thing that both Elishia & Rakshith got approval on

🎉 💯

Good points all. A fantastic example here is Microsoft Visual Studio. It existed as a fully paid model for years (in a standard/enterprise capacity) then added a "community" version that was free and added many features (but was still limited, running on Windows only, primarily being built to code C#, etc). The incredible uptake of that version led in large part to VS Code. Which as we all know is currently beating up most other IDEs across a wide swath of the app dev landscape. For me the important thing is enablement. If I build a tool that makes your life as a CF dev better, I would want to give that away. Anything I can do to reduce/limit/reduce barriers while improving quality of life for devs + improving code quality is a win for me.

We're seeing a rise of OSS developers being paid by the community too -- either through GitHub sponsorship or Patreon or kofi or similar where folks (who use the OSS projects, typically) can send one-off or recurring payments direct to the developers. But that model doesn't translate to corporations that develop/maintain OSS projects because they're already "getting paid" somewhere else, in order for them to be able to do OSS as well as their commercial products. Essentially, the community expects companies to "sponsor themselves" to provide free, OSS dev tooling and I think that's a good evolution of commercial product development: supporting free, OSS tooling through their other products. TL;DR: great to hear Adobe is committed to a free OSS extension for VS Code!

"great to hear Adobe is committed to a free OSS extension for VS Code" @Mark Takata (Adobe) is this accurate? Can you release which license the extension will be released under?

Oops, I meant "Adobe is committed to a free extension for VS Code" -- I did not mean it had to be OSS. I very much doubt it will be OSS (but that would be assume if it was, since the community could also contribute).

Sean, almost certainly this will not be open source licensed. It will be free to use by the community. There's certain rules and limits that building VS extensions puts us up against, but yes there will be things like connectors and language engines that will not be OSS (but I will ask to be sure this evening).

Basically anything that would let the air out of the bread-and-butter of ACF itself can't really be opened up - totally understandable. But free is a huge win even if the entirety of it can't reasonably be OSS. Thanks @Mark Takata (Adobe) for fighting the good fight for us 🙂

Update on this: I talked to the team about the extension and they confirmed that it would almost certainly be released (completely free!) under an Adobe license, meaning it is not OSS. However, there was talk about releasing documentation about the hooks and API endpoints for the language server which will come with the extension, meaning that possibly community members could leverage it for their own custom extensions in case anyone wanted to play in that space. I was very excited about that. We also talked about timelines re: closed/open beta testing and it was confirmed that those are scheduled to be coming in the first few months of 2022. Once I have more information, I'll let you all know and especially when we begin the open beta period.

@Mark Takata (Adobe) Do you know / can you say whether the extension will be useful to CFML devs who do not run Adobe servers? We still have 16K lines of CFML at World Singles Networks that I edit with VS Code (and the community CFML extension) but it's pretty solidly tied to (an old version of) Lucee at this point.

Sean, I'm not sure how much I can say (mostly because I don't have deep visibility into the nitty gritty of the LS) but I think it should work with any CFML features/tags that are shared across CFML frameworks. I believe we will include LS support back to 2016 tags, functions, structures in ACF. The LS will not run inside of ACF, and so should not hinge on you using an Adobe product. That said, things that are very specifically "other" (like Lucee Lang) won't have extended functionality. That said, if there's a different extension that covers that, it should work seamlessly alongside our extension. I think, TL/DR version is, anyone using CFML will find the extension better than anything else out right now, but ACF users (especially recent versions) will get the most/best benefit out of it.

Sounds great! I look forward to trying it out "next year" 🙂

Hey, since it's next year, wanted to see if you had any updated information on when a beta might be available to try out 🙂 🎁

Hey Mith, we are still hoping for a Q1 release, but it is looking like it might slip to very early Q2. I want it so freaking bad lol.

hey, just wanted to check back since Q1 is winding down. Is it still looking like early Q2? Don't mean to be a squeaky wheel - it's like waiting for Christmas tho 😄 🎁

OK so yes, we're still expecting this to launch Q2. Dunno if "early" is the right word, but all I can tell you is that I'm eyebrows deep in hucking bugs back into the fray to make sure when this gets out to y'all, it is the best it can be. My arms are tired from knocking heads together lol. (mostly kidding, it looks real good, just a few annoyances that required me to raise my voice so far). In terms of ACF versions, while this could change, currently the support is there for 2016, 2018 and 2021. Obviously support for the next version will be rolled in when the new version drops. When you set up a project, you will choose the ACF version you're running. If you're on 2018, that will be supported.

awesome - and thank you for the updates. waiting a few months more is infinitely more bearable than just not knowing. you can't put a price tag on a product team that communicates with the users. 🙂

In the future of coldfusion talk with Aditya did I hear him say the vscode extension is coming out 1st quarter next year?

It was supposed to hit q1 this year, but slipped. Now looking like late Q2. Really hoping to make a few big announcements at Dev Week but we'll see what happens.

Hey @Mark Takata (Adobe), sorry to bother you again. (Just super eager for this. 🙂) How's the outlook for a release we can try out? (even early-early beta) 😁 🎄 🎁

Totally understand the excitement, but I need this to go out as good as it can, and there's still a few things that need fixing. You must absolutely register for Dev Week though, the engineers that built it will be doing a deep dive into the features (and honestly I have no idea how they are going to do it in an hour, it took them 3 hours to cover everything with me and they were talking at mach 10 lol)

haha - gotcha. Definitely looking forward to Dev Week. 3h worth of stuff in an hour means I'll have to be ready to drink from the fire hose 😄 Thanks for what you guys are doing 🙏

I hope setting up a project is also just a json file.

Not sure how the project files work, I assume it is a .proj file as that's the standard for Visual Studio. Yes it comes with an LSP, and I'm 99% sure there's nothing keeping anyone from leveraging it to make their own tools.