To frontend developers , Have you ever encountered scaling issue on frontend ? The only time I did was we were using web sockets, it was one time thing. I am curios to know if there is a legit answer to these questions .

Depends how your front end is being served right? I can imagine that if you have a high volume app and are hosted on a regular box, you are going to run into scaling issues. Easier-ish to fix on front end with CDNs, defining E-Tags correctly, minification, etc. Data transmission costs $$$ 😬

Things like CDN (which offer caching, compression etc) are helpful in scaling out front-ends. Also if you're serving the front-end out of static storage (say AWS S3 or Azure Blobs) then you have to pay attention to egress rates & E2E latencies

A direct example I can think of is for instance showing a tabular data containing thousands of rows, and how well does your app can render it while keeping the page responsive and scrollable.

@loud-glass-33663 Doesn't this come under more of Devops/infra? When talking about scaling, I expect architecture issues. Most projects I have worked on were using Amplify/s3. So I personally have never seen these cost/scaling issues.

Depends on perception, as it can be categorized in scaling issue too, especially because it is asked for a frontend position.

@millions-ice-83302 When I think of scaling, I think of: This website works for 10 users simultaneously. What happens when 100,000 users use it simultaneously? Scaling to me, also means the following: 1. Time taken to load should not be affected much 2. I shouldn’t have to scale up so much hardware that I’d get bankrupt. Considering front end is always 1:1 design (i.e. only 1 user is going to access your stuff via 1 interface at a time - for example, a web browser) — I am unable to think about any other scaling examples for front end users and would be super interested to see if someone comes up with anything. Also, I think, being able to compress + build + decently cache user interface is an art in itself.

Think something in line. It purely depends on the architecture too. Imagine we have a web application to download reports. Various ways we can design either generate report in backend and send and generate report in client side itself. If it in client side how will the applications perform on high volume of data.

Compression is definitely an art. Caching doesn't help much in B2B/Saas apps. More like in consumer apps where you have to deal with huge number of users and multi media data (images/videos).

Scaling is with not just users/usage but any data involved. You are showing markers on map to show houses available for rents. Does the app become unresponsive when there are say, 200 markers instead of 10? You’re building a project-management tool, but will it crap out when someone creates 1000 tasks within a single sprint etc. Pagination/caching/push vs pull - all the standard scaling questions apply to frontend as well.

Some examples from my life that you might find parallels to: At a consulting gig long back (angularjs days), I had to make something similar to datatables for showing products and orders, every single thing was editable and angularjs of that time did not like that many watchers at all. The same project also had a CSV importer, this was back when webworkers were not a thing. Client wanted the UI to respond instantly when a user changed the delimiter for example. So server was not an option here. At Verloop, we had some struggle with showing tons of analytics data and websockets. While I was consulting Appsmith, they were going through perf fixes for reactivity (but this case might be an outlier because they're closer to a framework than your typical project) Depending on what they might be looking for, some adjacent problems include figuring out ways to make embedded widgets lighter, build times faster etc. Then there's the whole architecture level work so that big teams can work together aspect of scaling (that might not be relevant in this case, but is definitely important and worth mentioning if you've had experience in that)