Show HN: Darklang

When we were thinking about the scope for Dark, we briefly thought about trying to remove all the complexity for frontend too. However, when thinking about how Meteor went, and specifically about how much stuff is going on in the frontend world, we thought it would be simpler to understand if we stopped at the HTTP boundary.

Bear in mind that there are tons of applications that dont have frontends, especially ones that are just APIs.

Currently hosted in GCP, US west.

I'm curious who you see your audience as. If you look at a spectrum across skill level:

* On the far left you'll have those learning: univ students, boot camper's, technical folks in non-eng jobs (think operations-y people who are zapier+spreadsheet wizards).

* In the middle you'll have junior engineers starting their first or second role.

* On the far right, you'll have senior engineers who are looking at factors beyond functionality like architecture, style, performance, etc.

I think the middle is out. These are folks who've made an investment in their education and are looking to apply it. They're looking to earn their stripes and might trade efficiency for that. There's also secondary effects of using the incumbents like membership into a community (I run the SF Django meetup so I see this up and close).

The far right is out because DL is hiding the complexity they're precisely interested in tailoring (or at the very least, having the optionality to in the future). Additionally, they're very fast at the operations you've optimized for (CRUD) so that's not necessarily a barrier for them. They'll be working with boilerplates that are deployment ready (though not instant like y'all - that's pretty cool!). Yes there's some pain here you're solving. Not enough to justify the switching costs, IMO.

I think that leaves you with the beginner crowd. Zooming in further, I'd exclude students since there is no value for them to invest in something they wouldn't get hired for. There's the casual indiehacker / weekend project person. I think this would work fantastically for them because they just want to spin something up as fast as possible. There's also the operations person who does a lot of ducktaping of airtable+zapier+typeform+etc. I know many people who are doing that and when they hit a ceiling, this could be perfect.

I'm arriving to the following conclusion: though you're not a no-code tool, you share the same target audience. Repl.it is a good comparison here.

But how many people are writing APIs and either

1) aren't experienced enough to figure out how to write a Lambda function (using a wrapper FaaS like Netlify), or

2) are experienced and are willing to sacrifice the ecosystem you get from open-source/widely adopted languages/frameworks for a marginal amount of convenience over something like Netlify, where they can use whatever language they already know.

Maybe I don't see it and it's actually a lot of people. But in all my time working on APIs, I've never heard of someone writing an API who wasn't already a decently experienced developer.

Typically the front-end facing solution would come first for them, because why would they build something people like themselves would have trouble figuring out how to use? Which is where most no-code/low-code solutions are targeted for that reason.