Rewrite in ColdFusion

[bdw429s]

This is a little embarrassing for Adobe, but I guess they forgot that they are the proud owners of an awesome and modern JVM scripting language called ColdFusion. Implementing this site in Node must have been an understandable oversight. Please correct it with a healthy dose of Adobe's own products. :)

Please reach out if you need help. There's modern equivalents to all the tools you used for your Node back end. MVC, testing, package management, etc. Just think how much cooler the site will be when it finally says "Powered by Adobe ColdFusion" at the bottom!

[bdw429s]

Oh dear, looks like the actual Node API is in another repository here: https://github.com/kimchouard/server.adobe.github.com

Looks like quick work for a simple ColdBox MVC microservice running CF on Docker. I'm sure the CF community would love to help get that rewritten for you all.

[noraacl]

@bdw429s sounds like a great suggestion. How do we go about getting help to use ColdFusion?

[bdw429s]

@noraacl Thx for the reply! If the code in the repo above is all the Node surface area, I can help write a simple CFML app that duplicates the same functionality and runs on Adobe ColdFusion using all the latest best practices for MVC, REST, and testing.

I know nothing about your hosting requirements, but I can help you wrap it up in a container, or provide instructions on a standard server installation. You'll need a license to run Adobe CF which I'm sure the Adobe ColdFusion team can help you with. I'll ping the CF project manager and ask him. They might have some existing CF-based infrastructure already in place that it could be deployed to since it sounds like the API portion is its own thing.

If you want an easier way to connect concerning this, sign up for the CF Slack team. Many of the Adobe people from the CF team are present on this public team too. https://cfml-slack.herokuapp.com/ You can DM me there as @bdw429s

[bdw429s]

Hi @noraacl , sorry for the delay. I rewrote the Node API in ColdFusion a few weeks ago, but took my time sticking it up on Heroku. The ColdFusion equivalent of the web service you're using is here as an open source project on GitHub: https://github.com/bdw429s/server.adobe.github.com It does everything the old version did including configuration, caching, and easy local execution, but it's built with Adobe's own ColdFusion technology!

You can see a version of it running here on my personal Heroku account: https://server-adobe-github-com.herokuapp.com/ I've tested it with the github.io app and it seems to run fine as a drop in replacement for your Node app.

If you'd like to move forward and embrace the power of Adobe's own technologies, we'd just need to work with the ColdFusion team to get you a license to use and discuss your hosting arrangements. The app can run anywhere, but I put it on Heroku to demo since that's what you were already using and it's fast and easy to setup,

[bdw429s]

Hi @noraacl , I spoke with Elishia Dvorak of the Adobe ColdFusion team at cf.Objective() this week and she confirmed that the ColdFusion team will happily provide a license for you to use the ColdFusion version of your API that I wrote. How can we move forward with changing adobe.github.io to use Adobe's own products to power it?

[stevengill]

Hey @bdw429s!

Thanks for spending time looking into this.

I'm worried switching to cold fusion will lead to less contributions. The truth is that Node.js is more popular than coldfusion. I'm basing this off google trends [1] and seeing that javascript is the most popular language on github [2] .

Node.js is fully open source and doesn't require a license. It is widely used in open source and fits in better with what we are trying to accomplish.

Unfortunately, we will not be switching to CF.

[1] https://trends.google.com/trends/explore?q=coldfusion,nodejs [2] https://octoverse.github.com/

[bdw429s]

Hello @stevengill and thanks for the reply. I'm a little confused however as you seem to be perhaps not understanding the reality of what you have in place and what I'm suggesting.

Firstly, ColdFusion (one word BTW) is a product of Adobe (your company). The onus should be on you to explain why you would even begin to write web apps in another language than the one proudly owned by your own organization. If you can show me a single Microsoft website written in any language other than .NET then you might have a point. There's really no excuse for Adobe to use a competitor here.

Secondly, in regards to contributions, there have never been any contributions to your Node API. Ever. Not a single one. The entire API was written by a single person and only has one unmerged pull request in the history of the repo which is to the markdown on the readme file. Here is a link that shows how contributions has never been a part of this API: https://github.com/kimchouard/server.adobe.github.com/graphs/contributors I fail to see how you would be losing anything. Besides, CFML is an easy scripting language used by hundreds of thousands of developers around the world. My CFML port of your Node API actually used LESS CODE to do the actual GitHub interactions. And quite frankly, it's more readable than the mess of callbacks present in the Node version. Your Node API is a separate project and repo from this main repo. The only thing that needs changed in this repo is a single line of code that points to the URL of the backend API that provides the JSON data.

Thirdly, regarding the popularity of languages. I would ask you, is the point of adobe.github.io to advertise popular competitors on GitHub, or to showcase Adobe products and technologies? (I believe the answer is the latter) I will also point out to you that Adobe ColdFusion is more popular than Node when it comes to building web apps. This is reported by w3tech. CFML is the 5th most used technology for web apps and Node doesn't even make the list (neither does Ruby, Python, or Clojure for that matter).

Fourthly, regarding the closed-source nature of Adobe ColdFusion. There are actually free and open source CF engines, but I suppose that is neither here nor there since the point is that Adobe should be supporting and using their own technology stacks and not competitors. While ColdFusion itself is partially closed source (it bundles a ton of open source Java libs like Apache Commons), CFML as a language boasts its own open source ecosystem. CF devs use package managers, open source frameworks, code sharing sites, and I'm an author of quite a few open source CFML libraries myself. Therefore, the notion of using CF in no way runs against using it to promote open source work. The Adobe ColdFusion team has already offered you a license to use and I've already deployed the CFML version of the API to Heroku for you to test. All you would need to do is create your own Heroku deployment and put the license key in.

Will you please reconsider your use of technology? It's honestly a sad day when I have to remind a company that it's poor form to use a competitor's stack over their own products. You already proudly advertise your use of the Creative Cloud, which is excellent. I presume it never would have crossed your mind to use GIMP instead for your graphic design because, you know, it's open source!

[stevengill]

Hey @bdw429s. Adobe is a very large company. We don't have company wide mandate to force everyone at adobe to use CF. It is up to the development team. I am admittedly not experienced in CF but am very experienced in open source, javascript and node.js. I don't appreciate the chastising for us picking a different stack. Use what works best for you and your team is my mantra.

[bdw429s]

@stevengill I do apologize if you've taken my remarks personally. I'm painfully aware of Adobe's failure in embracing their own products everywhere. This has been a fact that's chaffed ColdFusion developers for years (and especially recently as Adobe's entire blogging platform was moved to PHP of all things :disappointed: ), but to be clear I don't blame the corporate mandates on you. I do however think this is an excellent opportunity to improve upon the work you've done in a manner that reflects upon the company that you represent. This isn't just "a team" doing what works for them. This is a team of Adobe employees building a web project that showcases Adobe's technologies.

On a side note, I would encourage you to look into CFML if you're into learning new things. I think you'll find it reads very similar to JavaScript: https://github.com/bdw429s/server.adobe.github.com/blob/master/models/github.cfc

I'll also add that one of the reasons I'm leaning a little hard on you is because I'm not asking you to learn CFML, code in it, or do any work yourself. I've already coded the complete conversion of your Node API to a modern CFML REST app and it's ready for you to drop in and use. It's forgivable to have started at a point of familiarity, and in the spirit of open source contributions, what is the real reason not to move forward with this change to embrace the awesome stuff Adobe offers? If you can't tell, I'm a big fan of ColdFusion and my overall goal here is to help promote it alongside these efforts by Adobe. The very inverse of this is true in ColdFusion itself, where superior technologies from the Acrobat team like PDF manipulation are proudly showcased in the ColdFusion platform.

[stevengill]

I wish I saw your original message to the thread when it was posted so I could have stopped you from spending time doing the conversion. I appreciate that you were so interested in contributing. Just because the conversion is done is not a good enough reason to do the migration. We don't have any CF devs in the Adobe open source office. I'm not interested in migrating a project to something that no one in the open source office can update/maintain without having to learn a new programming stack.

We have made the decision internally to build our open source web site using open source technologies. We appreciate the enthusiasm for CF but our decision is final.

[dakuwan]

Would like to second Brad on this issue for all of the well thought out and well supported reasons he's stated. Especially since the fix is done and ready for deployment.

I don't want to speak for Brad but for the comment of spending time I can bet that with ColdFusion he was able to build the entire new version significantly faster than it was built in Node.

While it may not be company policy to use and promote your own technologies this is an opportunity to take the initiative to do so. This would be something any management team would see the value in and reward as it benefits everyone when your corporation and products are promoted with minimal effort.

Finally this would be an opportunity to expand the development team's skill set by learning CF. It is a great language and I am sure like any developer it is better to have more tools at your disposal than "siloing" oneself to a single viewpoint.

[howardowens]

I'm confused. An employee of a company is arguing against using his own company's products? That makes no sense to me. Especially when the company in question has a great product that anyone in the field in question should embrace.

[robertdmunn]

ColdFusion should have been open-sourced and the core product made free back around Y2K or so. The pro/enterprise products could still be sold as they are now and include extras that you don't get with FOSS products. This is basically the model of every OSS company ( e.g. Red Hat and Canonical ). Oracle gives away Java and maintains a very healthy enterprise Java business, even though they are not traditionally an OSS company.

I still think ColdFusion ( and Lucee ) should be re-cast as JVM application platforms and have their underlying engines re-written to handle JavaScript, CFML, ActionScript, and other arbitrary programming languages that could be compiled to the JVM. The value-add in ColdFusion - beyond the ease of use of CFML - has always been the unified nature of the platform. With Node you can't just run an installer and deploy an integrated application platform. You have to do quite a bit of work just to assemble a comparable toolset. Of course, the extra work is worth it if you are deploying a large-scale website, but for many small-to-midsize sites, it pays to invest in a commercial product. Which is why I think ColdFusion ought to support more languages. I'm sure someone could come up with feature sets for a FOSS version and a commercial version.

[atuttle]

(emphasis in quotes is mine)

@bdw429s

The onus should be on you to explain why you would even begin to write web apps in another language than the one proudly owned by your own organization.

Nobody said Adobe is proud of ColdFusion, Brad. I defy you to show me proof that they are. ;)

If you can show me a single Microsoft website written in any language other than .NET then you might have a point.

I wasn't able to find one with weak google-fu in 5 minutes of looking, but it did help me remember that Microsoft is developing an implementation of Chakra Core, as an alternative engine that they propose as an option over V8 for Node.js. They've been at this for years. Obviously they believe Node.js has legs.

I will also point out to you that Adobe ColdFusion is more popular than Node when it comes to building web apps. This is reported by w3tech. CFML is the 5th most used technology for web apps and Node doesn't even make the list

Yes, according to that one cherry-picked source, ColdFusion is "more popular" than Node. But according to that same source, if CF is better, then PHP is best. Why aren't you arguing for PHP? Or, you know, static HTML, which also beats CFML from your cherry-picked source.

How about this source which lists JavaScript as the most popular language on Github? Not just by a little bit: More than double the numbers of the 2nd place position Java. Or we could look at Stack Overflow where the most common tag is JavaScript with 1.4 million questions of which more than 1,000 were asked today (it's 8:30 am on the east-coast of the USA). Where does ColdFusion rank on SO? 11,000 total questions of which 6 were asked today.

I think trying to make a point about popularity was misguided. Anyone who thinks that Node (or Python or Ruby) is less popular than CFML is either blind to the situation at hand or being willfully ignorant. ColdFusion has been around a very long time, which has contributed to it powering many (old, outdated, poor-usability) websites. And PHP, which was basically the OSS twin of CFML, born around the same time, ranks number 1 by your yardstick. So in a way you've argued against yourself: Open source will have been the better choice in the long run.

The Adobe ColdFusion team has already offered you a license to use and I've already deployed the CFML version of the API to Heroku for you to test. All you would need to do is create your own Heroku deployment and put the license key in.

And yet, here we are. CF is so toxic that Adobe doesn't want to touch it. You've literally done all of the leg work for them and their response is, "Nah, we're good. thanks anyway." That should tell you something.

I'm not asking you to learn CFML, code in it, or do any work yourself. I've already coded the complete conversion of your Node API to a modern CFML REST app and it's ready for you to drop in and use. It's forgivable to have started at a point of familiarity, and in the spirit of open source contributions, what is the real reason not to move forward with this change to embrace the awesome stuff Adobe offers?

So if I rewrote part of CommandBox in Haskell and said to you, "Come on bro! I've already done the work! Just use my thing!" you'd adopt it? I think not. Maintainability is important. Their team is obviously competent in JavaScript and you're shaming them for using what they know rather than toeing a company line that the company isn't even pushing. The real reason is that getting work done and knowing that you can maintain it in the future is far more important than looking good to the .001% of the population that cares what platform you use.

---

I know that @bdw429s knows who I am, because as I walked down the hall at cf.Objective() last week and got close enough to hear him bashing my Open Source project and trying to convince another attendee to use his team's alternative he noticed I was near and awkwardly silenced himself until I had passed... But for those of you who don't know my background, I say all of this as a long time ColdFusion / CFML developer, who has been disillusioned both by Adobe's lack of investment, and the people it decided to put in charge of the ColdFusion product. (For what it's worth, I tried the OSS alternatives and was equally disappointed by both the product and the team.) I also say all of this as a CTO that has decided my developers' time would be better spent enjoying the benefits of a large engaged community, rather than trying to keep ColdFusion alive on life support for a little while longer.

Yes, ColdFusion is functional and that's not just going to stop one day. As long as you can feed your family with it there is no shame in continuing to use it. (We still write some CFML here and there too, begrudgingly...) But be honest: Its hay-day has long since ended. ColdFusion is the COBOL of the web. COBOL is still in use today driving the AR/AP departments of probably 9/10 of the fortune 500. Does that mean anyone should ever argue that effort should be expended to rewrite something in COBOL?

[isapir]

Adobe is a very large company. We don't have company wide mandate to force everyone at adobe to use CF.

I'm surprised that you didn't choose Lucee then ;)

[isapir]

And PHP, which was basically the OSS twin of CFML, born around the same time, ranks number 1 by your yardstick.

Let's face it, if there was a free (as in beer) CFML engine back then, then there would be no PHP today. The only reason that PHP became popular was that it was free, while ColdFusion was a commercial product costing thousands of $$$.

[aarongreenlee]

I've had the pleasure of delivering some amazingly successful projects using ColdFusion for Adobe while contributing to ColdBox and other open source projects. I do know Adobe did have a mandate to use "Adobe @ Adobe" a few years ago.

I started with ColdFusion in the late 90s and invested in it until 2014. This is thread is an example of why I've started selecting other tools for projects since 2014. The truth is there are a lot more people skilled in other tools and hiring and training new talent is easier for other tools. ColdFusion is loosing mindshare.

I owe much in my life to ColdFusion. Community. Friends. And much more. However, I don't think the pressure of this thread is reasonable. ColdFusion was not the right tool for this job due to other constraints. ColdFusion is capable--sure. Developer mindshare is against ColdFusion which means practical constraints favor other languages and tools. If Adobe has a idle Engineer skilled in Node or something else then that Engineer should be empowered to choose the tool that works for them to deliver their project on time.

I think the offer to replace this work with ColdFusion is admirable. But I encourage the participants of this thread to raise their gaze, recognize the trends and the constraints they create.

Most respectfully,

Aaron Greenlee