Hi Fam! Met a lot of you folks during the CF Summit and had the most wonderful time meeting you all. ❤️ For those of you attended my talk, we talked about what's coming in CF Next. I wanted to run some interviews with you all to understand your use cases and the newer functionality you require on CFCharts and CFSpreadSheet first.. I also want to gauge feedback on some of the things we're planning on these features at our end to get some early feedback from you all on it! If these two libraries interest you or you were forced to use them in your code 🙃, please share your contact email ID, in DMs or comments, as you prefer.. to talk more about them! .. we will have discussions on more features as we keep picking them up!!

Hi @Charvi Just switched from Ben Nadel's POI library to native cfspreadsheet (ACF2023). Has been good experience so far and more performant. Not sure if it's doing it already, but anything to improve the performance for big spreadsheets. I saw that the spreadsheet-cfml library can stream on Lucee. Don't use CFChart, we use Javascript libraries (e.g. chart.js, etc). My gut would be not to waste time there. About to shift fromo wkhtmltopdf to cfhtmltopdf. First pass found some bugs 😉 We use Google Sheets over MS Excel

Agree re charting. CFML is for server-side processing: leave the client-side rendering of data to client-side tools. The best thing you could do with charting would be to mark it as deprecated and leave it at that.

thanks @davequested, I have a few follow ups questions on Google sheets.. DMing you! thanks for the feedback @Adam Cameron - just want to look out for folks using CFCharts.. plus any features of interest for server side charting, as well as reporting / dashboarding work that can be done with the library...

@Charvi the general consensus re the UI components in CFML is "do not use", and this has been the case for over a decade. Even the people in yer own team have stated in the past they're on board with this notion. Not sure why yer even looking at this stuff. The benefit of marking stuff as deprecated is that it continues to work for those already using it, but it's a responsible way of not encouraging anyone to start to use them. You should not be encouraging ppl to use this stuff, and you should not be wasting the CF Team's time stacking the pile even higher.

@Adam Cameron i'd want to hear from more people on this.. if that's the general consensus, i'm open to not pursue this.. we did run some interviews with folks initially who were using CFCharts.. and we have plans of building more reporting and dashboarding CF low code tools ourselves as well.. Just want to hear from the community if they are looking for specific features / functions for the library so we could prioritize correctly.

@Charvi We use cfcharts in a limited role (almost exclusively where we are producing static documents, particularly very large documents, for user download). For pretty much everything, along the lines which @Adam Cameron noted, we've steered well clear of using client-side libraries that have come bundled with the CF server for a variety of reasons. The biggest reason was that they were rarely updated and fell way behind their origin, and using those also meant we couldn't use an external CDN for those types of resources to shift traffic off our servers. CFs UI tags that pulled in those libraries were also limiting in terms of what the underlying libraries were capable of and made troubleshooting anything in that embedded Javascript a nightmare. They were also really poorly implemented, to be blunt.

Generally speaking, tools to make report and dashboard creation easier would be welcome. I think the issue is in implementation and separating out server side versus client side issues. Usually, we just have server return data and then handle the report/dashboard visualization on client side. We do have a use case where we'd like the reports or dashboards to be automatically emailed to a group of users, but these days we just email them a link to the dashboard/report. A particular pain point is creating/coding the filters (client side) and then having to create/code the logic for filters server side. This is most applicable to large datasets where processing has to occur server side. GraphQL would help a bit with this but we haven't implemented. Can you tell us a bit a bit more about what you mean by "low code tools" for reporting/dashboarding?

Thanks for all the feedback. Please keep it coming.. @Cage S we are planning to revive CF s report builder with better functionality. It's a low code tool because you can define queried data and placement of that data into a report through the builder. Idea is to also add dashboarding also into it. @rstewart yes we have had use cases come up where reports involving charts need to be exported and sent via email but as you rightly said this can alternatively be done via dashboarding tools as well.

Like other speakers here, I simply don't use CF's client-side stuff. My experience over the years has been that it's flaky, out of date, and poorly supported.

Charvi, same story here as others. We no longer actively develop using CFchart. We still have a few sites using it but have been slowly replacing it as updates are made with clientside charting tools like charts.js. We use CFspreadsheet a lot so I'm interested in the discussions around this. We appreciate your willingness to interact with us to get input on these tools. If possible to continue the discussion around these tools in Slack instead of in email, that would be preferred.

I remember when the CF UI stuff all got added -- I was working at Macromedia back then and went "on tour" to talk at conferences and user groups, promoting the UI tags "because I wasn't a frontend guy"... ...I look back with a certain amount of shame on that tour and those talks: I quickly soured on using them for the reasons folks have mentioned here -- poorly implemented, poorly documented, tied to outdated UI frameworks. All of the client-side UI stuff in CF should be marked deprecated and strongly discouraged. It was always a bad idea to integrate into a slow-moving server product (especially in a way that made end-user upgrades of the UI stuff nearly impossible). I can understand looking at chart generation in the context of reporting and dashboarding but please make it easy for people to upgrade the frontend libraries, or switch to other UI libraries, instead of tying it all into the backend. Provide examples and documentation and "templates" for building rich UIs on top of a data-centric API-based CF backend -- don't bake the UI stuff into the server!

Add 1000 votes from me to stay far away from client side additions to CF. The only CF server I've ever had that was compromised was thanks to CF's outdated version of fckeditor. I'm sure there's plenty of us here that remember that fun period.

One thing to consider here is that the bods on the CF Dev Team have, traditionally, not been that familiar with web development (this comes from talking with them a lot across various pre-release programmes, and technical forums for 20yrs+), which is bad enough when it comes to implementing a server-side web-oriented language, but really ill-conceived when it comes to working with actual client-side solutions. It's not their fault, I'm sure it's never been their choice - it'll be someone making bad platform/language decisions, probably motivated by bean counters not architects - but it is what it is. All of the client side stuff in CFML has always been poor, beta-quality, and largely abandoned after an initial release. It's cynical of Adobe to use this sort of thing as a "gateway drug" to entice low-end users into accidentally using these features. Which - again - is why pursuing this avenue is not something Adobe should be doing if they're actually wanting to do right by their dev community.

I'm really happy to hear about the low code/no code reporting feature and the focus to help enhance cfspreadsheet. Anything to avoid using POI via Java is appreciated. On the topic of cfchart, I point you to Adam and Sean's nicely worded advice. My first reaction is to depreciate it and focus in other core areas and potentially enhancing modern needs such as GraphQL, AI, licensing conducive for instantly scalable containers and serverless, and more. However, I do see the benefit of static document creation. This would also mostly remove the issue with keeping the library up-to-date as well. Therefore, I would consider remolding it to a nicely implemented static chart generator, removing any front-end focus. Back in the day when it was first implemented, JS Chart libraries were not that great and complicated. But these days, you can find nicely done and straightforward JS implementations ranging from open-source to enterprise. There's no need to reinvent the wheel here. As for the cfspreadsheet, I have two opinions on that. Otherwise, I love hearing the focus. 1. Keep the underlying library current. Compatibility with the moving target of MS365 and security are key. This should be easily manageable via the package manager. 2. Consider using the full underlying library and not a limited subset (unsure if it's limited in 2023, but historically has been). This allows for direct Java calls without side-loading the library when cfspreadsheet lacks needed features. If size is an issue for standard usage, provide a full library option in the package manager. 3. Consider somehow letting us call the library's functions directly, that may not be in the cfspreadsheet method, without having to go through Java.