Ask HN: Fastest Async Front-End?
I'm looking to build a front-end for task management with real-time AI agent help
I'm curious what I should use for the fastest response experience (<300ms response time for loading data from Postgres/APIs).
- Language - Framework
Snarky responses with detailed opinion welcome
11 comments
[ 2.9 ms ] story [ 26.9 ms ] threadI'm not really sure what you're building, but generally speaking your time-to-first-byte is bottlenecked by geography more than anything, unless your server is constantly under really heavy load.
Generally (and vaguely) speaking, because there isn't much detail in your post, IMO this is less a question of language & framework and more a question of caching and CDNs (unless every API request you respond with is totally dynamic). Depending on what you are trying to build, maybe some of that data can be cached/stored in edge nodes in a cloud KV of some sort (which will be duplicated to data centers around the world if you pay for it) so that each local user can get a fast response from their nearest edge.
Even if you just have one VM sitting in one single data center running Postgres, with some basic indexing, any normal web stack should get you well under 300 ms response time even from across the world. You can cache write-rarely-read-often DB/API content in Redis or similar, and you can cache HTML output in Varnish or similar.
And even if you do have a slow GPT in there that takes some time to respond, that should probably be a different API endpoint anyway (maybe on a different architecture) so the rest of the app isn't slowed down by it. (If by "task management" you mean something like Linear/Jira/kanban board style thing, basic UI states and such shouldn't have to go through a GPT).
If you need fast UI interactions (for things like dragging between columns), probably you can optimistically update it clientside and then send the state updates serverside in the background, and validate that they succeeded. Depending on your frontend framework this can be relatively easy (such as for react, in rtk-query: https://redux-toolkit.js.org/rtk-query/usage/manual-cache-up... or swr: https://swr.vercel.app/examples/optimistic-ui or tanstack: https://tanstack.com/query/v4/docs/framework/react/guides/op...).
If your state model is especially complex, you can maybe also consider saving changes to some local datastore and then batch syncing them to the server every so often. But then having to deal with two-way sync can get really annoying, like if the user logs in on different machines... avoid that if you can; it's a lot simpler when everything is server-authoritative with no client being more than a second or two behind.
Sorry if I'm misunderstanding anything...
State caching & two-way sync is exactly the challenge I’m targeting.
Backend optimization is straight-forward at this stage of dev (appreciate the suggestions though).
What I’m seeking to do is provide dense, tabular data with rapid refreshing as users make changes on the fly.
Any suggestions on how I might learn about managing the state model better?
Vue 3 + Pinia is my current front runner.
A writeup: https://blog.logrocket.com/rendering-large-datasets-vue-js/
As for implementation, this is probably a situation where I'd reach for Someone Else's Library™ instead, at least to learn from. Maybe something like https://www.ag-grid.com/example/ (try the 100k row example) with maybe a serverside data model: https://www.ag-grid.com/vue-data-grid/server-side-model-upda...
That's a ready-made open-core implementation (paid additional features), but you can see an example of how to make an performant implementation. Often, big tables like that can use some sort of virtualization (https://www.ag-grid.com/vue-data-grid/dom-virtualisation/), or here's another lib that does something similar: https://tanstack.com/virtual/latest
There is also a JS framework benchmark at https://github.com/krausest/js-framework-benchmark and a vue-pinia implementation at https://github.com/krausest/js-framework-benchmark/tree/mast...
Lastly, I would say it might be worth considering how the whole dataset works, holistically, as in whether the client really needs to handle all that data at once or if it can be streamed in chunks to & from the server, maybe with a bit of buffer in every direction. It's the same windowing concept, just moved to the network.
And of the data on the client, how much of it is bottlenecked by rendering vs other in-memory operations (sorting, filtering, pagination, etc.) -- can you speed that part up with any better algorithms or data structures?
But it sounds like your main bottleneck right now is rendering large datasets into the DOM, so hopefully some of those above will help.
At some scale, it might also be worth considering moving out of the DOM altogether and into a canvas, like https://canvas-datagrid.js.org/ or https://github.com/xwinstone/canvastable?tab=readme-ov-file. The DOM isn't really made for something like that, and it's pretty amazing what the libs can do, but the canvas can be much much faster. You do lose all the built-in DOM functionality though so you end up having to recreate a lot of functionality (like search, selection, drag & drop, etc.)
------
Good luck! I hope someone comes along with more experience and wisdom to share.
Use case is dense, tabular front ends where users need to rapidly update cells and have business logic applied on the fly.
So far backend is responsive, but front end is taking 10 seconds to handle refreshes.
This is browser intensive two way sync.
I recently wrote my very first API servers (from-end, back-end and Redis & RabbitMq in between) using .net Core with very little real world knowledge, and I easily get <100ms responses and I know I’m not following best practices.
The biggest issue you may have, TBH, is going to be your backend database queries which is why I use Redis for caching - the same request coming in over the same n minutes gets served directly from cache by the front-end which is a huge time win for the F5’rs amongst our users.
Getting the display layer to show tabular data fast is the use case & you got it - lots of refreshing.