Hacker News Reader

Comment by endisneigh | Hacker News Reader

This is not true, you cannot run your own foundationdb server and use the kv service without reimplementing yourself in fdb

View on HN

This instantly reminded me of Next.js, which is open source but has a special build format for serverless environments.

The 1st party implementation is closed source: 3rd parties start on the back foot trying to implement alternatives and have to keep up with a 1st party that can move in lockstep.

And sure enough, like every other time I see this kind of behavior: Deno was invested in by the CEO of Vercel.

"Javascript is taken over by venture capital" wasn't on my 2023 bingo.

Vercel needs to stop with this bullshit. It is straight up predatory ”open” source. Like a trapper’s cage, there’s a convenient, tasty bait and then it’s too late.

Is it too cynical to say this might be a lesson devs need to learn the hard way?

Right now the JS community has whipped themselves into a frenzy into building on VC backed technology.

- They refuse to acknowledge that the loudest voices in the room are openly sponsored and invested in by the same VCs who own the companies behind said tech

- They see no issue with a lack of diversity in implementations, instead settling for "it's a standard". Of course, defining a standard without a healthy variety of implementations means you end up with standards that don't benefit from a wide range of voices until well after they land (see RSC)

At the end of the day, those two alone are a pretty harsh combo: A VC-backed network effect machine built across multiple brands, and high technical costs to building something that meets the collection of standards.

I don't think anyone but FAANG can really compete with that without also getting VC dollars, thus reinforcing the loop.

You can build a Next.js app and run it on a docker container or regular linux host almost anywhere. Vercel has some nice continuous deployment stuff built-in but I'm not sure how a Next.js app is locked into it at all.

This is often repeated but misguided.

Next.js and Vercel heavily push serverless deployment: 13 reworked the built-in API support to leverage Web Standards, which discarded interop with the a much larger server ecosystem in order to enable better edge support.

Serverless deploys require providers to support the Next.js Build API: https://nextjs.org/docs/pages/building-your-application/depl...

There is no open implementation of this API (unlike Remix for example)

This means projects like Open Next start from 0: https://open-next.js.org/

The end result is significantly fractured support for a headline feature of the framework and a lot of unnecessary pain (https://betterprogramming.pub/beware-of-next-js-on-aws-ampli...) trying to leverage it on any non-Vercel platform.

Yeah on the same note I developed a moderately complex app on Next but I hit a roadblock when I needed background job support, which is not natively supported (or at least at the time wasn't) on Vercel/other Next platforms and so it was never a priority for Next. Pushing serverless so hard also made deployments janky and production bugs weird when you tried to use things not supported by the underlying platform, AWS (don't remember the details now, but Node version was one of those).

Yep, part of why I looked for alternatives and settled on Remix. It's never sat right with me

This sentiment has been repeated in a few comments. But, why can’t the deno deploy implementation be reimplemented, by yourself, by running a foundationDB server with mvSQLite[1]? That shouldn’t require any changes to the code.

[1] https://github.com/losfair/mvsqlite

That is not the same thing, still. Like you said it would be a reimplementation, not the same thing.

Reply on news.ycombinator.com