3 ms·

> I think the fact it maintains the "backend/frontend" separation makes it an awkward product solution imo. When we were thinking about the scope for Dark, we

> I think the fact it maintains the "backend/frontend" separation makes it an awkward product solution imo. 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.

carlosdp 7y ago
Sure I can see that logic. 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.
- btown 7y ago
  Think instead about a frontend or app developer who wants a simple backend that Just Works and can talk to the outside world painlessly (and there are tons of cases where something like Firebase wouldn't suffice). They're not worried about closed-source or lock-in because that's simply not going to move the needle on their project's success at that stage. It could be huge for that market.
  - carlosdp 7y ago
    Do you need a brand new language to solve that problem though? That sounds like something solved by a FaaS platform that exposes a database and other common primitives out of the box, of which plenty are popping up all over the place. If we're talking about a front-end dev, they're probably using React, in ES/Typescript. Any backend product targeting these devs would be nuts to not start by offering a JS environment, I would think. Hence why every FaaS thus far starts with a Node env.
- pbiggar 7y ago
  > willing to sacrifice the ecosystem you get from open-source/widely adopted languages/frameworks for a marginal amount of convenience over something like Netlify Obviously, no one is going to leave something that's good for something that's slightly better with a ton of downsides. So either: 1) Dark is a lot better, like way way way better than what's come before, or 2) it's not, and no-one will use Dark. We can probably agree that one of these two are true, right?
  - karmakaze 7y ago
    No single evaluation covers all users. We can see that the demand for software development is high and is especially high for backend. Anything that offers a safe, easy way to develop/deploy backends is a plus whether opensource or proprietary. Don't lock yourself into not getting locked as it goes.
  - tluyben2 7y ago
    If 1) is true people might still not use it unless open source. Unthinkable in the 90s, now all companies (big and small) I work with demand open source languages and frameworks, besides for embedded work.
eternalny1 7y ago
> we briefly thought about trying to remove all the complexity for frontend too Well, I think this whole idea is wrong, but at least you quit while you were ahead with that one.

carlosdp 7y ago

Sure I can see that logic. 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.

btown 7y ago
Think instead about a frontend or app developer who wants a simple backend that Just Works and can talk to the outside world painlessly (and there are tons of cases where something like Firebase wouldn't suffice). They're not worried about closed-source or lock-in because that's simply not going to move the needle on their project's success at that stage. It could be huge for that market.
- carlosdp 7y ago
  Do you need a brand new language to solve that problem though? That sounds like something solved by a FaaS platform that exposes a database and other common primitives out of the box, of which plenty are popping up all over the place. If we're talking about a front-end dev, they're probably using React, in ES/Typescript. Any backend product targeting these devs would be nuts to not start by offering a JS environment, I would think. Hence why every FaaS thus far starts with a Node env.
pbiggar 7y ago
> willing to sacrifice the ecosystem you get from open-source/widely adopted languages/frameworks for a marginal amount of convenience over something like Netlify Obviously, no one is going to leave something that's good for something that's slightly better with a ton of downsides. So either: 1) Dark is a lot better, like way way way better than what's come before, or 2) it's not, and no-one will use Dark. We can probably agree that one of these two are true, right?
- karmakaze 7y ago
  No single evaluation covers all users. We can see that the demand for software development is high and is especially high for backend. Anything that offers a safe, easy way to develop/deploy backends is a plus whether opensource or proprietary. Don't lock yourself into not getting locked as it goes.
- tluyben2 7y ago
  If 1) is true people might still not use it unless open source. Unthinkable in the 90s, now all companies (big and small) I work with demand open source languages and frameworks, besides for embedded work.

eternalny1 7y ago

> we briefly thought about trying to remove all the complexity for frontend too Well, I think this whole idea is wrong, but at least you quit while you were ahead with that one.