Show HN: Airplane Views – code-first platform for building internal UIs(airplane.dev)
airplane.dev
Show HN: Airplane Views – code-first platform for building internal UIs
https://www.airplane.dev
6 comments
I don't mean to rain on your parade but you have gone the wrong direction. People use low code tools like airplane.dev because they want to rapidly prototype. What you are building appeals to web devs only. You should talk to your customers, there is no shame in copying Retool. Yes your product may not have any more unique selling points but that's okay, the market is big. People want good GUI builders, not more UI DSLs. GUI builders are hard, they are not undifferentiated. But the hard work will pay off, a good GUI builder is great for prototyping.
I'm Ravi, Josh's co-founder at Airplane. Really appreciate the feedback!
I agree that there's a big market for GUI builders for rapid prototyping as you mention. Retool takes a great approach there, and we're very much not trying to copy them. Rapid prototyping likely won't be one of the main use cases for Airplane.
Instead, people are using Airplane to build more durable internal tools (eg admin panels), and for these use cases, we have many early users who prefer our code-based approach because they can version control it, extend it, etc. There's a lot less vendor lock-in than you get with using GUI-based platforms for building internal tools. We're not trying to compete with those platforms; instead, we're aiming to be adopted by a developer who prefers to build internal tools in-house, and sees Airplane as a much faster way of accomplishing that goal.
Thanks for taking a look!
I agree that there's a big market for GUI builders for rapid prototyping as you mention. Retool takes a great approach there, and we're very much not trying to copy them. Rapid prototyping likely won't be one of the main use cases for Airplane.
Instead, people are using Airplane to build more durable internal tools (eg admin panels), and for these use cases, we have many early users who prefer our code-based approach because they can version control it, extend it, etc. There's a lot less vendor lock-in than you get with using GUI-based platforms for building internal tools. We're not trying to compete with those platforms; instead, we're aiming to be adopted by a developer who prefers to build internal tools in-house, and sees Airplane as a much faster way of accomplishing that goal.
Thanks for taking a look!
"Sign up"? "Pricing"? Maybe if I was at a bigger company, I'd feel differently, but this strikes me as something that should simply be an open source library of React components. I don't get how whatever convenience this adds is worth $$. Maybe I am missing a key value prop.
Thanks for the feedback. I'm Josh's co-founder Ravi.
There are several open source React libraries out there for tables, chart components, etc that I'd encourage checking out. But the key other thing that Airplane gives you, above and beyond a component library, is a deep integration with Airplane tasks (Lambda-like functions) that Josh mentioned above. So you can create a Table component where the data is populated by the results of running one of these functions, or a Button that triggers execution of these, etc. It would be hard to provide an OSS version of tasks since a big part of the value is the hosting/execution/etc, and Views primarily makes sense as integrated with that.
At a high level, the purpose of all of this is to save developer time. An admin panel that takes days or weeks to create ideally can be built in hours using Airplane. Using a high-quality component library can speed up that process, but the additional primitives that Airplane provides out of the box ideally should speed it up significantly more.
From a pricing perspective our Free tier is pretty generous and there are several startups using Airplane for free.
Appreciate you taking a look and sharing your thoughts!
There are several open source React libraries out there for tables, chart components, etc that I'd encourage checking out. But the key other thing that Airplane gives you, above and beyond a component library, is a deep integration with Airplane tasks (Lambda-like functions) that Josh mentioned above. So you can create a Table component where the data is populated by the results of running one of these functions, or a Button that triggers execution of these, etc. It would be hard to provide an OSS version of tasks since a big part of the value is the hosting/execution/etc, and Views primarily makes sense as integrated with that.
At a high level, the purpose of all of this is to save developer time. An admin panel that takes days or weeks to create ideally can be built in hours using Airplane. Using a high-quality component library can speed up that process, but the additional primitives that Airplane provides out of the box ideally should speed it up significantly more.
From a pricing perspective our Free tier is pretty generous and there are several startups using Airplane for free.
Appreciate you taking a look and sharing your thoughts!
Thanks, I will consider checking out the free tier and giving it a try!
> “React without the boilerplate”
That’s called Svelte. My team would jump on this if it wasn’t tied to React!
That’s called Svelte. My team would jump on this if it wasn’t tied to React!
With Views, you can build admin dashboards, product usage charts, moderation inboxes, and more with just a few React components on a page. Views pair well with Tasks (our Lambda-like functions service)—you can write Tasks to fetch a list of customers or suspend a user, and hook them up to e.g. a Table or Button:
Internal tools tend to be under-invested yet power core parts of businesses. We want to help tools reach the same level of rigor as production software, and we believe using code is the right approach. Need to re-use some logic? Import it. Need a custom component? Build it yourself. Need to migrate off Airplane to your own system? We hope you don't, but you can refactor and reuse your existing code.
We think there are great low-code/no-code tools out there for building internal tools, but from our experience there have been few truly focused on developers. A lot of tools support e.g. writing JavaScript within a product, but we think being dev-focused goes beyond that:
- The core authoring flow should revolve around code. Views in Airplane are written in TS/JS, and Tasks support TS/JS, Python, Docker image, and shell scripts. You run airplane deploy from a CLI to, well, deploy it to Airplane.
- The tool should fit developer workflows. Develop locally, write tests, open a PR, push to deploy, promote to prod, etc. Someone shouldn't be able to break tools for the support team with a SQL typo.
- Plus, you can see how others have built things, remix examples, and share it back: https://github.com/airplanedev/templates
The challenge is making this easy to learn and use. We think Views will work because the surface area for internal tools is smaller. We can be more opinionated, and a design system is built-in. You can use Layout, Table, Form, and Chart and get 90% of the way there. We've put a lot of effort into our docs (docs.airplane.dev), although we still have ways to go. And we're working on making building easier: you'll soon be able to edit Views in your browser, and things like drag-and-drop builders can be later layered on top.
Views has been in private beta for a few weeks, during which 20+ teams have built and deployed 50+ views in production. We've had several developers new to React tell us it was simple to create Views in Airplane. We'd love for you to give it a go and send us your feedback!