[HN Gopher] Launch HN: Refine (YC S23) - Open-Source Retool alte...
___________________________________________________________________
Launch HN: Refine (YC S23) - Open-Source Retool alternative for
enterprise
Hi HN! We're the co-founders of Refine
(https://github.com/refinedev/refine), an open-source platform for
developing enterprise web applications rapidly. In one year since
launch we have 15K active developers each month, and over 5K
projects in production. Among the 5,000+ projects deployed to
production, we see a lot of admin panels, dashboards, B2B portals
and SAAS interfaces. Check out our online generator at
(https://refine.dev/#playground) to create a custom Refine
application and download it. Before starting refine, we spent five
years as a consultancy company building internal-facing
applications for enterprise clients. We have seen many complex use
cases where the demanded flexibility was much higher than what
existing low-code/no-code solutions provide. Moving away from rigid
architectures and pre-made components that are difficult to
customize, developers tend to start from the scratch. This results
in a significant waste of time and resources. In order to find a
sweet spot between "starting from scratch" and higher level
solutions, we started working on refine. After a couple of
iterations, we came up with a "headless" solution, separating the
UI-layer completely from the rest of the frontend logic. This
allowed us to support multiple UI frameworks and custom designs out
of the box. We understand the importance of frontend developers
working with the stack and tools they love and are familiar with.
So, we have built our project creation wizard that allows
developers to mix and match their technology stack when creating a
project. After 1.5 years of development with the great support of
the open-source community, Refine has become a mature framework
that allows developers to rapidly build enterprise applications and
have 100% control over their projects. While remaining
unobtrusive, Refine still saves a lot of development resources by
eliminating repetitive tasks such as CRUD operations, state
management, routing, authentication, access control, and i18n. It's
also backend-agnostic and works with any APIs or services. The
best way to start Refine development is visiting our extensive
documentation at (https://refine.dev/docs/). Here, you can also
find tutorials and real-life examples to use as a starting point
for your use case. We had one successful Show HN earlier this year
(https://news.ycombinator.com/item?id=34515128), and have since had
several major releases and added many more features. Recently,
we've released our enterprise edition featuring deployments, built-
in security, backend integrations and auto-generated UI's. By
expanding Refine's capabilities beyond the frontend, the enterprise
edition offers a complete solution for the internal tooling
requirements of larger organizations. To get more information,
please see our pricing page: https://refine.dev/pricing/. If you
have any questions, ideas or suggestions please share them with us.
The team will be here all day to answer. We look forward to all of
your comments!
Author : civan
Score : 164 points
Date : 2023-08-09 16:11 UTC (6 hours ago)
| annexrichmond wrote:
| One suggestion, as someone who is an Infra engineer and doesn't
| know frontend too well anymore, the first step in the demo asks
| me to "Select your React platform"
|
| I don't know what that means, and what the implication of
| choosing between Vite, Remix, or Next.js -- it's meaningless to
| me.
| kika wrote:
| ha-ha, brother, I feel you. Infra engineer (VP last position)
| and built an app with Refine. I was exactly in your position
| not a long time ago. I tried to choose "The Best Framework
| Ever" and made a lot of mistakes, and at the end, if you don't
| know frontend go with the flow: React + Next.js. Not because
| they are Best Ever, but because the majority of content online
| is dedicated to these frameworks. StackOverflow, ChatGPT, a
| friend who speaks frontend, etc.
|
| I did some work as part of my consultancy, had data left and
| decided to try my hands at frontend. Oh, boy, I think it was a
| mistake, but it was a lot of fun, will do again.
| https://cloudprice.io
| omeraplak wrote:
| The deceptive part of these types of frameworks is this: on
| the first day, you think it will solve all your problems. On
| the second day, you're happy, thinking about how much you've
| sped up because you chose this framework for your project. On
| the third day, you have a custom need, and you research how
| to do it within that framework. On the fourth day, you hack
| the framework to make it flexible. On the fifth day, you say,
| 'Why didn't I start from scratch myself?'
|
| Our goal and motivation in developing refine is to ensure
| that the developer continues to feel the way they felt on the
| first day, even on the day they finish the project and begin
| to maintain it.
| remich wrote:
| And on the sixth day you have uncontrollable flashbacks to
| the days of using jquery to manage your application state
| as a singleton in the global scope and you die a bit inside
| ;).
| kika wrote:
| why no one came up with the idea of reactive jquery i
| don't know. or, may be someone did?
| kika wrote:
| literally this. but to the benefit of refine.dev i should
| say that you made the framework extremely easily hackable,
| at least where lame me wanted to hack it. your data backend
| didn't work with my rest api, i've asked on discord and
| someone said: hey, it's actually in the docs, you just copy
| our default implementation into your project, import it,
| make sure it works as before and then hack it as your own
| code. a productized hack, i'd say.
| omeraplak wrote:
| If I understand correctly, using 'swizzle' to customize
| the data provider is not a hack for refine, but an
| expected behavior. But I'm curious about the
| conversation; could you possibly share the link?
| kika wrote:
| the ease looks like a hack, since it's documented it's
| not a "hack as in workaround". in my vocabulary "hack" is
| a compliment, not a derogative. i grew up on jargon file.
| hiatus wrote:
| I tried to use the site you mentioned at the end of your
| post, but when I tried to add an ec2 instance (searching for
| ec2 resource) I got a 500 error "Error talking to backend
| server: 500".
| kika wrote:
| hm, indeed. thanks! interesting, i need to investigate. i
| just redeployed the same code to the cloudflare worker and
| it worked.
| omeraplak wrote:
| Oops, you're absolutely right. The frontend ecosystem is quite
| complex, and the entry barrier for engineers working in other
| roles is getting a little higher every day. Perhaps by default,
| Vite should be used, and Remix or Next.js alternatives should
| be shown for advanced frontend developers. Thank you so much;
| we will definitely improve this area.
| sdesol wrote:
| Something else people may want to consider is the community
| health. Vite, Remix and Next.js are all extremely healthy,
| but Next.js is currently in a league of its own. You can see
| the community information for all three at:
|
| https://devboard.gitsense.com/vitejs/vite
|
| https://devboard.gitsense.com/remix-run/remix
|
| https://devboard.gitsense.com/vercel/next.js
|
| The only other project that I've seen with greater engagement
| than next.js on GitHub is Microsoft's vscode.
|
| Full Disclosure: This is my tool.
| drewbitt wrote:
| I encountered several challenges with Refine v3 but it looks
| improved in v4 with the detached router and improved
| documentation, which I found often lacking. This still isn't as
| native as implementing all these features on your own though, you
| pretty much access everything through Refine-specific hooks and
| providers, so there is a learning curve. It's flexibility
| centric.
| omeraplak wrote:
| The foundation of our motivation to create v4 was community
| feedback. Thank you so much for providing us the opportunity to
| improve ourselves!
| zoogeny wrote:
| I am a bit confused by these tools. Can someone analogize what
| they are doing here? It somehow reminds me of the Django admin
| capabilities but expanded to any Typescript base technologies?
|
| I have trouble wrapping my head around the use case for this. Is
| the target market existing businesses that already have APIs
| (probably as REST services), maybe some databases and they just
| want to quickly wire up some UI to it? It seems a bit heavy
| handed for writing an entire application.
|
| I can imagine maybe a medium sized business where the data
| science, sales, marketing, customer service etc. teams want some
| access to the production system data in a format other than
| Tableau or Microsoft BI. And perhaps their engineering team is
| entirely focused on product development or operations and so no
| significant resources can be allocated. I guess this might allow
| more junior or jack-of-all-trades engineers to whip up basic
| admin features?
|
| To be honest, even in small startups I've worked at, cranking out
| admin dashboards using React was just so trivial that I can't
| imagine paying to make it slightly easier. And looking at their
| code examples, it doesn't seem all that more simple. I suppose
| there maybe some goldilocks zone between startups that just crank
| that kind of stuff out and huge enterprises where entire teams
| exist to manage internal tools. In that zone perhaps having these
| kinds of platforms can expedite internal tooling creation.
| civan wrote:
| I believe this is an highly productive discussion, and the
| question narrows down to "which tool is a better match for a
| specific use-case?"
|
| The domain of internal-facing applications is quite diverse.
| One use-case can be a single page internal tool, triggering a
| small script. On the other extreme, organizations build
| SAAS/B2B interfaces with 10+ pages/resources maintained by
| dedicated development teams.
|
| Need to deploy atomic internal tools where technical and non-
| technical roles collaborate? Retool, Superblocks, Appsmith,
| Tooljet or Budibase are perfect solutions. Turning
| scripts/workflows to basic UI's with integrated security and
| observability? You can choose with Windmill, Airplane or Onu.
| You don't want any overhead or learning curve for your lean
| project? Start from scratch and build with the great tools
| React community offers.
|
| Refine becomes a better option for complex cases and higher
| customization requirements. You can give it a try if * You have
| to implement a custom design / design system, * You want to be
| able to customize your stack instead of locking in a black-box
| architecture. * You a need robust architecture for your long-
| lasting project proven by thousands of community members.
| molsongolden wrote:
| Cranking out an admin dashboard in react then also means
| supporting an admin dashboard. The dev is now on the hook for
| user issues, additional feature requests, hey can you just add
| this other field, etc... The dev is interrupted and distracted
| from other work while the other internal team is slowed down
| and blocked waiting for the dev to clear their tickets.
|
| If you have semi-technical users (can muddle through generating
| SQL using stackoverflow) then unleashing them on a read-only DB
| copy with an app builder can be better for everyone involved.
|
| Something like: "Hey I saw your ticket requesting a 'user
| address' field in the dashboard, do you want the mailing
| address or billing address? Lmk then I can probably add this
| today and it'll go live in the next deploy" -> user instead
| adds the field on their own in < 5min
|
| Lots of additional use cases for other db interactions too
| where "let's just spin up an internal admin panel in the app"
| can turn into days or weeks of getting input and now the design
| needs to be thought about and more stakeholders consulted vs.
| absolute basic functionality being stood up in Retool in a
| couple of hours. It's sort of similar to presenting a wireframe
| instead of high-fidelity mock-ups
| zoogeny wrote:
| My first point, which I elaborated on in another reply to my
| comment, is that this makes sense for tools that are
| completely no-code. Refine brags about being developer first.
| Their example on github is a 75 line React-ish script. So,
| someone is writing, testing, deploying code. If that isn't
| your dev team, then who is managing that process and
| supporting it when someone inevitably borks it?
|
| My second point is that even no-code tools tend to require
| developer support sooner or later. What I've noticed for
| admin tooling is that it often works best when it is driven
| by the product team. For example, customer support requests
| comes in which requires devs to stop working, investigate the
| issue, manually fix up data where necessary, etc. Devs hate
| doing this. Give the dev the ability to add the functionality
| to the admin and they often will, just to make the support
| requests go away. If you take away the admin from the product
| team then there is more friction in this path.
|
| I will admit however, that the quality of life improvements
| demanded by the support teams often go un-attended. But I
| don't see how Refine will help this go away if it requires
| someone familiar with next.js/React, Ant/MaterialUI, etc. to
| make changes.
| molsongolden wrote:
| Ah, I hadn't tried the Refine demo and was going totally
| off of past Retool experiences where creating or modifying
| an app can mean just picking a UI component and adding SQL.
|
| Refine does appear to require developer build-out and is
| more of quickstart framework.
| smt88 wrote:
| > _To be honest, even in small startups I 've worked at,
| cranking out admin dashboards using React was just so trivial
| that I can't imagine paying to make it slightly easier._
|
| I haven't tried Refine, but with Retool, we had non-developers
| able to build themselves functional admin tools in literally
| minutes.
|
| Writing new code, regardless of how great the React components
| are, just doesn't come close. I can do things with Retool in
| 2-3 hours that used to take a week or more of a senior React
| dev's time. It's at least one order of magnitude of difference,
| maybe more.
| zoogeny wrote:
| If this was a no-code solution I would agree. But the
| developers themselves are in this thread saying things like:
| "One of the key differences is our code-first preference over
| no-code, which distinguish Refine from the drag-drop style
| workflows of Retool, Appsmith, Tooljet, Budibase etc." Their
| github README has a short 75 line snippet that shows the
| React-ish code one needs to implement a basic dashboard for a
| generic REST service. One of the top comments was from an
| operations guy asking: "Why do I have to choose between
| next.js and Remix?" Clearly they are targeting this towards
| development teams to lessen their burden and not directly at
| support teams to roll their own. Choosing between next.js vs.
| Remix only makes sense to a developer.
|
| As for "2-3 hours" in no-code vs. "1 week" for a developer, I
| might challenge that. In many cases if a support team (sales,
| customer service, marketing, etc.) asked a product team to
| build something custom for them then they are going to quote
| product development timelines. However, Most places where
| I've worked where admin tooling was expected and high-quality
| the admin features were part of the product feature
| development. In general, most functionality would be added in
| some small part of the feature dev time. For example, a 2
| week sprint for a new product feature might include 1 day of
| adding functionality related to that feature to the admin.
| That is to say, your 1 week quote is almost definitely not
| the time it would take to add the features but a block of
| time the product team is quoting to make you go away. That is
| an org problem, not a technology problem. With Refine, I
| don't think you will bypass this problem since you will need
| someone capable of using at least React and whatever stack
| you configure the tool with.
| detinho wrote:
| I worked at a startup that had many internal tools for solving
| small problems using Retool. One frontend guy even added a
| "diff" component so we could compare json payloads and manually
| edit them.
|
| I have to admit that it's not the best of the worlds, but for
| small, focused internal interfaces that call some APIs, it can
| serve well.
|
| Don't know about this new tool, but talking of retool itself, I
| also don't see it being used for a full fledged customer facing
| application.
| debarshri wrote:
| Retool and others are internal application platforms. The
| concept exists since the dawn on computer. SAP, IBMs of the
| world always had one offering like this.
|
| You always need an internal platform may be for seeing the
| order status of the shipped product or some customer data
| etc. The consumer of the tool is a customer service agent or
| an internal employee etc. These tools does not have to be
| perfect , they have to be functional.
|
| It has always been a huge market as it saves ton of money for
| an org. These days as building UI and APIs have become
| democratized, the market for internal applications platform
| have become very competitive.
| rubenfiszel wrote:
| I see windmill mentioned a few times (founder here). I think we
| are both anchoring our tools around "Retool for enterprise"
| because Retool is known and it give a quick overview of the
| domain we are in: Internal tools, but the audience and pain
| solved by refine and windmill are likely to be quite different.
| Windmill caters towards software engineers that want to write
| powerful backend logic in typescript/python/bash/go, long running
| jobs and complex workflows for internal use (we compete there
| with temporal, airflow, airplane), and share them with the rest
| of their orgs with all permissions handled for them, ability to
| scale on large clusters, and observability baked in (full history
| of all executions, including args, logs, and result) AND in
| addition have a low-code dashboard builder similar to retool
| because webhooks, schedules and automatically generated UI from
| scripts are not always sufficient.
|
| Refine looks more like a headless retool for software engineers
| that are comfortable with frontend frameworks but want an
| opinionated stack that is tailored toward internal uses and do
| not want to deal with the rest of the boilerplate, user
| management, and connection/management of databases etc. I could
| see myself preferring refine for some use-cases and would
| probably recommend it if you are comfortable with writing
| frontend and the logic is limited to CRUD. So I wish them good
| luck and I am happy to see such diversity in the open-source
| space!
| ayewo wrote:
| Congrats on the launch!
|
| How does your product compare to Retool and other products in the
| space including the OSS ones (Appsmith, Windmill, Tooljet etc)?
| hn_throwaway_99 wrote:
| Will also throw in react-admin there. React-admin is not the
| same space per se (it's basically a react framework, not a
| low/no code tool), but if I built an internal admin app in
| react-admin, what would you say the pros/cons are to moving to
| Refine?
| omeraplak wrote:
| refine's headless architecture offers developers the
| flexibility to implement their design using any UI framework
| to their apps. It also comes with built-in UI integrations
| for popular libraries like Material UI, Ant Design, Chakra
| UI, and Mantine.
|
| With react-admin, you have no choice other than using
| Material UI for your app. refine's provides nearly all the
| features of react-admin enterprise provides as open-source.
|
| Since refine's architecture is headless, router logic is
| completely detached from the business logic and UI layer. So
| you can use refine with React Router, NextJS, Remix, or any
| other framework may pop-up as long as it's React based. With
| react-admin, you can only use react-router and it doesn't
| have a real SSR support, while with refine, you can use SSR
| frameworks like NextJS and Remix without being limited.
| civan wrote:
| At Refine, we try to take a fresh approach to a space with very
| strong existing players, as you mentioned. Our philosophy is
| keeping the developer-centric focus and provide the best
| experience possible to make boring enterprise CRUD apps fun to
| build.
|
| One of the key differences is our code-first preference over
| no-code, which distinguish Refine from the drag-drop style
| workflows of Retool, Appsmith, Tooljet, Budibase etc.
|
| Instead of offering a fixed set of pre-made components, Refine
| outputs a real React project with collections of helper hooks
| and providers. The "headless" architecture enables developers
| to integrate any preferred UI framework or custom design,
| thereby maintaining the highest level of customization and
| styling options.
|
| This level of flexibility fits use-cases like complex admin
| panels, SAAS interfaces and B2B portals rather then single-page
| internal tools which require little or no customizations.
| foxbee wrote:
| Congratulations and welcome to the open source low code club:
|
| Budibase https://github.com/Budibase/budibase
|
| Appsmith https://github.com/appsmithorg
|
| Tooljet https://github.com/ToolJet
| gervwyk wrote:
| Also add Lowdefy onto the list
| https://github.com/lowdefy/lowdefy
|
| co-founder here :)
| omeraplak wrote:
| Here's what sets Refine apart: we're all about getting hands-on
| with the code, rather than relying solely on drag-and-drop like
| some other tools do, such as Retool, Appsmith, Tooljet,
| Budibase, and others. Instead of just giving you a set of pre-
| made building blocks, Refine goes the extra mile and creates a
| complete React project for you. This project comes packed with
| useful hooks and providers that make your work smoother.
|
| We also have this 'headless' feature that lets developers
| seamlessly blend in their favorite UI framework or their own
| custom designs without any hassle. This flexibility is
| particularly great for things like complex admin panels, SAAS
| interfaces, and B2B portals. On the other hand, if you're
| working on simpler tools for internal use - you know, the ones
| that don't need a lot of tweaking - Refine might offer more
| complexity than necessary.
| verdverm wrote:
| low-code doesn't necessarily mean drag-n-drop, though that is
| typically the association in people's minds
|
| To us, low-code is really about creating simpler, or higher
| up the logical stack, abstractions, and then generating the
| implementation.
|
| Our take is not so far off from yours, where we take a code
| first approach. Users declaratively define their application
| in CUE and then get most of the code. Rather than providing
| hooks, we let the user write directly in the output code.
| Unlike Refine, we enable our tool to continue to aid the
| developer beyond the initial scaffold phase, allowing things
| like the data model to update and the user gets new database
| migrations to be auto-generated and applied. We also make it
| really easy for anyone to create and share these application
| blueprints or generators (as we call them).
|
| In this way, the user can select any mix of technology and
| make starterkits or addons for any application, not just
| webapps. For example we have users (ops team) injecting and
| maintaining CI & k8s files into their service fleets (dev
| team). This is a case where we see low-code, as a term, more
| generally.
|
| https://github.com/hofstadter-io/hof
| frankgrecojr wrote:
| Superblocks https://www.superblocks.com/
| KnlnKS wrote:
| I don't think Superblocks is open source.
| fakedang wrote:
| I once tried a Refine tutorial made by the Refine team, hosted on
| their website, when it was suggested as an alternative dashboard
| maker to Retool. I ended up being confused even more, so I went
| back to Retool.
|
| I'm a noob. Retool can be used by a noob. Your tool can't, so
| it's not a Retool. That's just the bitter truth.
| bovermyer wrote:
| So could we use this with DynamoDB?
| omeraplak wrote:
| Hey, with our open-core, you can connect to any data source as
| long as it provides a Public API. In our Enterprise edition,
| however, we support Direct Database connections (PostgreSQL,
| DynamoDB, Oracle DB) and other integrations that cannot be used
| client-side (such as Salesforce, Slack, Stripe, etc.)
| aaur0 wrote:
| How is it different from https://github.com/ToolJet/ToolJet ?
| drewbitt wrote:
| Refine is not low/no code like ToolJet or Windmill. It's still
| a framework that encapsulates a lot of the workflow, API
| clients, DBs, auth etc though
| GGO wrote:
| It is not AGPL licensed. Refine is MIT licensed and can be used
| over network without open sourcing your own code
| codegeek wrote:
| "Retool for Enterprise"
|
| I assume you have no ties to Retool but using it to explain your
| product ? Sounded like it is a product offered by Retool so you
| might want to rethink that.
| mrcwinn wrote:
| Agreed, really bizarre. Confusing because most people have
| never heard of Retool. Potentially misleading because to some
| it implies either a relationship or a very icky gimmick.
| dang wrote:
| Sorry, that's partly my fault - I've replaced "open-source
| Retool for enterprise" with a more generic phrase now. Is it
| better?
| codegeek wrote:
| No worries. Looks good.
| dang wrote:
| Changed again by founders' request. Hopefully still clearer
| than the original!
| [deleted]
| ck_one wrote:
| Does your Auth solution support Server Components from NextJS?
| drewbitt wrote:
| Yes https://refine.dev/docs/examples/next-js/NextAuth-js/
| lovasoa wrote:
| There is a lot of activity in this space, and I think it's a good
| thing.
|
| Other very similar but less code-heavy solutions include
| appsmith, tooljet, or budibase.
|
| In the same spirit, but SQL-only instead of based on javascript,
| I am currently working on https://sql.ophir.dev . It also allows
| building entire data-centric applications and internal tools very
| quickly, but without having to think about things like "remix",
| "vite", or "next.js", which sound like chinese to most non-
| developers.
| remich wrote:
| Congrats on the launch. I used Refine a couple of months ago to
| spin up an interview exercise for a SDET position. Working with
| the tool was admittedly a bit bumpy due to the somewhat sparse
| documentation (for portions), but I was pleased with the overall
| experience and felt that it allowed me to do in a matter of days
| what may have taken me a week or two in the past.
| codegladiator wrote:
| Have you checked out windmill by rubin ?
|
| edit: link https://github.com/windmill-labs/windmill
| Bjorkbat wrote:
| Incidentally I was about to comment on how peculiar it is that
| there are two open-source Retool alternatives backed by Y
| Combinator.
|
| I know, I know, they're covering their bases, but nonetheless
| find it if only slightly amusing.
|
| Piss-off a VC and they might back your competition. Get on
| their good graces and they'll give you both money and wait to
| see who comes out on top.
| kfk wrote:
| Coming from Enterprise and having used Retool ~3 years, I am
| also buffled... low code biz apps is one of those product
| categories that seems good initally, especially if you never
| worked for a Corporation, but it is really not. These tools
| normally don't do governance, testing, security, users
| management, that well, which puts them in direct competition
| with MS Access. If you think MS Access is old and not web
| based, just use it's evolution: MS Power Apps. Can you
| compete in this area? Sure, but at 100$ per seat prices,
| about 3-5 times less these low code tools demand. By the way,
| I have been quite pleased with Flask Appbuilder, which has a
| clean approach to crud apps, has good governance, and it is
| truly open source.
| ezekg wrote:
| This looks cool. The pricing page says the enterprise edition is
| open source, but I can't find it anywhere. Am I not looking in
| the right spot?
| eagleinparadise wrote:
| Do you all support TRPC?
| nodesocket wrote:
| When I go to the win95 admin portal demo my entire monitor starts
| to flicker (almost with the refresh rate). Is this just brain
| playing tricks?
|
| https://win95.refine.dev/
| omeraplak wrote:
| Oops, we haven't heard of this issue before. We're looking into
| it. Thank you
| samspenc wrote:
| Ha, thanks for sharing this, I played with it and it was a nice
| fun demo, glad the Refine team had a sense of fun while putting
| together working demos :)
| majestic5762 wrote:
| Why do people keep comparing refine with nocode tools like
| windmill or tooljet? Refine just scaffolds your codebase, gives
| you a good start and has some really cool hooks for common
| operations like auth / data management / tables etc. I use it for
| my SaaS and it's great (though they never replied to any of the
| enquires i made for enterprise). Once you scaffold the project,
| then you're on your own.
| gervwyk wrote:
| It's something like https://www.airplane.dev/ a closer
| alternative to Refine? Or how does it compare?
| erenererkalkan wrote:
| You've captured Refine's purpose perfectly - it's all about
| scaffolding your codebase and providing handy hooks for tasks
| like auth and data management. We're thrilled to hear that it's
| been a great fit for your SaaS needs.
|
| We sincerely appreciate your understanding. While we regret any
| previous oversight in responding to your enterprise inquiries,
| we're actively addressing all incoming applications now. Your
| interest matters a lot to us, and we're working to ensure a
| smoother experience.
| lovasoa wrote:
| > Why do people keep comparing refine with nocode tools like
| windmill or tooljet?
|
| Because they market it like that. Their tagline is "Open-source
| Retool for Enterprise", and retool is a nocode (or low-code)
| tool.
| Zaheer wrote:
| This is pretty cool. I noticed in the flow I could choose which
| technologies to use. That's interesting because ReTool is fully
| hosted and abstracts that away. I could see this also being used
| to bootstrap regular sites at some point.
| omeraplak wrote:
| Thank you so much for your comment. We believe that the most
| valuable aspect is allowing developers to work in their own
| environment with the tools and integrations they prefer. We're
| very happy that we've been able to reflect this.
___________________________________________________________________
(page generated 2023-08-09 23:00 UTC)