A customer of ours at ToolJet, specializing in service-based offerings, traditionally used Tableau for their analytics needs. They decided to give us a shot and started moving some of their customers over to ToolJet, taking advantage of our Plotly-based chart component for visualizations. While the initial lift to replicate their Tableau setups in ToolJet is non-trivial, the value proposition is turning out to be significantly more compelling. They're now confidently migrating more customers.
They're aware that our platform might hit some snags with the more complex use cases but most of their customers have similar use cases that are less complex.
"The knowledge cut-off date for my training data is up until September 2021. However, I can access real-time information via my browsing tool. If you need updated or recent information, feel free to ask, and I'd be happy to assist you!"
It is a generic connector for OAuth. Since Xero supports OAuth 2.0, it should be a similar process to integrate. Feel free to ping us [hello@tooljet.com] if you run in to any issues.
Speaking as someone who learned how to make websites 20 years ago, target="_blank" is traditionally only for links leading to another, completely different and separate website.
For example, if you have a link going to Google somewhere you might put target="_blank" on it.
Otherwise, its use has always been frowned upon because it breaks the back button (it's a new window/tab!), disrupts context (unless that disruption makes sense, like above), and spams the taskbar/tab bar.
It's a bad practice always since the user can easily choose if he/she wants to open it in new tab by themselv but not the other way. For a user there is zero benefits in this practice
"The user" on a typical website does not know how to do this.
For a user there is the benefit that they will not lose their presence on the website. Many users do not know how to navigate back.
Of course, in times long gone a new window would appear, and the pattern made even more sense than with tabs.
If you would have left out the word "always", I might have agreed that for this particular website and intended audience, it does not make much of a difference.
Founder here, I’m excited to announce that we've just launched the beta version of ToolJet’s Workflow Automation tool!
For those unfamiliar, ToolJet started its journey when we open-sourced ToolJet (https://github.com/ToolJet/ToolJet) here on HackerNews back in June 2021 (https://news.ycombinator.com/item?id=27421408). When we launched ToolJet, we aimed to bridge the gap between developers and non-developers, making it easier for teams to build internal tools swiftly. Our journey began right here on HackerNews, and much of our evolution has been shaped by feedback from many of you. Today, we’re taking a step further with our new Workflow Automation tool.
How it works
1. Connect your data sources: Add any of the pre-existing ~50 data sources like PGSQL, RestAPI, Zendesk, Stripe, Amazon S3 and many more.
2. Create a workflow: Create a new workflow from your ToolJet Dashboard. A workflow is a series of steps which are executed one after the other, and each step is interacting with a datasource by fetching or putting back data.
3. Business logic: Implement your business logic by creating branches based on conditions and by running JavaScript codes.
4. Debugging: You can see the logs by expanding logs panel at the bottom of the workflow builder. It will have all information you need to debug your workflow.
Budibase’s workflow product has been around for a while and we are directly competing with each other. We have our own strengths but would be difficult to say if we or them are better at this stage.
Windmill is a great product too but it is totally pro-code and building workflow with it, one has to write a lot of code compared to ToolJet. Hence, ToolJet would be definitely faster here.
Windmill allows you to write code in any places but we have a hub augmented every day with pre-made integrations so that you do not have to: https://hub.windmill.dev. We also have native support for BigQuery, Snorflake, Mysql, GraphQL, with dedicated editors.
Hence, I fail to see how it would be any faster to build workflows in tooljet than in windmill. I do not have a business license of tooljet so I have not been able to do the comparison. Interested to hear feedbacks on that.
Our workflow engine and UX seems to be a lot more advanced from what I can see because we have been iterating on it for longer. Congrats on the launch though and may the best open-source alternative to Retool win.
I have not tried the product in depth but this comes from your website headline where it says “Turn scripts into .... “. But great to know you have inbuilt integrations now. Best of luck, may the best internal tooling platform wins.
If you do not know the product then maybe instead of saying that X is simpler/faster/better than Y it would be better/fairer to say "I don't know" or "from a look at their landing" ?
haha, not interested. Sometimes it is okay to bow out of an online conversation :)
Retool and ToolJet are building in the same problem space of internal tooling. Primary difference is that ToolJet is open source. And btw, we launched in March 2021.
Open source is nice. I actually find these types of tools useful in testing where you don’t have time to do a full automated suite but you need to compare data between systems
As a non dev, I'm doing every of my front and back with chatgpt code interpreter and it's working fine.
I ask him to create a simulation to test each part of his code and modify until it work.
The issue with low codes tools is that I cannot ask gpt to do stuff for me, and I have the risk that gpt cannot help me as he don't know the tool.
Can’t say for all low code tools but if you consider ToolJet, you can build apps using drag and drop UI builder and doing customisation in UI. You really don’t need GPT once you get a hang on it. Ofcourse, experience can be further improved using GPT but that is not real value as of today. Compared to GPT powered traditional development, ToolJet’s approach is still faster.
IMHO, real value is when you can extend/customise ToolJet using custom code or database queries. And this is where GPT can help. We even have a inbuilt Copilot for these use cases.
Heads up: on your docs page, using Brave on Android 13, if I go to the menu and expand a section, it scrolls, but then if I click on an item, when I go back to the menu it will no longer scroll and I have to use the back button to get back to where I can use the menu again.
ToolJet is a full stack platform for building internal tools where automation is one part of it. We also support creating web applications and have a data store.
While make.com is focussed just on automation but for all kinds of use cases and not focussed on solving internal tooling problems for the companies.
However, process street does look focussed on building software for internal applications but it is more towards no-code spectrum which has its advantages but makes it less customisable. ToolJet, on the other hand is more customisable and developer friendly because of our low-code approach.
Right, we are exploring this as well but don't have a solid plan yet. Since the pricing is custom, we try to provide a plan that works for a specific customer.
They're aware that our platform might hit some snags with the more complex use cases but most of their customers have similar use cases that are less complex.