Hacker News Reader

Comment by onemoresoop | Hacker News Reader

Related to UI but not exactly on density. Even Refilling a prescriptions from Wallgreen's seems to have become impossible from a smaller phone such mine - IPhone SE2020 - since the control to choose the pharmacy or add a zip code for searching one is not actionable, the interface automatically scrolls down and when I drag the page I can see that it's there but there's no way to access it. It appears to be some kind of React garbage optimized for larger screens but completely and utterly broken on slightly smaller ones. It's not that I have anything against the technology itself but it broke basic functionality of yesteryear that just worked. And to what avail? All seems broken and ugly these days. And this isn't even about looking under the hood and analyzing the waste this wave of technology has brought. Where are we heading to? Is everything about to get worse and worse? Who is benefitting from all this because the user isn't...

View on HN

I've seen a lot of React interfaces that don't scale well - and even worse don't allow you to scroll to the bit you can't see!

As I assume it's possible to have scalable interfaces in React - what's the common mistake people are doing?

> 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.

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.

I'm glad you said this.

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.

Increase effort/improve in these areas:

- focus on authoring robust CSS

- 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.

I'm with you... I use a 5.9" phone, but have accessibility/font settings maxed out. There are a lot of sites with limited or broken functionality. Modal dialogs are the absolute worst... they should be configured to just take over the screen on smaller displays, with the region as scrollable. It's easy enough to do, and has been my approach for menus and modals for a long while now.

I spent 8.5 years teaching at a lower-tier, public "access" university in the US. Don't get me wrong, it was great for what it did, and I was fortunate to work with a lot of awesome people. But we were far from an elite, exclusive institution like Harvard or MIT.

For many years I served on the CS department's graduate admissions committee. Lots of our MS applicants talked about working on sites for major US / western brands, and lots of those kids did not make the cutoff for even our relatively low bar for admission.

I think about that a lot whenever I see that a multibillion dollar multinational corporation has a web page that doesn't work at all.

Computer Science is an odd match for basic programming. I would want a CS department to reject many people who are perfectly capable of making good websites.

I wish the US had a more appropriate path for "software development education" than "scientific study of computing" or commercial bootcamps.

Where I'm from, after high school there's vocational higher education (as opposed to scientific higher education), and parallel to high school there's vocational education.

I'm sorry, but what does poorly implemented responsive design have to with React? I agree with you that most websites are very poorly made, but that's not React's fault (as much as it is being constantly shitted on here on HN, which I really don't like), only developers' (and their managers'). Please stop blaming frameworks.

It's true that React almost certainly wouldn't be responsible for what sounds like a blatant layout bug on a narrow smartphone viewport. React has almost no opinions on things like web page layout or touch interactions. I have to imagine the commenter invoked "React" as a sort of scapegoat for the prevalence of low-quality web pages.

Maybe not React itself, but the UI frameworks that draw devs to the frameworks, yes. Frameworks like that offer the promise of responsive design to developers without actually helping them understanding how it works, and as a result often fail to deliver on that promise. Splitting everything into 12 grid columns often just hides the actual work that needs to be done. Plain HTML is fully responsive by default, almost all framework components are less-so.

I don't blame React per say. But with the proliferation of this technology I've noticed lots of things broken (links, history navigation, layout) that render a lot of things unusable to me and unfortunately I see very few upsides. I'm even willing to admit that React and SPAs are a great technology that enables some (few) use cases that were cumbersome before. But, it clearly seems rushed and applied everywhere with no discernable thought.

React was created because we wanted to have more complex web apps. That brings more complexity in development. Empirically, clearly we now see everywhere that most companies don't want to pay for the best version of their websites they can have.

I agree and part of that was delivered, I mentioned earlier that for some use cases SPA tech couldn't be better (well, it could and it keeps on improving and i'm in for it). But it seems that it washed away with good practices, with things that used to work and are utterly broken. Again, Im not blaming React, I just can't help but notice that the brokenness started around the same time React was adopted en masse.

React is great for what it does. But people also wants it where it does not fit (where server-rendered html is enough with vanilla JS). And then they go on to re-implement half the browser features. Badly.

I completely agree with this. Management is usually under a lot of pressure to add new features or fix bugs from the previous release that was also rushed. This has a compounding effect on technical debt.

The pace and scale of application development is also not at all comparable to the past. The level of involvement management has in app dev is much higher and there are more technical contributors who are less coordinated. This leads to a lot of "good enough" thinking instead of paying attention to details.

This is especially true for products and especially at startups. Less so for services at big orgs. Services tend to have a longer lifecycle. Services are usually B2B and the public never sees those UIs.

It's a poor craftsman who blames his tools.

You can blame a tool for making your work easier or harder, but you can't blame a tool for making your work substandard.

There's an old saying: "a bad workman blames his tools."

Reply on news.ycombinator.com