Comment by jkaplan | Hacker News Reader

Comment by jkaplan | Hacker News Reader

Parent Full thread

1. I'm not sure about this premise: "leader of the production-ready frontend-as-a-service space." They def seem like a good fit for some frontends -- but they're certainly not a good fit for ALL frontends generally. (For example, sufficiently small sites should probably just go with static hosting, and sufficiently dynamic web apps still will want a SPA.)

2. At the end of the day, web backends are just a lot more varied and complex than web frontends. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client. And functionally, there's a relatively large set of common things they pretty much all do (routing, serve images, etc.) Therefore, it's relatively simple to build an opinionated framework that can still cover a good number of situations.

By contrast, a "backend" is really a lot of different things (like the four you mention, plus various types of storage and caching), which can use many different languages/technologies, all working together in different ways. It's hard to conceive of a universal "backend" framework that could cover all of that complexity.

3. There are some efforts to do this kind of thing (to some extent). Google's Firebase and AWS Amplify are the two that I think are closest -- they try to give low-configuration generic backend building blocks. (I'm currently using Amplify for a project -- still too early to tell. It also works with Next.js!) There's also platform-as-a-service options like Heroku.

Backend is probably a lot easier than the frontend, which is why you can see service like hasura and supabase. Backend is a highly patternized work, which is why it can be low to no code, whereas front end as a service is merely just deployment as a service.

> At the end of the day, web backends are just a lot more varied and complex than web frontends.

> No, they aren't. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client.

First, that's factually untrue; web front-ends can contain a wide array of things beyond those three (WASM, content in formats other than HTML that is read and used by the JS/WASM, etc.)

Second, on a similar level of reductionism, web backends are just bundles of bytes that need to be deployed on servers.

Even completely leaving aside the language/software diversity, the point is that the vast majority of web "frontends" are really just one thing (rendering the UI and responding to inputs) whereas web "backends" are frequently not really one thing (1 or more types of storage, 1 or more types of computation, responding to requests, perhaps event processing and scheduling, etc.)

I did not mean to imply that all, or even most backends are more complex than frontends -- only that the problem space of backends is larger and more varied (for typical web use these days, at least.)

Not sure I agree with your first point. Next can output static sites easily, I've used it for some tiny marketing sites recently and I think its fine for small sites. You get auto routing, and can use react components without any hassle.

And 'sufficiently dynamic web apps still will want a SPA' doesn't make much sense to me because you can just use nextjs in full SPA mode and its just as 'dynamic' as any react app

This is a really strong argument. At the end of the day I think it is possible (with iteration) to get the level of abstraction correct for something approaching some semblance of the universality you refer to.

I really just want a framework that allows me to:

1) Run locally like Next.js's "npm run dev"

2) Do end-to-end unit tests because the framework provides the abstraction layer

3) Deploy to the cloud via push to Github and have it run exactly the same as (1), but do it at scale (deploy to serverless functions, use actual SQS Queues, Eventbridge, etc.)

Of course the core would a developer experience like Vercel, Stripe, etc.

Check out Amplify! I've heard good things and my limited experience is good so far. (Although running locally isn't the best, unfortunately... but that's always going to be an issue the more you lean on a cloud services.) Deployments are easy. In terms of scalability, it's all massively scalable AWS services under the hood, and it seems relatively easy to "eject" if you ever need to.

Once u have enough experience in AWS tooling world, Amplify is probably the last one you want to use for your product, just so unpolished…..

Reply on news.ycombinator.com