Hello my fellow Retool developers!
I would like to solicit feedback from the developer community on where we think Retool should be heading. What are your priorities and needs and wants? I don't mean individual features, we have a forum for that already, a bit broader than that.
I'm almost done formulating mine and will pipe in shortly, but want to get the ball rolling.
Ok here is my initial entry. These are the big things I would like to see done and in this order of priority:
The first thing to work on, which they are doing, is performance improvements. The new render engine is a very good step (can we see that bleed over to the IDE maybe?) The new table component is very fast, hopefully once it reaches and exceed feature parity with the previous one, its performance will remain stellar. Listview is the next one to get a full workover. More coal on this fire!
A close second - Improved and new components like Treeview, Drag List/Grid, Charting, Mapping Context Menus. Add lots more events to all components (beforeUpdate, afterUpdate, onClick, onDblClick - go wild!) I include mobile components in this item. Give us something new or a major update every week.
Next up would be an improved developer IDE. Dockable windows, multi-monitor support, dark mode and so on. Many feature requests have been submitted on this so I will not dwell further.
Last on my list is third party components. A way for third party developers to create first class components. This expands the ecosystem, takes some load off of Retool and increases the richness of the platform. This was one of the most important features that let Visual Basic eat the world.
I know as a company Retool wants a nice long list of features to attract as much attention as possible thus you have been working on Workflows, Retool Database, Embedded and I am sure other very neat things we don't now about yet. Keep that up!
But put 80% of your resources on the CORE product. Quality over Quantity.
Easier/better graphs/dashboard tools. I would love for Retool to win the 80/20 on replacing Tableau, and honestly I don't feel like it's far off.
Remove the need for javascript. I know this is a far fetched wish, but if you want to capture the Data market, all the js fiddling is a major hurdle for adoption. Especially when manipulating data objects, being able to mangle every source with SQL would be fantastic. Python would be a close second in making it easier for most data folks.
Better IDE-ish options for SQL. Automatic linting would be great, at the least.
I'm happy to dive deeper on any of this, if it'd be helpful.
Hi @Doormouse, welcome to the forums and thank you for your input!
When you say:
Blockquote
Especially when manipulating data objects, being able to mangle every source with SQL would be fantastic
Do you mean using SQL to query data from different sources? If yes, you should check out Query JSON with SQL queries (https://docs.retool.com/docs/sql-queries#query-json-with-sql). You can take your results from a Postgres query, your Stripe results and a BigTable result and use standard JOINS to link them with a JSON SQL query. You do need to make sure the source data is transformed into an array of objects, but then you are ready to go! It is one of the most underrated features in Retool.
As to Python, interesting idea... Adding a PyScript query type sounds intriguing.
Brad you've nailed it. 
Welcome to the community Ben!
I hear you from the data-user perspective, and agree that Tableua should die 
but I think the JS is essential and isn't going anywhere for the majority of users. I also agree that JS is scary for non-dev's though... and many new LowCode tools are pushing the need for code further and further away from the user. (think FlutterFlow).
I'm not sure what the resolution would be except to try and create an experience for a different user type (more data/BI focused).
But my take is that your point 2 shouldn't near the top of the wishlist. 
I think Brad has nailed it. And that your points 1 & 3 are valid.
Also, regarding Python, I think the Workflows team might be working on a Python integration. 
. Maybe it'll come across to Web one day
Hi @bradlymathews, thank you for the post. (David here, CEO @ Retool.) I wanted to chime on in this thread to say thank you for all the great feedback. I'm with you 100% on all of it.
Here's what we believe:
Performance is critical. I'm glad we've made a lot of progress with Runtime V2, but there's more work to do. (As you note.) @Alexi and team are working hard on the new Table component, and we're excited to build more and more features into it (while maintaining its incredible performance).
Improved and new components have not been a focus for us thus far, but maybe it should be. I agree it'd be great to ship a new component every week. @emily's team (the app building team) is responsible for this; I will check in with her.
An improved developer experience is the focus for this year. We have some really exciting plans that @maya is working on, and we expect to have some updates to share in the next few months. We are ourselves testing out a much better code editing experience, and expect to ship that by end of this month.
Third party components are something we want to work on, but are not on our roadmap right now. I agree that it would be very powerful, but we want to make sure we can deliver a great experience.
Better graphing and dashboarding is something we want to do, but it's hard to prioritize (since Retool is not meant to be used as a BI tool, haha). I think this would be a fun hackathon project for us!
We want to support Python. It just arrived in Workflows today and we will bring it to web soon.
If anybody has any other feedback, please chime in on this thread! Thank you again @bradlymathews for the initial post. We love hearing feedback from users!
I dont know how feasible this would be - but the ability to create component event Listeners hooks traditionally through Javascript, rather than through the UI options, so we could get much more creating adding events on the fly, etc.
And also, as bradley mentioned MOAR events! give me all the event triggers! Oh, and a password input field for mobile.
Thanks for all the great work - retool is quickly becoming my go-to!
HI there. Yep great list, and agree that stability and performance need to stay at the top of the pile.
I put another post up on this, but...Copilot, or GPT integration. As of a couple of days ago I've started using GPT-4 to develop code fragments; I'm not a pro developer and this is a massive accelerator for creating the little javascript fragments necessary to tie Retool apps together (example below). Given that many users probably have really similar use cases (build an api integration; parse / format json into tables, create CRUD interfaces with validation etc) then an AI assistant with knowledge of the Retool code base and how the components interact could be an absolute game changer, bringing all the benefits of no-code with the flexibility of low-code.
Example
@bradlymathews - I'm loving your list (and the reply from @dvdhsu)...from a technical perspective, I'm not sure I can think to add anything else at the moment, so I'm going broader as requested!
We're new users/devs and excited by the potential of Retool, but frustrated by the licensing model that makes it incredibly difficult for us to justify creating apps to improve the experience of our hundreds and hundreds of client users, who would only ever be really light users. Our sales contact has said "we can probably" sort something, but the ball-park numbers were still way out of our league ;(
So, I'd like to see alternative licensing that would enable this - a user access license would not have application edit permissions, just run permissions. Ideally, it would be a developer license subscription that includes user access licensing, or separate, really low-cost (volume-based?) user access licenses. Perhaps a hybrid model, where the current developer licenses could each include enough (20+?) user access licenses to enable initial deployments/usage, and then extra user access licenses could be purchased separately?
Or if the primary issue is scaling/capacity costs of the cloud service to be able to handle unknown levels of usage, then it could easily be an on-premise only feature that means we would be responsible for capacity and performance?
I know Retool has massive potential for us beyond internal applications, and this seems like an incredibly easy opportunity to exploit as it's presumably almost entirely a commercial decision and would need minimal (but incredibly high value!!) technical change?
TIA
This is a debate that has been happening for a while, inside and outside of Retool. Retool started with a backend focused market: What's an extra $50 per employee when you are already paying them $4-8k per month? One dev can do twice as much in half the time with half the needed skills compared to a say a React developer. Or each department can have its own dev and not need to rely on IT to get around to giving them the productivity tools they need. A sound value proposition.
The UX of a retool app is not really compatible with the expectations of the general public. So I just don't see Retool apps as general web dev replacement (with some exceptions of course.) What it would be great for in this market segment is prototyping. Once you have iterated your app to MVP, getting front/middle/back-ends all in sync, send it off to a designer and React dev to duplicate. Save time and money that way I believe.
The middle ground seems to be in contention: contractors, vendors, clients and such where your 5 person company, which is perfectly happy paying $250/month for your employees, just can't expand that to $5000 for 100 external entities that need occasional use. Public apps is the current solution to the problem but no one thinks it is an adequate one. (But please don't get rid of it as is - it has its uses!)
One idea I just had, that goes against the subscription model that Retool uses and the entire industry has been moving to for a while now (maybe I should say "has now moved to"?) is an old model that still has applicability: a dev license with a low per-seat royalty. Say $5000 gets you one dev and 100 seats outside of the organization in perpetuity for the current major version. $10 per additional seat. $1000 per additional dev. Add a support contract on top of that if you want faster turnaround. Self hosted of course. Seats inside the org retain the current pricing model.
So +1 for me, let's add this to the list and figure to how to get that middle market covered.
HI @dvdhsu, great that you're engaged in this thread. In response to your BI statement - Retool is absolutely our BI tool when what we're managing is real-time operational processes - dashboards, in effect, where we can observe process completion across multiple systems / databases by querying status of objects / data across the process lifecycle. BI tools that rely on a time-delayed transfer to a data warehouse don't cut it, and add unnecessary cost and complexity.
In terms of solution; I agree this should not be core Retool roadmap - maybe a more slightly more structured 'user generated content' forum might go a long way ? Really just an extension of the 'community' show and tell' but with more of a focus on contributors providing working code components that others can utilise. From a BI perspective I'm sure there are users out there who've implemented more fully-featured plotly implementations or similar which might solve 90% of most users' needs with a little creativity.
Interested to know other's thoughts.
I'm probably one of the least technical Retool users, so a third-party component library would be awesome! I know there are quite a lot of requests for new/altered components in this forum so I think opening up to outside developers may be able to take some of the work off the plates of Retool's own engineers and expand the ecosystem more rapidly.
I've particularly noticed a lot of requests for updates/changes to the table component. Personally I would like to see some of the interactivity and field types of Airtable in the way you can interact with tables and databases as an alternative to using forms for CRUD. I may be wrong here, but I figure most people use tables at the core of their apps, so focusing on that as the key feature might help seal the deal for people on the fence about using Retool.
Otherwise I absolutely love Retool. Not only has it helped streamline my processes, but it's helped me learn a bit of coding as a complete novice. So thank you! 
Nice @domjammoo
I have been navigating these "quests" of producing content with GPT-3 for quite some time now, the freedom that a canvas with an immensely wonderful flow like Retool's, including the new connectors with OpenAI are catalyzing factors for any scenario, for sure.
I recorded a simple video with no audio just to illustrate the adjustments with some recursive and consecutive calls with summarized texts and at the end I put a trigger to send an email (I assembled the html in JS). Loom | Free Screen & Video Recording Software | Loom
The creation of texts using the openai connector with gpt-4 in the retool workflow was not very stable with a number above 5 queries using gpt-4, so I opted to change the templates and leave gpt-4 only for classification and analysis of contexts and the other queries I left with the 3.5-turbo, but I confess that 003 (davinci-003) still remains my love.
I missed a documentation talking a little bit about the Whisper parameters, I tried to send an audio without uploading to an S3 and I couldn't, but I'll try in the next days.
Congratulations for the post and the initiative to all the Staff, the current Workflow experience is very good, since the beginning of the Workflow Beta I miss a vertical control on the Div/Tab/Window that displays the execution log (inside WorkFlow), it occupies in some cases more than 50% of the vertical screen space and only disappears when you click again, it would be great to have a control similar to what we have in the internal apps/queries.
Thanks a lot!
Hi @bradlymathews, on the topic of priorities, I'd like to know what the priority is for fixing a longstanding bug, which is the caching for Query Library queries. This bug was reported over 6 months ago (Sept 13, 2022) and still hasn't been fixed.
I share your frustration that it can take too long to fix bugs. I recommend adding an "Any progress with this?" kind of post the original thread and you will usually get a response back - it may not be the one you want, but it does apply some pressure and can get priorities re-shifted by being a squeaky wheel.
I don't want this thread to focus very specific bugs like this, but let's add a +1 for speeding up bug fixes!
I have to say I'm very impressed to see @dvdhsu in this thread. I heard about retool from your mouth directly while listening to a Podcast a while back (cant for the life of me remember which one). I didn't expect to see you still involved in the community at this point considering how big retool has gotten.
@bradlymathews as usual you nailed it with your list. Don't do such a good job so some of us can contribute a bit more! Haha.
@nickwarren we have had similar conversations with Retool regarding pricing, and I know they are discussing some stuff internally based on our last meeting with them. We are a small shop and pricing was a bit of a blocker early on. Now that we have developed all of our internal systems into retool its far less of a blocker. I agree with bradly 50/mo is well worth it (for us at least) having streamlined all of our business processes into one app. We have removed the need for at least one employee if not more.
That being said I would love to see them pivot slightly to allow instances the ability to create a SaaS model and resell to others. Sure we can always take our app to a react developer and have them build it for us, but its ever-changing the more we use it. We decide we want something to work differently and can rebuild it in anywhere from a few minutes to a few days. I love the ability to change/adjust as we grow as a business and as developers. The system we have built is industry specific and all-inclusive and I KNOW others would love to have it... we would love to monetize that fact and have the ability to continuously update it based on user feedback. I feel like we might be a very specific case in that sense but the more I see in the forums the more I'm unsure of that.
+1 for middle market pricing
+1 for speeding up bug fixes
+1 for other languages
+10 for Multi-screen support and/or custom IDE to allow for multi-monitor development
I do feel like these posts end up with a lot of negative feedback so I want to add a few positive notes...
Thank you for Runtime V2 it was a game-changer, appreciate the ability to beta test with you guys on that and everything else. Thank you for paying attention to the community and continuously improving. Thank you for creating such a great product, its helped us immensely, I'm excited to see it progress and grow.
Thanks @barton for the bump on the bug. I'm going to chat to the team and make sure this is resolved in the next few days.
On bugs more generally: we recently instituted a SLA for bugs (our newly hired COO, Mark Schaaf, was adamant we do so). We are getting much better at triaging, prioritizing, and fixing bug reports, and I agree we weren't very good at it before. Hopefully you all should see us resolving bugs much faster going forward!
Pricing feedback: yes, absolutely agreed. We anticipate having something to announce in the next month. 
On more user-generated content: yes, we have many ideas here and are excited to ship some ideas here soon. One is to serialize Retool apps better (instead of YAML, we are working on our own DSL which is much more readable). Then we want to allow people to source control these apps (on Github). Then you could imagine having a "Deploy to Retool" button on all these Retool apps you find on Github.... which would allow you to share the apps. (We will in the future also build an app store directly in Retool.)
Thank you all for the feedback!
I work primarily with small businesses and non-profits to automate and organize their current process flow. Unfortunately, most of these organizations are very "paper-centric" and I find I need a migration path to lead them to electronic document exchange. This means I still depend on exporting "reports" to PDF. I would really like to be able to configure the output to 1. a specific local directory and 2. the ability to customize the name (e.g. use data from components like customer name and date)
