I find Glide quite interesting since I feel like it’s smack dab in the middle of no-code & dev-tool.
In terms of technicality, where do you all think Glide sits?
I would say between AirTable and OutSystems.
What do you think @Darren_Murphy?
2 Likes
I think I generally agree?
I think the abstraction of resources is putting me more on the no-code side of things I think. If Glide had robust resources and event handlers I think it would be a bit more dev friendly.
I guess I see there being two theses - One side of the spectrum is about enabling less technical folks to make apps, and one side is about expediting development speed. I think since there isn’t self-hosted nor a robust external resource layer it puts me more towards the no code side.
1 Like
Knowing that you can still use ai component to make custom code.
1 Like
Yea I’m very much pro the AI component. Personally I think the platform that combines the AI prompting and the low-code building blocks the best will be the winner. I think Glide has a chance with that AI component.
2 Likes
Glide sits between no-code and low-code on the spectrum. It’s ideal for non-developers who want to build powerful apps visually, while also offering enough flexibility for developers to extend functionality. It simplifies app creation without needing to write full code, bridging the gap between design and development efficiently.
Late to contributing here.
I think I would put Glide deep inside “Non-technical” territory. If one uses 99% of Glide native capabilities, then one never sees a line of code or even needs to type an equal sign to write an Excel formula. I would say that Glide, when it comes to writing any type of syntax, is way less technical than Excel or Google Sheets. Much less. Data architecture and logic are needed to build on Glide, but I feel this is not what you meant by your Technical ↔︎ Non-technical scale. Data architecture and logic are common sense really, whereas syntax one needs to learn as set of rules.
That being said, there is 1% of Glide native capabilities that do allow a certain level of technicality, such as CSS, HTML, markdown, JSON, webhooks, APIs. I’m not even sure we can consider these technical, but let’s assume they are. Though being familiar with these might greatly enhance the features of an app, I would argue they are not necessary to building a whole array of very functional internal business apps.
I think the custom AI component is a good example. The way I see it, the developer uses natural language to interact with AI and under the hood the custom AI component generates code. Some developers would like the ability to look at the generated code and tweak it themselves, it would be more efficient than having to chat back and forth with the AI, though Glide won’t let them do that. It could, but it won’t. This keeps Glide non-technical.
To take myself as an example, I cannot write a line of CSS or HTML to save my life or that of humanity. But I can build some Glide apps.
So I would put Glide deep in “Non-technical” territory", with a thin tunnel linking to “A tad technical but only if you want to”.
1 Like
Thanks for the really thoughtful response here @nathanaelb!
I think we are on the same page here. Maybe this is a better graphic -
Glide enables less-technical teams to build Google Sheets powered applications. Glide requires you to have a general understanding of good data architecture practices, but not necessarily coding languages .
This means they are more targeted towards non-mission critical use-cases and things that don’t integrate deeply into technical dependancies? Assumption being technical dependencies past Google sheets would require some sort of technical person to assist. Would you agree with that?
2 Likes
The following would be subject to discussion I’m sure:
| Criteria | Traditional code | Glide |
|---|---|---|
| Language syntax | Required | Not required |
| Database architecture | Required | Required |
| Logic | Required | Required |
| UI design | Required | Not required |
| UX design | Required | Required |
| Design maintenance | Required | Not required (managed by Glide) |
| Hosting (domain) | Required | Not required (though recommended) |
| Storage | Required | Not required |
| Infrastructure for usage scaling | Required | Not required (managed by Glide) |
| Scalability ceiling | Very high | Glide-dependent (number of rows, users, storage, etc.) |
| Performance optimization | Manual control | Some limited options |
| General technical maintenance | Higher | Not required (managed by Glide) |
| Authentication feature | Required | Not required (managed by Glide) |
| Security management | Manual implementation | Not required (managed by Glide) |
| Data privacy | Custom implementation | Black box managed by Glide |
| HTML / CSS / Markdown | Required | Optional |
| JavaScript | Required | Optional |
| Webhooks & APIs | Optional | Optional |
| Development time | Longer | Shorter |
| Learning curve | Steeper | Gentler |
| Customization flexibility | High | Limited (though sufficient for Glide’s use case) |
| Version control | Manual (e.g., Git) | Limited (for now) |
| Testing frameworks | Extensive options | Manual testing through preview functionality |
| Cost structure | Development costs + hosting | Subscription-based |
| Integration capabilities | Extensive | Limited but growing. Extensive thanks to optional webhooks and APIs. |
| Offline functionality | Implementable | Limited because “web” applications |
| Backend logic complexity | Unlimited | Constrained to Glide computed columns and built-in logic (though some Glide experts push the limits) |
| Deployment process | Multi-step and somewhat complex | One-click and simple |
| Team collaboration | Requires additional tools | Built-in and limited (for now) |
| Technical debt | Accumulates over time | Less visible but present |
| Ownership/portability | Full ownership | Dependent on Glide (though data can be exported) |
| Community support | Topic and language-specific | Glide’s community forum |
I’m sure more can be added to this list, don’t hesitate to share your thoughts.
2 Likes
wow what a list!
1 Like
The top of my list above “Development time” is why I would be Glide deep inside “Non-technical” territory.
(“Data privacy” has nothing to do with the rest of the top of the table, but it fits nicely next to “Security management”.)