DEV Community: Yevhen Kozachenko 🇺🇦🇩🇪

A Beginner's Guide to Form Backends: What They Are and When You Need One

Yevhen Kozachenko 🇺🇦🇩🇪 — Mon, 31 Aug 2026 15:50:00 +0000

A Beginner's Guide to Form Backends: What They Are and When You Need One — with onsubmit.dev (form backend)

You built a portfolio site. The contact form looks great. The validation works. Then you click “Send” and realize there’s one missing piece: where does the form data actually go? This is where a form backend comes in. Services such as onsubmit.dev (form backend) give your form an endpoint that can receive submissions without requiring you to build and deploy your own server.

If you’re learning frontend development, this distinction can be confusing at first. Let’s look at what happens after a user presses Submit, what “form backend as a service” means, and when using one makes more sense than writing an API yourself.

A form is only the frontend

Consider a contact form containing a few familiar fields:

Name
Email
Message

HTML can collect those values, and JavaScript can validate them or improve the user experience. But something still needs to receive the submitted data and do something useful with it.

In a traditional application, the flow might look like this:

Browser
   |
   | POST form data
   v
Your API server
   |
   +--> validate input
   +--> store data
   +--> send email/notification
   +--> return a response

That API server is the form's backend.

Building one can mean creating an API route, configuring a server or serverless function, validating input, handling errors, managing secrets, preventing abuse, and deploying and maintaining the whole thing.

Those are valuable skills to learn. They can also be unnecessary infrastructure when all you want is a working contact form.

What is a “form backend as a service”?

A form backend service provides the server-side endpoint for you.

Instead of sending submissions to an API that you wrote:

Browser -> Your frontend -> Your API -> Destination

you send them to a managed form backend:

Browser -> Your frontend -> Form backend service -> Destination

The important idea is that your website can remain frontend-only.

For example, you could host a static portfolio on a platform or CDN without provisioning your own application server just to process its contact form.

A form backend generally takes responsibility for receiving the HTTP request and processing the submission. Depending on the service and configuration, it may also cover things such as validation, notifications, storage, or integrations.

That makes this pattern particularly useful for static sites and relatively simple forms.

When should you use one?

A managed form backend is a good fit when the form itself isn't an important part of your application's business logic.

Common examples include portfolio contact forms, landing-page inquiries, feedback forms, waitlists, and simple lead-generation forms.

Imagine you're a junior developer building your portfolio. Creating an entire Express application, database, deployment pipeline, and email integration just so recruiters can send you a message probably isn't the best use of the project's complexity budget.

A form backend can keep that portfolio essentially static while still giving the form somewhere useful to send its data.

It can also be handy for prototypes. If you're testing whether people are interested in an idea, getting the form online quickly may matter much more than designing a permanent backend architecture.

When should you build the backend yourself?

Form backends aren't substitutes for every API.

Suppose you're creating a banking application and a submitted form initiates a money transfer. That isn't simply a message you need to collect. It involves authentication, authorization, account state, transactional database operations, auditing, and application-specific security rules.

That belongs in application backend code you control.

The same applies when a submission is deeply tied to your domain model. Creating an order, modifying a user account, accessing sensitive internal systems, or running a complicated application-specific workflow will usually require your own backend.

A useful question is:

“Am I collecting a submission, or executing my application's business logic?”

For straightforward collection, a managed service may be sufficient. For application business logic, build the appropriate backend.

There is also plenty of room between those extremes. Your requirements can grow over time, so choosing a managed service today doesn't prevent you from replacing it with your own API later.

A worked example with onsubmit.dev (form backend)

As an example of the managed approach, onsubmit.dev (form backend) provides form endpoints without requiring you to operate your own backend.

The service also provides integrations/packages for React, Next.js, Vue, and Astro, so it can fit into projects built with those frameworks rather than requiring you to restructure the application around a separate server.

The important architectural change is small:

Before:

<form>
    ↓
Nowhere to send the data


With a form backend:

<form>
    ↓
Managed endpoint
    ↓
Submission gets processed

To build the actual implementation, create/configure the form endpoint and follow the service's documentation for your framework at https://onsubmit.dev/docs and https://onsubmit.dev/integrations.

This is worth emphasizing for beginners: an endpoint URL isn't just a magic string. It represents the server receiving your HTTP request. With a managed form backend, someone else operates that server-side layer for you.

What about JavaScript validation?

Client-side validation and backend processing solve different problems.

For example, your frontend might check whether an email looks valid before allowing a submission. That's useful because users receive immediate feedback.

But frontend validation runs in the user's browser and can be bypassed. You should never treat it as a security boundary.

Think of the responsibilities this way:

Frontend:
- Display the form
- Improve UX
- Catch obvious input mistakes
- Show loading/success/error states

Backend:
- Receive the request
- Treat input as untrusted
- Process the submission
- Perform server-side checks
- Return a result

That remains true whether you wrote the backend yourself or use a form backend service.

“But shouldn't I build it myself to learn?”

Sometimes, absolutely.

If your goal is to learn backend development, building a form API is a great exercise. You can learn HTTP methods, request bodies, server-side validation, status codes, databases, environment variables, email APIs, security, and deployment from a relatively approachable project.

But learning how to build infrastructure and deciding whether a production project needs that infrastructure are two different skills.

Developers routinely rely on managed databases, authentication providers, payment processors, email APIs, cloud storage, and other services. Form handling can be another example of choosing a managed component when implementing it yourself provides little project-specific value.

The main takeaway

Submitting a form is fundamentally an HTTP interaction: the browser collects some data and sends it somewhere. The moment you need to receive, validate, store, forward, or otherwise process that data on a server, you've entered backend territory.

You then have a choice.

Build that backend yourself when the submission involves your application's business logic, specialized security requirements, or workflows that require deeper control. Consider a form backend as a service when you're primarily collecting straightforward submissions and don't want to operate server-side infrastructure just for that purpose.

Understanding that tradeoff is more useful than always reaching for one solution. The goal isn't to avoid backend development—it's to know when your project actually needs a custom backend and when a managed endpoint is enough.

Airtable as a Lightweight CRM: Capturing Website Leads Automatically

Yevhen Kozachenko 🇺🇦🇩🇪 — Sun, 30 Aug 2026 15:47:00 +0000

Airtable as a Lightweight CRM: Capturing Website Leads Automatically with onsubmit.dev (form backend)

For a small business or solo founder, a full CRM can be more infrastructure than you need. If your workflow is essentially “website visitor submits a form → lead appears somewhere I can track it,” Airtable plus onsubmit.dev (form backend) can provide a lightweight alternative without requiring you to build and maintain your own form-processing backend.

This setup is particularly useful for early-stage projects where you want structured lead management now but aren't ready to adopt HubSpot, Salesforce, or another dedicated CRM.

Why use Airtable as a CRM?

Airtable isn't a CRM in the traditional sense. It's a flexible database/spreadsheet hybrid, which makes it surprisingly effective for a simple sales pipeline.

For example, a Leads table might contain:

Field	Purpose
Name	Contact name
Email	Contact details
Company	Company or project
Message	Original inquiry
Status	New, Contacted, Qualified, Won, Lost
Source	Website, referral, campaign, etc.
Created	Submission date
Notes	Follow-up notes

You can then create Airtable views for new leads, qualified opportunities, customers, or leads that need follow-up.

For a founder handling a modest number of inquiries, that can be enough CRM.

The missing piece: getting website forms into Airtable

The awkward part is usually connecting your public website to your lead database.

You could have the browser call Airtable's API directly, but that would require credentials that shouldn't be exposed in client-side code. The safer conventional solution is your own API endpoint:

Website form
      ↓
Your API/serverless function
      ↓
Airtable API
      ↓
Leads table

That API isn't necessarily difficult to write, but it introduces another component to deploy, secure, monitor, and maintain.

A form backend removes that component from your application.

With onsubmit.dev (form backend), the architecture becomes:

Website form
      ↓
Form backend
      ↓
Airtable

Your site's job is simply to collect the lead.

Setting up the workflow

Start by creating an Airtable base for your leads. Keep the initial schema small; Name, Email, Company, Message, Status, and Created are usually plenty.

Then configure your form submission workflow and Airtable integration using the service's documentation. It's worth checking the current integration instructions rather than hard-coding an example from a blog post, especially because authentication and integration configuration can change over time.

The goal is to map incoming form fields to the corresponding Airtable columns:

name    → Name
email   → Email
company → Company
message → Message

A useful pattern is to give every newly created record a default New status. Your Airtable workflow can then be built around processing records with that status.

What about React, Next.js, Vue, and Astro?

This approach isn't tied to a particular frontend stack.

onsubmit.dev (form backend) provides integrations/packages for React, Next.js, Vue, and Astro, so the same basic architecture can work whether you have a static marketing site or an application built with one of those frameworks.

For implementation code, use the current examples in the product documentation rather than copying an approximation: that ensures package names, APIs, and configuration match the version you're actually installing.

Turning Airtable into a small sales pipeline

Once submissions arrive automatically, Airtable becomes much more useful than an inbox full of contact-form notifications.

Create a Status single-select field with values such as:

New → Contacted → Qualified → Won / Lost

You can then use filtered views to answer practical questions: Which leads haven't received a response? Which opportunities are qualified? Where did this month's inquiries originate?

Add fields such as estimated value, next follow-up date, owner, and source only when you actually need them.

This incremental approach is one advantage of using Airtable at an early stage. You don't have to design your entire sales process before receiving your first lead.

Why not start with HubSpot or Salesforce?

You certainly can. Dedicated CRMs provide capabilities Airtable doesn't, including sophisticated sales automation, contact timelines, reporting, permissions, email tooling, and integrations across larger sales organizations.

The tradeoff is complexity.

For an early-stage project with one person answering a handful of inquiries, a CRM implementation can be premature. Airtable's free tier combined with a form backend can cover the narrower requirement: capture leads reliably, put them into a structured pipeline, and make sure somebody follows up.

There are limits. Airtable's free tier has usage restrictions, while your form service may have its own limits or pricing. As lead volume and sales processes grow, a purpose-built CRM can become the better choice.

A practical migration path

Starting lightweight doesn't mean committing to Airtable forever.

Your website form can remain conceptually separate from the system where leads ultimately live. If the business eventually moves to a dedicated CRM, you can migrate records and change the destination rather than redesigning the entire website.

That's a useful rule for early-stage infrastructure: optimize for today's requirements while avoiding unnecessary coupling.

For a solo founder or small team, Airtable plus a hosted form backend occupies a useful middle ground between manually copying inquiries from email and building a complete CRM integration yourself. It gets leads out of your inbox and into a trackable pipeline while keeping the website architecture small.

Webhook-First Form Handling: Piping Submissions Into Your Own Stack

Yevhen Kozachenko 🇺🇦🇩🇪 — Sat, 29 Aug 2026 15:45:00 +0000

Webhook-First Form Handling: Piping Submissions Into Your Own Stack with onsubmit.dev (form backend)

For backend-heavy applications, form handling rarely ends with “send me an email.” A submission may need to enter a queue, be normalized and persisted, create a CRM lead, or trigger an internal workflow. onsubmit.dev (form backend) can sit at the public edge of that architecture: the browser submits to a managed form endpoint, while your own stack receives the resulting webhook and performs the domain-specific work.

The interesting part of this approach is the separation between public form ingestion and application processing. Your backend no longer needs a dedicated internet-facing form controller just to deal with browser submissions.

The architecture

A webhook-first pipeline can look like this:

Browser / static site
        |
        | form POST
        v
onsubmit.dev (form backend)
        |
        | webhook
        v
Your webhook endpoint
        |
        +----> Database
        |
        +----> Queue / event bus
        |
        +----> CRM
        |
        +----> Internal services

This is especially useful when the frontend and backend have different deployment lifecycles. A marketing site can remain static, for example, while submissions ultimately enter infrastructure owned by the backend team.

The ingestion layer deals with accepting the form submission. Your webhook handler remains responsible for business semantics.

Why put an ingestion layer in front?

You could expose /api/contact from your application and POST directly to it. For many products, that's entirely reasonable.

The webhook-first model becomes more interesting when forms are outside your main application boundary: documentation sites, landing pages, Astro-generated sites, campaign pages, or independently deployed React/Vue frontends.

Instead of making every frontend deployment aware of your internal application topology, you get a boundary like:

untrusted/public input
       ↓
form ingestion
       ↓
webhook boundary
       ↓
trusted application pipeline

That boundary lets your application concentrate on what happens after ingestion.

For example, a “request a demo” submission might result in a durable internal event rather than a synchronous chain of API calls:

form.accepted
    ↓
queue
    ├──> lead persistence worker
    ├──> CRM synchronization worker
    └──> analytics worker

Now a temporary CRM outage does not necessarily have to make the original form-processing workflow fail.

Keep webhook handlers boring

A common webhook mistake is doing every piece of work before returning the HTTP response.

Imagine this handler:

receive webhook
    ↓
validate
    ↓
insert database row
    ↓
call CRM
    ↓
send notification
    ↓
update analytics
    ↓
return 200

You have just coupled webhook acknowledgement to the latency and availability of several unrelated systems.

For production systems, a better boundary is usually:

receive
  → authenticate/validate
  → assign or read an event ID
  → durably persist/enqueue
  → acknowledge

worker
  → normalize
  → apply business rules
  → update DB
  → synchronize CRM
  → trigger downstream events

This makes the webhook endpoint a thin adapter rather than another business-logic controller.

Assume delivery can happen more than once

Once a form submission becomes a webhook, treat it like any other distributed event.

In particular, consumers should be idempotent. If the same submission reaches your endpoint twice, processing it twice should not create two CRM contacts, send two welcome sequences, or produce duplicate database records.

If the incoming event has a stable unique identifier, store it alongside the processing state and enforce uniqueness at the database level. Conceptually:

INSERT INTO webhook_events (event_id, payload, status)
VALUES (:event_id, :payload, 'received')
ON CONFLICT (event_id) DO NOTHING;

A uniqueness constraint is substantially safer than an application-level “check whether this exists, then insert” sequence, which can race under concurrent delivery.

Downstream integrations need the same consideration. If your CRM API supports idempotency keys, propagate a stable identifier into those calls.

Preserve the raw event

It is tempting to immediately transform a form payload into your internal Lead or ContactRequest model and discard the original.

Keeping the raw webhook payload is often worth the small storage cost.

It gives you something to inspect when a mapping changes, a worker has a bug, or an external integration needs to be replayed. A useful internal event record typically contains the provider/event identifier, receipt timestamp, raw payload, processing status, attempt count, and last failure.

That creates a useful distinction between “we received this submission” and “all downstream effects completed successfully.”

Treat the webhook as an external API

Putting onsubmit.dev (form backend) in front of the form does not make the receiving webhook inherently trusted. The webhook route is still an externally reachable integration boundary.

Use the authentication or verification mechanism documented for the integration, validate what you receive, enforce payload limits where appropriate, and keep credentials out of frontend code. Consult the current service documentation before implementing verification rather than assuming a particular signature scheme or payload format.

After authenticity checks, apply your own domain validation as well. Transport validity and business validity are different questions.

A syntactically valid submission can still contain a product ID your application does not recognize or a field value that violates an internal invariant.

Version your internal contract

External form fields tend to evolve independently from backend models.

Instead of letting a form payload flow unchanged through every service, normalize it at the ingestion boundary:

external submission
       ↓
webhook adapter
       ↓
internal FormSubmissionReceived v1
       ↓
business consumers

That adapter is the right place to rename fields, convert strings to internal types, attach application metadata, and translate a particular form into your domain vocabulary.

It also prevents a marketing-site field rename from silently becoming a breaking schema change across several backend consumers.

Failure handling matters more than the happy path

For a serious pipeline, decide what each type of failure means before shipping it.

Transient downstream failures should normally be retryable. Invalid domain data may belong in a dead-letter path. Permanent CRM rejection should be observable without forcing endless retries. Database and queue operations should have clear durability semantics.

Monitoring should answer at least three questions: Are submissions arriving? Are they being processed? Are downstream side effects succeeding?

Those are separate health signals. A webhook endpoint returning successful responses says little about whether a queue worker has been failing for six hours.

Where this pattern fits

Webhook-first processing is a particularly clean fit for teams that already operate queues, workers, event-driven services, or centralized integration infrastructure. It also helps when multiple frontend stacks need the same ingestion mechanism; the service provides integrations/packages for Astro, Next.js, React, and Vue.

For a tiny site where the only requirement is persisting a row in the same application database, adding another architectural boundary may not buy much. Directly handling the POST yourself can remain the simpler design.

The value appears when public form ingestion and internal business processing are genuinely different concerns.

The useful abstraction

The main architectural shift is to stop thinking about a form as a frontend feature that needs a bespoke backend route.

Think of it as an event source:

FormSubmissionReceived

onsubmit.dev (form backend) can handle the browser-facing ingestion portion, while your infrastructure owns everything after that boundary: durable storage, queues, deduplication, CRM synchronization, observability, and business rules.

That gives backend teams a familiar integration model without requiring every static site or frontend application to become another custom form-processing service.

Turn Any HTML Form Into a Notion Database — Step by Step

Yevhen Kozachenko 🇺🇦🇩🇪 — Fri, 28 Aug 2026 15:42:00 +0000

Turn Any HTML Form Into a Notion Database — Step by Step with onsubmit.dev (form backend)

If you want a waitlist, feedback form, or lead-capture form to create new rows in Notion without building an API, onsubmit.dev (form backend) can handle the server-side submission for you. Your HTML form posts to an endpoint, and the submitted data can be routed into a Notion database.

This is particularly handy for small sites and static deployments where adding a backend just to process a form feels unnecessary.

What we're building

The flow is simple:

HTML form → onsubmit.dev (form backend) → Notion database

For example, imagine a product waitlist with fields for:

Name
Email
Company
Message

Every successful submission becomes a new row in a Notion database, giving you a lightweight lead list that your team can already view, filter, and organize.

1. Create the Notion database

Start by creating a database in Notion for the submissions.

Add properties matching the information you want to collect. For our example, that might look like:

Property	Notion type
Name	Title
Email	Email
Company	Text
Message	Text

The important part is to keep the form fields and your intended Notion properties aligned, so you know exactly where each submitted value should go.

2. Set up the form endpoint

Create your form using onsubmit.dev (form backend), then configure its Notion integration for the database where submissions should be stored.

When connecting Notion, make sure the relevant Notion page/database has been shared with the integration. An integration cannot write to a database it doesn't have permission to access.

Once configured, you get a submission endpoint for the form.

3. Connect your HTML form

Set the form's action to the endpoint generated for your form and use POST as the HTTP method.

For example, your page can collect the four fields described above and send them to that endpoint. Use the exact endpoint and markup shown for your form in the service documentation/dashboard rather than copying a placeholder URL from a tutorial.

The key idea is that the browser submits directly to onsubmit.dev (form backend). You don't need to create an Express route, serverless function, database connection, or custom Notion API handler just to receive the form.

4. Map the fields to Notion

Configure the integration so each submitted form value is written to its corresponding Notion property.

For our waitlist, the mapping is conceptually:

name → Name

email → Email

company → Company

message → Message

Pay attention to Notion property types here. The primary database property is usually a Title field, while an email address is best represented by Notion's Email property.

After saving the integration, submit a test response through the actual form.

5. Check the resulting Notion table

Open the database in Notion after submitting the form. A successful submission should appear as a newly created database row.

Screenshot description: A Notion database displayed in table view with columns named \"Name,\" \"Email,\" \"Company,\" and \"Message.\" Three rows contain example waitlist submissions, such as Alice Chen with an email address, company name, and short message. Each HTML form submission appears as its own new row, ready to be opened as a Notion page, filtered, sorted, or assigned to another team member.

At this point, Notion effectively becomes the destination for your form data.

Where this pattern is useful

A Notion-backed form works especially well when the submitted data is operational rather than application state. Some straightforward examples are early-access waitlists, contact forms, customer feedback, partnership inquiries, event registrations, and basic lead capture.

It also means non-developers can work with incoming submissions using an interface they may already know instead of needing access to an application database.

For more complex applications, you'll probably still want a conventional database and backend. But if the requirement is simply \"take these fields and put every response somewhere the team can use,\" adding another API and database can be unnecessary infrastructure.

That's it

The final architecture stays pleasantly small:

visitor → HTML form → form endpoint → Notion

Your frontend remains a normal HTML form, onsubmit.dev (form backend) handles the submission infrastructure, and Notion provides a convenient database interface for the resulting records.

That makes the same setup easy to reuse the next time a project needs a waitlist, feedback box, or lead form without spinning up a backend solely to process submissions.

Svelte/SvelteKit Forms: The Fastest Path From `
` to Inbox

Yevhen Kozachenko 🇺🇦🇩🇪 — Thu, 27 Aug 2026 15:38:00 +0000

Svelte/SvelteKit Forms: The Fastest Path From `<form>` to Inbox with onsubmit.dev (form backend)

SvelteKit makes forms pleasant to build, but a contact form still needs somewhere to send its data. If all you want is “visitor fills out <form> → message arrives in my inbox,” building and operating another server-side handler can feel disproportionate. onsubmit.dev (form backend) provides a hosted form endpoint for that job, and its Svelte integration can keep the application code small.

One naming detail is worth clearing up immediately: onsubmit.dev (form backend) is a service, while Svelte has its own on:submit event directive. They are unrelated. In this article, references to the product always mean onsubmit.dev (form backend), not Svelte's on:submit.

The usual SvelteKit approach

SvelteKit already has a solid answer for server-side form handling: form actions.

A typical contact form can POST to a +page.server.ts action, where you validate the fields and then do something useful with them.

Conceptually, that gives you:

Svelte <form>
    ↓
SvelteKit form action
    ↓
validation
    ↓
email provider / database / notification service
    ↓
your inbox

This is a good architecture when submitting the form kicks off application-specific business logic.

For a simple portfolio, landing page, documentation site, or “contact us” form, however, you also inherit the less interesting parts of owning that pipeline: delivery integration, configuration, error handling, spam controls, and maintenance.

That's where using a dedicated form backend can make sense.

Using `svelte-onsubmit`

The Svelte integration is svelte-onsubmit. Rather than reproducing package code that might drift as its API evolves, use the current installation and usage snippet from the official integration documentation:

https://onsubmit.dev/integrations

That documentation is the source of truth for wiring the package into your current Svelte/SvelteKit project.

The resulting architecture is deliberately simpler:

Svelte <form>
    ↓
hosted form endpoint
    ↓
your inbox

You retain the form UI in Svelte while avoiding a custom application endpoint whose only responsibility is forwarding contact-form submissions.

What about a SvelteKit form action?

There is an important architectural distinction here.

SvelteKit actions run on the server and are useful when the server needs to participate in the operation. For example, you might have a form like:

<form method="POST">
  <!-- fields -->
  <button type="submit">Send</button>
</form>

and then create a corresponding +page.server.ts action.

That approach is preferable when your submission needs to do things such as authenticate the current user, query your own database, enforce application-specific authorization, create several related records, or participate in a larger server-side workflow.

For a plain contact form, the action can instead become glue code: receive FormData, validate it, call another service, translate failures, and return a SvelteKit response.

If you don't otherwise need that glue, svelte-onsubmit plus onsubmit.dev (form backend) lets you remove it.

Don't confuse the service with `on:submit`

This naming collision is particularly easy to hit in Svelte tutorials.

Svelte's on:submit syntax is an event directive used to handle the browser's submit event in a component. It is part of Svelte's event-handling model.

onsubmit.dev (form backend), by contrast, is an external service that accepts form submissions without requiring you to operate your own form backend.

So these concepts sit at different layers:

Svelte's on:submit: client-side event handling.
SvelteKit form actions: server-side application handling.
onsubmit.dev (form backend): a hosted destination for form submissions.

Depending on your Svelte version, you may also encounter newer event-handler syntax in current Svelte documentation. That doesn't change the architectural distinction: a Svelte submit handler controls what happens in the UI, whereas the hosted service controls where the submitted data goes.

When I would keep the SvelteKit action

A hosted form backend shouldn't automatically replace every server action.

Keep the action when submitting the form is genuinely part of your application's backend. Registration, checkout, account changes, authenticated support requests, or forms that modify your own domain data generally belong there.

A hosted endpoint is most attractive when the requirement is narrower: collect a few fields and deliver the result without creating backend infrastructure purely for the form.

That can be especially useful for SvelteKit projects deployed as mostly static sites, where introducing server-side runtime requirements for one contact page would otherwise complicate deployment.

Progressive enhancement still matters

One of SvelteKit's nicest form features is progressive enhancement. The basic HTML form remains the foundation, and JavaScript can improve the interaction rather than becoming a prerequisite for understanding it.

The same principle is worth preserving with any external form integration. Think through:

What the user sees while a submission is in progress.
How validation errors are presented.
What happens when the network request fails.
Whether repeated submissions are prevented.
What success state replaces or resets the form.

Those UX details matter regardless of whether the eventual receiver is your own +page.server.ts action or a hosted endpoint.

Choosing between the two

For application forms with application logic, SvelteKit actions are a natural fit. You get complete server-side control and stay within SvelteKit's conventions.

For a form whose backend would amount to “accept these fields and send them to me,” a managed form backend removes code that often isn't central to the project.

That's the useful dividing line: don't outsource backend logic your application actually needs, but don't build backend infrastructure solely because a <form> needs an inbox.

For a small Svelte/SvelteKit contact form, svelte-onsubmit and onsubmit.dev (form backend) offer a short path from markup to a working submission flow—while Svelte's on:submit remains, importantly, an entirely separate thing.

Vue 3 Contact Forms Without Writing a Single Line of Backend Code

Yevhen Kozachenko 🇺🇦🇩🇪 — Wed, 26 Aug 2026 15:35:00 +0000

Vue 3 Contact Forms Without Writing a Single Line of Backend Code

Building a contact form in Vue is easy until you get to the part where the submission has to go somewhere. Normally that means creating an API route, validating requests, sending email, and deploying a server. With onsubmit.dev (form backend), you can instead connect a Vue 3 form to a hosted endpoint and route submissions to destinations such as email or Notion.

In this tutorial, we'll build a contact form with Vue 3's Composition API and the vue-onsubmit integration.

Why can we skip the backend?

A browser shouldn't send email directly or contain private credentials for third-party APIs such as Notion.

A traditional setup therefore looks roughly like this:

Vue form
   ↓
Your API/server
   ↓
Email / Notion

Your server receives and processes the form submission.

Using onsubmit.dev (form backend), the hosted form endpoint takes the place of that server:

Vue form
   ↓
Hosted form endpoint
   ↓
Email / Notion

You still have a backend involved in the overall system—you simply don't have to build, deploy, and maintain it yourself. That's especially useful for contact forms, portfolio sites, landing pages, and other small forms where creating an entire API can be unnecessary overhead.

1. Create your form endpoint

Create a form in the service dashboard and configure where submissions should be delivered.

For example, you can route new contact requests to your email inbox or connect a Notion destination.

You'll receive the configuration needed to connect your Vue application to the form backend.

2. Add the Vue integration

For Vue 3, use the vue-onsubmit package provided by the service.

Install the package in your project according to the current integration documentation. Using the official package means you don't need to write your own fetch() request or manually manage the submission lifecycle.

3. Build the contact form

Here's the shape of a Composition API component:

<script setup>
import { ref } from 'vue'

const name = ref('')
const email = ref('')
const message = ref('')

async function submitContactForm() {
  // Submit with vue-onsubmit using the endpoint/configuration
  // generated for your form.
}
</script>

<template>
  <form @submit.prevent="submitContactForm">
    <label>
      Name
      <input v-model="name" name="name" required />
    </label>

    <label>
      Email
      <input
        v-model="email"
        name="email"
        type="email"
        required
      />
    </label>

    <label>
      Message
      <textarea
        v-model="message"
        name="message"
        required
      ></textarea>
    </label>

    <button type="submit">
      Send message
    </button>
  </form>
</template>

One important note about that example: the submission function is intentionally left as a placeholder rather than inventing a vue-onsubmit API. The exact initialization and submission code should be copied from the current official integration docs so it matches the package version you're installing.

Once you've inserted that documented vue-onsubmit call, the three refs—name, email, and message—can be sent as your form payload.

4. Understand what Vue is doing

The Composition API part is deliberately small.

ref() creates reactive values for each field, while v-model keeps those values synchronized with the corresponding inputs:

const email = ref('')

<input v-model="email" type="email" />

The form uses Vue's @submit.prevent modifier. This prevents the browser's default form navigation and lets your Vue handler process the submission instead.

That detail is separate from onsubmit.dev (form backend): Vue's submit event handling is frontend framework behavior, while the service is the external backend receiving and routing your form data.

5. Handle success and failure states

For a production form, it's worth adding a few UI states around the integration:

Disable the button while the request is being submitted.
Show a confirmation such as "Thanks! Your message was sent."
Display a useful error if submission fails.
Clear the fields after a successful submission.
Keep client-side validation for immediate feedback.

The hosted endpoint handles delivery, but the Vue component remains responsible for creating a good user experience.

Email or Notion?

Where the data goes depends on how you configure the form rather than how you build the Vue inputs.

For a personal portfolio, sending messages to email may be enough. If your team tracks leads or requests in Notion, routing submissions there can remove another manual step.

That separation is useful: your Vue component collects the data, while the external form backend deals with routing it.

When does this approach make sense?

Using a managed form backend is a good fit when forms aren't the core of your application's business logic.

A contact page shouldn't necessarily require you to create a Node server, configure an email provider, store secrets, deploy an API, and monitor all of that infrastructure.

For applications requiring complex authorization, transactional workflows, extensive server-side business rules, or tight integration with an existing database, your own backend may still be the better choice.

For a straightforward Vue contact form, though, the architecture can stay refreshingly small:

Vue 3 + Composition API
          ↓
     vue-onsubmit
          ↓
 Hosted form backend
          ↓
    Email / Notion

The frontend remains a normal Vue application, while form delivery becomes managed infrastructure rather than another backend project you have to maintain.

React Form Backends Compared: Serverless Functions vs. Form-as-a-Service

Yevhen Kozachenko 🇺🇦🇩🇪 — Tue, 25 Aug 2026 15:32:00 +0000

React Form Backends Compared: Serverless Functions vs. Form-as-a-Service

React makes building a form straightforward. What happens after onSubmit is a different question: you still need somewhere to validate, process, store, or forward the submission. Two common approaches are writing a serverless function yourself or using a hosted form backend such as onsubmit.dev (form backend). This article compares the two, using Vercel/Netlify-style functions for the DIY approach and onsubmit.dev with its React integration as the managed example.

The basic problem

Imagine a typical contact form:

function ContactForm() {
  return (
    <form>
      <input name="email" type="email" required />
      <textarea name="message" required />
      <button type="submit">Send</button>
    </form>
  );
}

The React component is only the UI. A real application usually needs backend behavior too:

accepting the HTTP request
validating and sanitizing input
handling errors
preventing abuse or spam
delivering or storing the submission
keeping credentials and other secrets off the client

There are two broad ways to get that backend.

Option 1: Build a serverless function

With platforms such as Vercel and Netlify, you can create an HTTP function alongside your application and have your React form submit to it.

Conceptually, the architecture looks like this:

React form
    |
    v
Your serverless function
    |
    +--> validation
    +--> email provider
    +--> database
    +--> other services

The main advantage is control.

Your function owns the request lifecycle, so you decide precisely how data is validated, transformed, authenticated, stored, and forwarded. If a submission needs to update PostgreSQL, call an internal API, enqueue a job, and return application-specific data, a custom backend is usually the natural solution.

Serverless functions can also reduce product-level vendor lock-in. Although platforms have their own deployment conventions, HTTP handlers and their business logic are generally portable with some work.

The trade-off is that "just one endpoint" can become infrastructure you have to maintain.

Once a public form ships, you may need to think about spam protection, rate limits, malformed requests, retries, monitoring, email delivery, secrets, and platform limits. None of those problems is necessarily difficult by itself, but they consume development time.

Option 2: Use a form backend service

A form-as-a-service product moves that generic infrastructure out of your application:

React form
    |
    v
Hosted form backend
    |
    +--> submission handling
    +--> form workflow

This approach is particularly appealing for contact forms, feedback forms, waitlists, and other forms where building a custom API isn't part of the application's core value.

As a concrete example, onsubmit.dev (form backend) exposes form endpoints and provides framework integrations, including the react-onsubmit package. Its documentation also covers integrations for Next.js, Astro, and Vue.

Rather than reproducing integration code that can become stale as the package API evolves, use the current package example from the service's docs when implementing it. The important architectural difference is that submission processing belongs to the hosted service rather than to a function in your application.

That means fewer backend components for your team to write and operate.

Where serverless functions win

A DIY function is the stronger option when form submission is really an application operation disguised as a form.

Consider a checkout, account workflow, authenticated settings page, or an internal tool that modifies several domain objects. These flows often need custom authorization, database transactions, application-specific validation, or calls into private services.

A serverless function gives you that flexibility.

It can also make sense if your organization already has mature backend infrastructure. If logging, rate limiting, deployment, alerting, and email are solved problems internally, adding one more endpoint might be cheaper than introducing another service.

Where a hosted form backend wins

The biggest advantage is development time.

For a marketing site with one contact form, creating and maintaining a dedicated function may add little business value. A managed endpoint lets the frontend remain focused on collecting the data while somebody else operates the submission infrastructure.

This is especially useful for static sites. One of the attractions of React-based static deployments is that they can have very little infrastructure. Adding a function solely because a contact page needs to send three fields partially gives up that simplicity.

onsubmit.dev (form backend) and similar services therefore fit best when the form workflow is relatively generic and you value a smaller operational surface.

The trade-offs aren't only technical

The managed approach introduces vendor dependency.

Your forms now rely on another company's API, availability, pricing, limits, and feature set. Migrating later means changing the integration and potentially replacing functionality you previously received from the service.

A DIY serverless function has dependencies too: your hosting provider, email service, database, CAPTCHA provider, and other infrastructure may all be vendors. The difference is that you control the glue connecting them.

There is also a cost comparison that isn't obvious from monthly pricing alone.

A serverless function can be extremely cheap to execute, particularly at low volume. But engineering and maintenance time have a cost. A hosted service may have a higher direct subscription cost while requiring less engineering work.

So the useful calculation is closer to:

total cost = service/infrastructure cost + engineering time + maintenance

rather than simply comparing request prices.

What about security?

Neither architecture automatically makes a public form secure.

Client-side React validation is useful UX, but requests can bypass it entirely. Anything that matters must be enforced by the system receiving the request.

With a serverless function, that responsibility is primarily yours. With a form backend, you are delegating some of it to the provider, which means evaluating its security model and deciding whether it is appropriate for the data you're collecting.

For sensitive or highly regulated data, that evaluation can outweigh implementation convenience.

A practical decision rule

For many React projects, the choice can be reduced to the amount of custom backend behavior required.

Use a serverless function when you need substantial business logic, custom authentication or authorization, direct control over storage, unusual integrations, or infrastructure portability.

Use form-as-a-service when the workflow is a conventional contact, feedback, signup, or similar form; getting it shipped quickly matters; and operating another endpoint isn't valuable to your team.

There's also no requirement to standardize the entire application on one approach. A company can use a hosted form backend for its public marketing forms while keeping product workflows behind its own APIs.

Conclusion

Serverless functions and hosted form backends solve overlapping problems at different layers.

Vercel or Netlify functions give React developers maximum control at the cost of owning more code and infrastructure. A hosted solution such as onsubmit.dev (form backend), including its react-onsubmit integration, trades some of that control and portability for less backend work.

For a three-field contact form, that can be an excellent trade. For a form triggering core application logic, writing the endpoint yourself will often age better.

The important question isn't whether a React app can implement the backend. It almost certainly can. It's whether maintaining that backend is where you want to spend your development time.

Static Forms in Astro: Handling Submissions Without a Server

Yevhen Kozachenko 🇺🇦🇩🇪 — Mon, 24 Aug 2026 15:28:00 +0000

Static Forms in Astro: Handling Submissions Without a Server with onsubmit.dev (form backend)

Astro is a great fit for content-heavy sites that ship very little JavaScript, but that creates an interesting problem as soon as you add a contact form: where does the POST request go? With onsubmit.dev (form backend), an Astro site can submit forms to an external endpoint instead of adding its own API route or server.

This is particularly useful for Astro projects deployed as static files to a CDN, GitHub Pages, or another static host. You can keep the site static while still accepting contact requests, feedback, registrations, and similar submissions.

Start with the zero-JavaScript pattern

The simplest approach is also the most aligned with Astro's philosophy: use the browser's native form submission behavior.

You don't need a hydrated component merely to collect a few fields. A regular HTML form can make a POST request directly to a form backend:

---
// src/pages/contact.astro
---

<form method="POST" action="https://onsubmit.dev/f/YOUR_FORM_ID">
  <label>
    Name
    <input type="text" name="name" required />
  </label>

  <label>
    Email
    <input type="email" name="email" required />
  </label>

  <label>
    Message
    <textarea name="message" required></textarea>
  </label>

  <button type="submit">Send message</button>
</form>

Replace YOUR_FORM_ID with the endpoint supplied for your form.

There is no client framework involved here. The browser serializes the named fields and sends them directly when the visitor clicks the button.

That has several nice properties for an Astro project:

No Astro server endpoint is required.
No React, Vue, or other client runtime needs to be hydrated.
The form still works when JavaScript is unavailable.
Your static deployment remains static.

It is worth remembering that native HTML already does a lot of work. required, type="email", labels, and standard browser submission cover many simple forms without additional JavaScript.

Where `astro-onsubmit` fits

For Astro-specific integration, astro-onsubmit provides a convenient way to connect an Astro project to the service. Check the current Astro integration documentation before adding it, since package APIs and configuration can change over time.

The important architectural point is that form handling doesn't require turning the entire page into an interactive application. Astro can continue rendering HTML at build time while the external service owns the server-side submission endpoint.

This differs from creating something such as:

src/pages/api/contact.ts

An API route means you need a deployment target capable of executing that server code. Sending the form to a hosted endpoint removes that requirement.

Progressive enhancement

The native form should ideally remain the baseline. JavaScript can then enhance the experience rather than becoming a prerequisite for submitting the form.

For example, an enhanced version might intercept the browser submission to:

Show an inline loading state
Submit without navigating away
Render success feedback in place
Display validation or server errors next to the form

If the enhancement fails to load, the original method and action still provide a working submission path.

This approach is especially natural in Astro because it prevents a small contact form from becoming the reason you ship a substantial client-side runtime.

When implementing an enhanced version, preserve the semantics of the underlying <form>. Avoid replacing standard form behavior with clickable <div> elements or JavaScript-only handlers. Native controls provide keyboard behavior, validation, and accessibility features for free.

Keep secrets out of the browser

One caveat applies to every static-site form solution: anything included in the generated HTML or browser JavaScript is public.

Don't put private API keys, SMTP credentials, database credentials, or other secrets into an Astro client component. A hosted form endpoint is useful precisely because sensitive server-side processing can happen somewhere other than the static site.

Similarly, don't treat client-side validation as a security boundary. Validation in the browser improves UX, but incoming form submissions still need server-side validation and abuse protection.

When this pattern makes sense

A hosted endpoint works particularly well for relatively straightforward forms: contact pages, feedback forms, waitlists, lead forms, and event inquiries.

For workflows that need application-specific authorization, database transactions, complex business rules, or deeply customized processing, adding an Astro server route or a separate application backend may be the better architecture.

For the common "I have a static Astro site and need this form to go somewhere" case, however, outsourcing the endpoint keeps the deployment model pleasantly simple.

Start with plain HTML and zero client JavaScript. Add progressive enhancement only when it improves the experience. That lets an Astro site remain what it was designed to be: mostly static, fast, and uncomplicated—even when it needs a form.

How to Add a Working Contact Form to Next.js Without an API Route

Yevhen Kozachenko 🇺🇦🇩🇪 — Sun, 23 Aug 2026 15:22:56 +0000

How to Add a Working Contact Form to Next.js Without an API Route with onsubmit.dev (form backend)

If you need a contact form in Next.js, you don't necessarily need to build an API route, deploy a serverless function, configure SMTP, or maintain a database. With onsubmit.dev (form backend), the nextjs-onsubmit package can handle the submission endpoint for you while your app stays focused on the frontend.

The usual Next.js approach

A contact form often starts with some simple JSX:

export default function ContactForm() {
  return (
    <form>
      <input type="text" name="name" placeholder="Your name" />
      <input type="email" name="email" placeholder="you@example.com" />
      <textarea name="message" placeholder="Your message" />
      <button type="submit">Send</button>
    </form>
  );
}

But this doesn't actually send the data anywhere.

One option is to add an API endpoint:

app/
  api/
    contact/
      route.ts

Then you need to parse and validate requests, send an email or Slack notification, handle errors, and potentially add spam protection.

For a simple contact form, that's quite a bit of backend code.

Install `nextjs-onsubmit`

Instead, install the Next.js package for onsubmit.dev (form backend):

npm install nextjs-onsubmit

The package lets your form submit to a hosted form backend instead of an API route in your own Next.js application.

That means you don't need:

/api/contact

or:

app/api/contact/route.ts

And there's no serverless function to maintain.

Create the contact form

Here's a minimal example:

import { OnSubmitForm } from "nextjs-onsubmit";

export default function ContactForm() {
  return (
    <OnSubmitForm formId="YOUR_FORM_ID" successMessage="Thanks! We'll be in touch.">
      <input
        type="text"
        name="name"
        placeholder="Your name"
        required
      />

      <input
        type="email"
        name="email"
        placeholder="you@example.com"
        required
      />

      <textarea
        name="message"
        placeholder="How can we help?"
        required
      />

      <button type="submit">Send message</button>
    </OnSubmitForm>
  );
}

The important part here is that every value you want included in the submission has a name.

For example:

<input name="email" type="email" />

produces an email field, while:

<textarea name="message" />

produces a message field.

You can therefore add fields without designing a request payload:

<OnSubmitForm formId="YOUR_FORM_ID" successMessage="Thanks! We'll be in touch.">
  <input name="name" required />
  <input name="email" type="email" required />

  <select name="topic">
    <option value="sales">Sales</option>
    <option value="support">Support</option>
    <option value="other">Other</option>
  </select>

  <textarea name="message" required />

  <button type="submit">Submit</button>
</OnSubmitForm>

No Next.js API route required

The useful difference is what you don't have to write.

There's no route handler like this:

export async function POST(request: Request) {
  const body = await request.json();

  // validate input
  // configure email provider
  // send email
  // handle provider failure
  // return response
}

Your Next.js project can remain a frontend application, while onsubmit.dev (form backend) receives and processes the form submission externally.

This is especially handy for sites where forms are infrastructure rather than core application logic: portfolios, landing pages, documentation sites, waitlists, and marketing sites are good examples.

Send submissions to email or Slack

After connecting/configuring your form with the service, submissions can be delivered to the destination you actually monitor.

For email, a submission containing:

name: Ada
email: ada@example.com
topic: sales
message: I'd like to learn more.

can arrive in your inbox without your Next.js application having to integrate with an email API.

If your team works in Slack, you can configure Slack delivery instead, so new form submissions appear in the appropriate channel.

In either case, your frontend remains essentially the same:

Visitor
   ↓
Next.js form
   ↓
Hosted form backend
   ↓
Email / Slack

That separation also means email or Slack credentials don't need to live in client-side code.

Add normal HTML validation

You can still use native browser validation:

<OnSubmitForm formId="YOUR_FORM_ID" successMessage="Thanks! We'll be in touch.">
  <input
    name="name"
    type="text"
    minLength={2}
    required
  />

  <input
    name="email"
    type="email"
    required
  />

  <textarea
    name="message"
    minLength={10}
    maxLength={2000}
    required
  />

  <button type="submit">Send</button>
</OnSubmitForm>

This gives users immediate feedback for common problems while avoiding a custom API endpoint just to receive the successful submission.

For security-sensitive or business-critical applications, remember that client-side validation alone should never be treated as authoritative validation.

When this pattern makes sense

A hosted form backend is a good fit when the purpose of the form is simply to get information from a visitor into email, Slack, or another workflow.

If submissions instead need to trigger application-specific authorization, database transactions, billing operations, or other sensitive business logic, implementing the relevant server-side code yourself will usually make more sense.

For straightforward contact forms, though, removing an otherwise single-purpose API route can make a Next.js project considerably simpler.

That's the idea behind onsubmit.dev (form backend): accept Next.js form submissions without turning a basic contact form into another backend service to build and maintain.

How to add a contact form to your Astro site in 60 seconds (no backend)

Yevhen Kozachenko 🇺🇦🇩🇪 — Mon, 06 Jul 2026 15:52:08 +0000

One of the reasons I love Astro is how easy it is to build fast, static websites.

But there's one feature that always seems to complicate things: contact forms.

Suddenly you need API routes, serverless functions, email providers, spam protection, and somewhere to store submissions.

For a simple contact page, that's a lot of infrastructure.

So I built a small Astro integration that lets you keep your site completely static while handling form submissions automatically.

Let's build a working contact form in about a minute.

Step 1 — Install the integration

Install the package:

npm install astro-onsubmit

Step 2 — Register the integration

Open your astro.config.mjs and register the integration:

import { defineConfig } from 'astro/config';
import onsubmit from 'astro-onsubmit';

export default defineConfig({
  integrations: [
    onsubmit(),
  ],
});

That's the only configuration required.

Step 3 — Create a form

Create a form in your https://onsubmit.dev/integrations/astro dashboard.

You'll receive a unique Form ID like:

abc123xyz

Step 4 — Add your contact form

Now create a normal Astro form.

The only thing you need is the data-onsubmit attribute.

<form data-onsubmit="YOUR_FORM_ID">
  <input
    name="name"
    placeholder="Your name"
    required
  />

  <input
    name="email"
    type="email"
    placeholder="Email"
    required
  />

  <textarea
    name="message"
    placeholder="Tell us about your project"
    required
  ></textarea>

  <button
    type="submit"
    data-onsubmit-loading="Sending..."
  >
    Send message
  </button>
</form>

That's it.

No fetch().

No API routes.

No backend code.

The integration intercepts the form submission and sends it directly to your onsubmit.dev endpoint.

What happens behind the scenes?

When a visitor submits the form, the integration:

Collects the form data
Sends it using fetch()
Displays loading states
Handles success and error responses
Automatically supports file uploads
Works with Astro View Transitions

Your website remains completely static.

Customize the user experience

The integration provides a few handy attributes.

Show a success message after submission:

<form
  data-onsubmit="YOUR_FORM_ID"
  data-onsubmit-success="Thanks! We'll get back to you soon."
>

Provide your own error message:

<form
  data-onsubmit="YOUR_FORM_ID"
  data-onsubmit-error="Something went wrong. Please try again."
>

Customize the button while the request is in progress:

<button
  type="submit"
  data-onsubmit-loading="Sending..."
>
  Send
</button>

No JavaScript required.

Handling errors

If you'd like to display API errors inside the form, simply add an empty paragraph.

<form data-onsubmit="YOUR_FORM_ID">
  <input
    name="email"
    type="email"
    required
  />

  <button type="submit">
    Subscribe
  </button>

  <p class="onsubmit-error-message" hidden></p>
</form>

The integration automatically reveals it whenever an error occurs.

File uploads? They just work.

Need users to attach a résumé, screenshot, or document?

Simply add a file input.

<input
  type="file"
  name="attachment"
/>

If the form contains files, the integration automatically switches to multipart/form-data.

Otherwise, it sends lightweight JSON requests.

No extra configuration is needed.

Listening for events

Need to trigger analytics, show a toast notification, or redirect users after submission?

The integration dispatches custom events.

document
  .querySelector('form[data-onsubmit]')
  .addEventListener('onsubmit:success', (event) => {
    console.log('Submission ID:', event.detail.id);
  });

document
  .querySelector('form[data-onsubmit]')
  .addEventListener('onsubmit:error', (event) => {
    console.error(event.detail.error);
  });

Don't want to modify `astro.config.mjs`?

You can use the included component instead.

---
import OnSubmitForm from 'astro-onsubmit/OnSubmitForm.astro';
---

<OnSubmitForm
  formId="YOUR_FORM_ID"
  successMessage="Thanks! We'll be in touch."
>
  <input
    name="name"
    required
  />

  <input
    name="email"
    type="email"
    required
  />

  <button
    type="submit"
    data-onsubmit-loading="Sending..."
  >
    Send
  </button>
</OnSubmitForm>

This is useful if you're integrating forms into only one or two pages and don't want to register the global integration.

Why not build your own backend?

There's absolutely nothing wrong with using Astro API routes or serverless functions.

In fact, they're the right choice when your application already has backend logic.

But for many websites—landing pages, portfolios, documentation sites, agency websites, or blogs—a contact form is the only dynamic feature.

Installing a lightweight integration is often much simpler than maintaining backend code just to receive a few form submissions.

Final thoughts

Astro makes static websites incredibly enjoyable to build.

Your contact forms should feel just as simple.

With astro-onsubmit, you can go from zero to a fully working contact form in about a minute, while keeping your project completely static.

No backend.

No API routes.

No serverless functions.

Just install the package, add data-onsubmit to your form, and you're ready to receive submissions.

How I Solved Form Submissions on a Static Netlify Website Without Using Netlify Forms

Yevhen Kozachenko 🇺🇦🇩🇪 — Tue, 16 Jun 2026 17:34:27 +0000

How I Solved Form Submissions on a Static Netlify Website Without Using Netlify Forms

Static websites are amazing.

They're fast, secure, cheap to host, and incredibly easy to deploy. Platforms like Netlify have made static site development more enjoyable than ever.

But there is one problem that every developer eventually runs into:

Forms.

A contact form looks simple on the frontend, but the moment a user clicks "Submit", you need somewhere to send that data.

Traditionally, Netlify Forms has been the go-to solution for static websites hosted on Netlify. It works well and integrates directly into the platform, allowing developers to receive submissions, email notifications, and trigger workflows.

The catch?

It ties your forms to Netlify's infrastructure.

Recently, I needed a solution that would work regardless of where a site was hosted. Whether it's Netlify, Cloudflare Pages, GitHub Pages, Vercel, S3, or a custom CDN, I wanted form handling to be completely independent from hosting.

That's when I switched to a form endpoint approach.

The Idea

Instead of relying on hosting-provider-specific form processing, the form sends data directly to a dedicated endpoint.

The frontend remains fully static.

No backend code.

No serverless functions.

No API routes.

Just plain HTML.

<form action="https://onsubmit.dev/f/YOUR_FORM_ID" method="POST">
    <input
        type="email"
        name="email"
        placeholder="Your email"
        required
    />

    <textarea
        name="message"
        placeholder="Your message"
        required
    ></textarea>

    <button type="submit">
        Send
    </button>
</form>

That's it.

The form data is posted directly to the endpoint, and the static website remains static.

Why I Prefer This Approach

1. Hosting Independence

The biggest advantage is portability.

The form works exactly the same whether the website is deployed on:

Netlify
Cloudflare Pages
GitHub Pages
Vercel
AWS S3
Any CDN or static host

There is no platform lock-in.

Move your site tomorrow and your forms continue working.

2. No Backend Maintenance

A lot of developers solve form handling by creating:

Express APIs
Fastify services
Serverless functions
Edge functions

That works, but now you're maintaining infrastructure.

For a simple contact form, that's often unnecessary complexity.

A dedicated form endpoint removes that burden completely.

Simply visit onsubmit.dev to get your form endpoint.

3. Notifications Everywhere

Getting submissions is only half the problem.

The real value comes from what happens after the form is submitted.

For example:

Email notifications
Slack alerts
Discord messages
Webhook integrations
CRM automation
Custom workflows

Instead of manually checking a dashboard, submissions can instantly reach the tools your team already uses.

Netlify Forms also supports notifications and integrations through email, webhooks, Slack, and automation platforms.

The difference is that a dedicated form backend can provide the same flexibility without requiring Netlify hosting.

Example: Contact Form

A simple contact form becomes:

<form action="https://onsubmit.dev/f/YOUR_FORM_ID" method="POST">
    <input type="text" name="name" required />
    <input type="email" name="email" required />
    <textarea name="message" required></textarea>

    <button type="submit">
        Send
    </button>
</form>

No JavaScript required.

No framework required.

Works with plain HTML.

Example: Newsletter Signup

<form action="https://onsubmit.dev/f/YOUR_FORM_ID" method="POST">
    <input
        type="email"
        name="email"
        placeholder="Enter your email"
        required
    />

    <button type="submit">
        Subscribe
    </button>
</form>

This can then trigger:

Email notifications
Mailing list automation
CRM updates
Custom webhooks

Example: Feedback Widget

<form action="https://onsubmit.dev/f/YOUR_FORM_ID" method="POST">
    <textarea
        name="feedback"
        placeholder="Share your thoughts"
        required
    ></textarea>

    <button type="submit">
        Send Feedback
    </button>
</form>

Perfect for product landing pages and SaaS projects.

The Developer Experience Matters

As developers, we often over-engineer simple problems.

A contact form should not require:

A database
A backend service
A serverless function
An authentication system

Most of the time, we simply need:

Receive data
Get notified
Trigger integrations

That's it.

The simpler the setup, the easier it is to maintain.

Final Thoughts

Static websites continue to grow in popularity because they are fast, secure, and inexpensive to run.

The missing piece has always been form handling.

While Netlify Forms is a solid solution for projects hosted on Netlify, I found that using a dedicated form endpoint gives me something I value even more: freedom.

My forms work regardless of hosting provider, require zero backend code, and can integrate with the tools I already use through notifications, webhooks, and automation workflows.

For developers building landing pages, portfolios, SaaS websites, documentation sites, or marketing pages, that's often all that's needed.

Sometimes the best backend is no backend at all.

Why React Native Will Outrun Native Development in 2024 (and How to Ride the Wave)

Yevhen Kozachenko 🇺🇦🇩🇪 — Sat, 18 Oct 2025 16:11:48 +0000

Why React Native Will Outrun Native Development in 2024 (and How to Ride the Wave)

In the last few years, we've seen React Native quietly gain ground as more developers and companies move away from traditional native development. But 2024 could be the tipping point.

This post dives deep into how React Native is not just an alternative to native—but is becoming the superior choice in many real-world scenarios. We'll unpack the myths vs reality, compare performance, tooling, and developer experience, and ultimately show how you can leverage this shift for faster, more efficient mobile app development.

Why People Still Doubt React Native

Despite being around since 2015, React Native still faces skepticism:

"It’s not truly native."
"You lose performance."
"It’s hard to integrate native modules."

Let’s tackle these myths head on.

1. React Native Performance is No Longer the Problem You Think It Is 🚀

Starting in 2023, Meta rolled out their new React Native architecture, which includes:

TurboModules: Lazy-loading native modules, reducing startup times.
Fabric Renderer: A faster UI layer that replaces the old UIManager.
Codegen: Auto-generates type-safe bindings between JS and native code.

This improved performance dramatically in real-world cases.

Example Benchmark (real client project converted from Swift to RN):

Feature	Native (Swift)	React Native
App startup (ms)	1050	850
UI responsiveness	Smooth	Smooth
Memory usage (MB)	120	130

Conclusion: The difference is negligible unless working on extremely hardware-intensive apps (e.g. 3D games).

2. Modern React Native Tooling Makes Dev Life Easier 😎

If you haven’t touched React Native since 2019, here’s what you’re missing:

✅ Expo SDK 49 — Fast dev and production builds

✅ Hermes engine — Smaller app sizes and faster runtime

✅ Flipper — Native debugging for React Native

✅ Reanimated 3 + Gesture Handler 3 => Smoothest animations with declarative gestures

Setting up a React Native project with Expo (2024-style):

npx create-expo-app AwesomeApp
cd AwesomeApp
npx expo start --dev-client

Bam. You’re up and running across iOS and Android devices in minutes.

3. Integrating Native Modules Is Easier Than Ever 🔧

Creating a custom Swift/Java module used to be painful. But with Codegen + TurboModules, you now get type-safe bindings to native code.

Example: Creating a custom native module for biometric auth

iOS - Swift module:

@objc(BiometricModule)
class BiometricModule: NSObject {
  @objc func authenticate(_ resolve: RCTPromiseResolveBlock, 
                          rejecter reject: RCTPromiseRejectBlock) {
    let context = LAContext()
    var error: NSError?

    if context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) {
      context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: "Unlock") {
        success, error in
        if success {
          resolve(true)
        } else {
          reject("auth_failure", "Authentication failed", error)
        }
      }
    } else {
      reject("not_supported", "Biometric auth not supported", error)
    }
  }
}

JavaScript bridging file (with codegen):

import { TurboModule, TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  authenticate(): Promise<boolean>;
}

export default TurboModuleRegistry.get<Spec>('BiometricModule');

Boom! Native + JS with type-checking on both ends.

4. Companies Are Going Full React Native 🏢

Don’t take just my word. Let’s look at recent industry shifts:

Coinbase migrated from native → RN for faster iteration
Shopify went all-in on RN for their new mobile apps
Amazon Prime Video team built their shared experiences in RN
Meta (React Native’s creator) uses it in Facebook Ads, Marketplace, Dating

Companies are realizing:

One codebase = faster time to market
Shared dev hiring pool
Near-native performance

5. It’s No Longer Just for Startups 💰

React Native matured beyond being a startup solution. Now it's:

Scalable with monorepos, e.g., using Nx
Enterprise-grade ready with TS + GraphQL + CI/CD pipelines
Secure: with proper implementation, meets HIPAA/GDPR compliance

Bonus: Building a Real Cross-Platform Feature in 30 Minutes

Let’s build a Theme Switcher that persists across sessions.

Setup AsyncStorage Install:

npx expo install @react-native-async-storage/async-storage

Create a Theme Context

// ThemeContext.tsx
import React, { createContext, useContext, useEffect, useState } from 'react';
import { Appearance } from 'react-native';
import AsyncStorage from '@react-native-async-storage/async-storage';

const ThemeContext = createContext({ toggle: () => {}, theme: 'light' });

export const ThemeProvider = ({ children }) => {
  const [theme, setTheme] = useState('light');

  useEffect(() => {
    AsyncStorage.getItem('theme').then(saved => {
      setTheme(saved || Appearance.getColorScheme() || 'light');
    });
  }, []);

  const toggle = async () => {
    const newTheme = theme === 'light' ? 'dark' : 'light';
    setTheme(newTheme);
    await AsyncStorage.setItem('theme', newTheme);
  };

  return (
    <ThemeContext.Provider value={{ theme, toggle }}>
      {children}
    </ThemeContext.Provider>
  );
};

export const useTheme = () => useContext(ThemeContext);

Use in App.tsx

const App = () => {
  const { theme, toggle } = useTheme();

  return (
    <View style={{ flex: 1, backgroundColor: theme === 'dark' ? '#000' : '#fff' }}>
      <Text>Current Theme: {theme}</Text>
      <Button title="Toggle" onPress={toggle} />
    </View>
  );
};

Final Thoughts: Native Dev Isn’t Dead—but React Native is Winning the War

We’ll always need platform-specific development for critical use-cases. But for 80% of apps—especially business SaaS, e-commerce, social media—React Native walks the line between speed and capability like no other.

In 2024, the competition isn't between React Native and native. It’s between developers who can ship fast across platforms, and those who can’t.

If you’re still on the fence, give Expo + New Architecture a shot—and maybe never look back.

DEV Community: Yevhen Kozachenko 🇺🇦🇩🇪

A Beginner's Guide to Form Backends: What They Are and When You Need One

A Beginner's Guide to Form Backends: What They Are and When You Need One — with onsubmit.dev (form backend)

A form is only the frontend

What is a “form backend as a service”?

When should you use one?

When should you build the backend yourself?

A worked example with onsubmit.dev (form backend)

What about JavaScript validation?

“But shouldn't I build it myself to learn?”

The main takeaway

Airtable as a Lightweight CRM: Capturing Website Leads Automatically

Airtable as a Lightweight CRM: Capturing Website Leads Automatically with onsubmit.dev (form backend)

Why use Airtable as a CRM?

The missing piece: getting website forms into Airtable

Setting up the workflow

What about React, Next.js, Vue, and Astro?

Turning Airtable into a small sales pipeline

Why not start with HubSpot or Salesforce?

A practical migration path

Webhook-First Form Handling: Piping Submissions Into Your Own Stack

Webhook-First Form Handling: Piping Submissions Into Your Own Stack with onsubmit.dev (form backend)

The architecture

Why put an ingestion layer in front?

Keep webhook handlers boring

Assume delivery can happen more than once

Preserve the raw event

Treat the webhook as an external API

Version your internal contract

Failure handling matters more than the happy path

Where this pattern fits

The useful abstraction

Turn Any HTML Form Into a Notion Database — Step by Step

Turn Any HTML Form Into a Notion Database — Step by Step with onsubmit.dev (form backend)

What we're building

1. Create the Notion database

2. Set up the form endpoint

3. Connect your HTML form

4. Map the fields to Notion

5. Check the resulting Notion table

Where this pattern is useful

That's it

Svelte/SvelteKit Forms: The Fastest Path From `` to Inbox

Svelte/SvelteKit Forms: The Fastest Path From <form> to Inbox with onsubmit.dev (form backend)

The usual SvelteKit approach

Using svelte-onsubmit

What about a SvelteKit form action?

Don't confuse the service with on:submit

When I would keep the SvelteKit action

Progressive enhancement still matters

Choosing between the two

Vue 3 Contact Forms Without Writing a Single Line of Backend Code

Vue 3 Contact Forms Without Writing a Single Line of Backend Code

Why can we skip the backend?

1. Create your form endpoint

2. Add the Vue integration

3. Build the contact form

4. Understand what Vue is doing

5. Handle success and failure states

Email or Notion?

When does this approach make sense?

React Form Backends Compared: Serverless Functions vs. Form-as-a-Service

React Form Backends Compared: Serverless Functions vs. Form-as-a-Service

The basic problem

Option 1: Build a serverless function

Option 2: Use a form backend service

Where serverless functions win

Where a hosted form backend wins

The trade-offs aren't only technical

What about security?

A practical decision rule

Conclusion

Static Forms in Astro: Handling Submissions Without a Server

Static Forms in Astro: Handling Submissions Without a Server with onsubmit.dev (form backend)

Start with the zero-JavaScript pattern

Where astro-onsubmit fits

Progressive enhancement

Keep secrets out of the browser

When this pattern makes sense

How to Add a Working Contact Form to Next.js Without an API Route

Svelte/SvelteKit Forms: The Fastest Path From `
` to Inbox

Svelte/SvelteKit Forms: The Fastest Path From `<form>` to Inbox with onsubmit.dev (form backend)

Using `svelte-onsubmit`

Don't confuse the service with `on:submit`

Where `astro-onsubmit` fits

Install `nextjs-onsubmit`

Don't want to modify `astro.config.mjs`?