Comment by tyingq | Hacker News Reader

Comment by tyingq | Hacker News Reader

I've tried a lot of these tools. The trouble is that things go extremely well until you hit a wall. With no way to extend them with something like freeform code, the wall doesn't move.

The best ones, then, tend to be the ones that have been around long enough, or had enough foresight to have covered various corner cases.

The other issue is that most of them have "per user / per month" pricing, which doesn't work for many use cases. Things like, for example, an applicant tracking app. If you use the functionality to a high degree, every job applicant is another end user license.

Two of the better ones: http://quickbase.com & http://ragic.com

Other ones I've seen: http://caspio.com, http://knack.com, http://fusio.com, http://trackvia.com/, http://podio.com, https://www.zoho.com/creator/, http://airtable.com, https://getzenbase.com/, http://www.zenginehq.com/

One of the more promising ones was DabbleDB. Twitter acquihired them and shut the tool down. It had a very smooth UI: https://www.youtube.com/watch?v=MCVj5RZOqwY

My theory is that it is not the existence of a wall that limits these tools - it is the invisibility of the wall. Spreadsheets have a wall too, but it is pretty clear to naive users where it is. These app-in-a-can tools hit the wall suddenly and unpredictably - you need a new UI feature, or the data model can't be generalized, or you can't connect to some silo. Perhaps a better metaphor than a wall would be a mine field.

I've run into all the things you mentioned. Pretty quickly though.

One I hit in many of the tools was lack of a good UI widget for select fields that have lots of choices. Something like a combobox with autocomplete.

Yeah - same story repeated decade after decade. "Build apps without coding" is one of those Siren ideas - it seems so compelling and necessary, yet everyone ends up using much the same design as has failed countless times before. I don't really understand exactly why this is so, but I'm pretty sure we need to figure that out to make progress.

These services are cloud services. They have another wall. Spiked, dark, cruel and ready to collapse on us at a second's notice. A new person getting hired at some critical services cloud company. Excellent suit. New CFO, or COO, or whatever. Nice MBA, economics degree, daddy's really important, he has been executive at some bank for decades, comes in. And something happens.

Maybe he sees pedestrian get shot on the street while he walks to his desk and smiles. Maybe a chair screeches on the floor, reminding him of the screams of some kid five years his junior he was beating up in high school. Maybe he cuts his hand on the edge of his giant mahogany desk and the drop of blood fondly makes him remember the thousands of children whose families he sucked dry, and condemned to abject poverty at his previous bank job, reveling in their inescapable fate. We will never know. An epiphany happens.

Then he proceeds to phone up some lead architect and asks the question "don't we fully control the data that these cloud 'customers' think is theirs" ? He likes the answer so much he fires the lead architect on the spot.

And his eyes twinkle.

I totally agree with you. Most of these tools seems really neat and have seductive examples. Then when you use it for a project you end up needing some kind of customization which they do not accommodate.

I've saved countless hours by doing as you suggested - only using the tools that have matured, where all standard questions are already answered on stackoverflow and common corner cases are covered.

So when I see Google App Maker, my response is "cool, this might be something I can use in a year or two, let's see."

It is possible extensibility will be via Google Apps Script, about as close to "freeform" code one can get in a sandbox. Google have successfully implemented Apps Script in a number of G Suite products so I would be optimistic about seeing it in App Maker for advanced scenarios. Fingers crossed

Many of the tools I mentioned have scripting capabilities, but that doesn't keep you from hitting a wall, because you're scripting in whatever limited context they give you.

Sometimes the wall is the data model, or the construct they give you for navigation, access control, roles, etc.

Something like freeform javascript that executes in the client would help a lot, because you could patch around limitations in many cases.

Creator of App Maker here, though it's been a while since I was on the team.

Smoothing out the transition from on-rails to off was one of the original design goals, so there was arbitrary server and client scripting from pretty early on, and a component model to create widgets. The project as moved from being hosted on App Engine to being hosted on Docs infrastructure, so I'm not sure what the specifics of extensibility are, but I suspect they're pretty good, but more Apps Script oriented. Should be a good solution for heavy Docs users.

My thinking in this space is that you really can have your cake and eat it too with these tools, though it requires a really thought-out design, and that they built-in features use the same extension points that are available to users.

With JavaScript available on the client and server it becomes less of an issue whether you can run code at all, and more of an issue of whether you can run at the right time and intercept the right flows. Especially with Web Components on the client pretty much taking care of components. Providing a standard router on the client and server with similar middleware and handlers, and also middleware/handlers on state changes, you can get close to easy to start with and fully extensible.

Sounds promising. This is why HN is so great. Meaningful insider feedback in the space of an hour. Thanks for that.

The other limiter is less technical. Finding a way to charge per user only for true internal users. That was my other stumbling block...tools that want to charge for everyone that touches a built app in any way whatsoever.

Looks like App Maker already supports JavaScript for both server and client scripting, including bindings to read and write data.

https://developers.google.com/appmaker/scripting/overview

Oh sweet "Server scripts run on Apps Script. They can access databases directly and use Apps Script APIs like calendar, email, and more.".. This could be very interesting

Replying to myself because I found an animated gif that gives a peek into some of the functionality. It does look fairly slick. https://storage.googleapis.com/gweb-uniblog-publish-prod/ori...

Hi - I am a Developer Evangelist at Zoho. I would love to have a chat sometime about what worked and more importantly what didn't for you guys. I really value your opinions at this time, especially since we are building some major changes into the product. Please write to me at <username> at gmail dot com if interested. Cheers!

Reply on news.ycombinator.com