7 ms·

In my experience (building things like realtime trade monitoring front ends), client side processing sucks. You have 10 or 20 data sources that need joining up

In my experience (building things like realtime trade monitoring front ends), client side processing sucks. You have 10 or 20 data sources that need joining up in a client defined set of ways (think viewing X price feed with Y trade feed and some Z meta data feed), all natively sending many updates a second - I’ve tried and failed to build a client side heavy implementation (although that might just be my lack of front end skills!), much better to have some DAG of backend processing units that the front end can consume feeds from and remain really light, just managing subscriptions and rendering the data.

galaxyLogic 1mo ago
Developing on the back-end has much more mature tools in my experience, IDEs and QA tools. Client-development is often not much fun dealing with the browser dev-tools. So I share your feeling thath serious development is better done on the back-end. But in principle there should be a client-dev-tool as good as those for the back-end. There is some progress. I've used WebStorm to do client-side work which has a niocve feature that as I debug my client-side program I can use WebStorm instead of browseer-tools and if I see a typo in my code while debugging it I can edit it away and it gets saved into the source-file where it came from.