> As I assume it's possible to have scalable interfaces in React
React has almost no opinions on web page layouts or anything related to styling. The only type of web page problem I can think of that's specific to React would be hydration errors, and this doesn't sound like that.
The reason that a lot of React interfaces don't scale well is that the vast majority of web pages are very low quality, and React is a popular way to build web pages.
As someone that has written his fair share of raw html, php and js, it's a bit misleading to associate react and these issues. I'm writing in nextjs / react these days, and it's amazing...but like everything out there, if used poorly, you get poor results.
Designing for reactive UI's and accessibility is a feature. Sometimes features get cut, even when they shouldnt.
It appears to be associated with the use of react based visual components - particularly model type dialogs which when they appear allow enabling scrolling but that can appear partially offscreen.
Obviously it's a developer competence issue, but I wondered if there was a React specific trick here - or as you say it's just that popular tech has by definition numerically more low quality/inexperienced developers.
- actually test the UI (different devices, browsers, viewports, scenarios)
- reserve APPROPRIATE time to test UI
- reserve APPRORIATE time to fix the issues
- have designer in tight loop
- have systematic approach to track issues
- test with users
- aim to apply fixes asap so that the fixes gets tested as well
Biggest single factor causing issues is to start late. The time will run out if the styling setup is not robust, it depends on some questionable conventions or libraries, or is simply hacked together.
It is not that complicated, but it is most certainly difficult to do magic tricks late in the development.
React itself is not a root cause. I believe the fundamental cause is a mix of skill issues, lack of knowledge, quality ambitions and time management.
> Biggest single factor causing issues is to start late.
This entirely depends on the dev team working on it and the complexity of what's being asked for. As a developer, I'd rather start late on simple ideas than start early on incomplete and overly complex requirements.
I've seen plenty of projects be absolutely destroyed by product managers and designers with main character syndrome and their own lack of attention to detail and being entirely unresponsive to or flat out inexperienced at answering the technical questions from developers.
Those design decisions are sometimes even late and only mentioned after dev has started. That's completely unacceptable on any project. Requirements and designs are their own intermediate result and demand just as much finality as the product itself. Every revision will erode the final product and mess up a deadline. Developers should not be along for the ride with indecisive designers. Go to the developers with a completed vision and no stone unturned and you will have the best results. Level of experience throughout the project must be equal.
The implementation details are far more important to the overall UX and polish of the result than the visual design. The implementation details can't be ignored or you risk an uncoordinated shit show.
”Start late” in relation to paying attention to details, testing UI and other quality aspects that are not visible in the beginning. In simple terms: budget some time to handle unknowns. Or at least some of them.
When it comes to the amount of upfront design needed…
…yes, everyone agree ”complete vision no stone unturned” is the optimal. That is easy ask.
In real life that is not possible, unless you are working with incredibly small scope OR without any schedule. I.e. not possible. Business with money involved? Just no.
Agree on level of experience. Experience usually helps a lot.
Unable to design and develop system with certain level of uncertainty and adaptability is the real tragedy.
I believe everyone should be interested on the possible routes ahead. Assuming one or two persons are able to foresee some unknowns is intellectually lazy. Expecting them to brainstorm it out to the detail infront of some whiteboard is just not how real life works.
> Unable to design and develop system with certain level of uncertainty and adaptability is the real tragedy.
I'm entirely willing to sound like a naive fool for saying this, but the tragedy from my perspective is business not willing to accept that the majority of the risk comes from letting people with less technical experience be in charge of people with more. That's just plain dysfunction and all too common. Many businesses waste so much money on scaling up their teams when they should be focused on hiring or training up the best.
As I assume it's possible to have scalable interfaces in React - what's the common mistake people are doing?