3 ms·

End users don't want complex UI interfaces, they want to use your product to find value as quickly as possible. You can have a crayon drawing interface as long

End users don't want complex UI interfaces, they want to use your product to find value as quickly as possible. You can have a crayon drawing interface as long as things make sense and there isn't friction from using the product. Some UI gets this but often I find that most does not and that's the most common complaint that I hear from company to company..."you have the most advanced product but I need to take a two month course to figure out how to use it". Customers really just want to buy your product, do nothing and get money and the closer you can get to delivering on that experience, the better. You will always get more value from building APIs and integrations with other products than you will from putting options in the hands of users, but the big players in industry know this and build big moats intended to keep you out rather than improve everyone's products and their customers happiness. The problem is as workers in this industry we've taken the money and been good soldiers rather than demand and enforce open standards that would benefit our day-to-day and society at large. I haven't even started in on the darker side of UI/UX like dark patterns and "engagement". It's not like "Sam's Pizza Shop" or any other small (or even medium) business needs some super complicated UI/UX and building that out for them would leave them worse off. Complicated JS frameworks should be the exclusive domain of companies employing hundreds+ of engineers and even then you have the problems from the last paragraph. IMO if you choose to work on frontend and perpetuate all this behavior, you're part of the problem.

willsmith72 2y ago
> End users don't want complex UI Agreed, simplicity can be part of a great UX > JS frameworks should be the exclusive domain of companies employing hundreds+ of engineers Definitely not. All it takes is a few comboboxes, date/time pickers, or literally anything wanting client state, to deliver a FAR better UX using js than pure html. If you tried building the kind of experience expected by today's consumers without js, you would know. People have very little patience for mediocrity on the web Simple tech does not mean simple UX
- busterarm 2y ago
  And every single fancy UX JS tooling to provide those features utterly fails to do so in a way that's compatible with screen readers to be usable by people with visual impairments. Things like fly-out menus can be completely unusable by people with tremors. ADA lawsuits against websites are massively on the rise (I worked in the early stages of WCAG compliance and helping people seek to bring such lawsuits). You don't need all that fancy shit to deliver something that works and every time you go overboard with it you're alienating someone... Edit: Also, wth? Every browser supports showPicker() and you can control and style the crap out of that without pulling components and frameworks into the mix. Nobody's saying don't use JS at all here. You don't need teams of engineers, components and a whole frontend build toolchain to put forms on a basic website. THAT is the complaint here. Not "caveman think JavaScript bad".
  - willsmith72 2y ago
    We agree on the importance of accessibility, but it can be both terrible and brilliant in every language or framework.
  - agos 2y ago
    There are excellent options for building accesible stuff in the frontend world nowadays. If somebody is building something that is not accessible, the issue is not with the tooling
dmix 2y ago
> End users don't want complex UI interfaces It's complex UI requirements, not complex UIs... For ex our company routes phone calls and needed routing system that had 3 layers deep of hierarchical organization, reordering, sorting, weighting, grouping etc. You could have done all of those with a new page load every time, or spread out into individual static pages, but that'd take 10x longer for the user. I built something that did all of that in a box that fit into one screen and one page load, and only 1 ajax request for autocomplete search box. Some things just demand 'desktop style' complex browser UIs that server side simply can't provide... Which is why every serious company that makes $$ uses it. Backend devs like to pretend they can throw the baby out with the bath water and call it day, then deliver poor UX because they limit themselves artificially, just because some people abuse JS. That's not the solution.
- busterarm 2y ago
  None of what you did requires vite or nextjs and all of the tooling that comes with all of that. And then in three years when the undermaintained bit of software needs to be updated the entire landscape has changed in the JavaScript world 4x over already and the tooling needs to be entirely redone along with the desired change. Again, nobody is saying "you don't need JavaScript". We're saying that the way you folks are going about it is Hell's Treadmill. At least if I have a languishing, old, unrebuildable bit of code on the server side, I can find some exploit to make it run my code changes without modifying any of the original code :D

willsmith72 2y ago

> End users don't want complex UI Agreed, simplicity can be part of a great UX > JS frameworks should be the exclusive domain of companies employing hundreds+ of engineers Definitely not. All it takes is a few comboboxes, date/time pickers, or literally anything wanting client state, to deliver a FAR better UX using js than pure html. If you tried building the kind of experience expected by today's consumers without js, you would know. People have very little patience for mediocrity on the web Simple tech does not mean simple UX

busterarm 2y ago
And every single fancy UX JS tooling to provide those features utterly fails to do so in a way that's compatible with screen readers to be usable by people with visual impairments. Things like fly-out menus can be completely unusable by people with tremors. ADA lawsuits against websites are massively on the rise (I worked in the early stages of WCAG compliance and helping people seek to bring such lawsuits). You don't need all that fancy shit to deliver something that works and every time you go overboard with it you're alienating someone... Edit: Also, wth? Every browser supports showPicker() and you can control and style the crap out of that without pulling components and frameworks into the mix. Nobody's saying don't use JS at all here. You don't need teams of engineers, components and a whole frontend build toolchain to put forms on a basic website. THAT is the complaint here. Not "caveman think JavaScript bad".
- willsmith72 2y ago
  We agree on the importance of accessibility, but it can be both terrible and brilliant in every language or framework.
- agos 2y ago
  There are excellent options for building accesible stuff in the frontend world nowadays. If somebody is building something that is not accessible, the issue is not with the tooling

dmix 2y ago

> End users don't want complex UI interfaces It's complex UI requirements, not complex UIs... For ex our company routes phone calls and needed routing system that had 3 layers deep of hierarchical organization, reordering, sorting, weighting, grouping etc. You could have done all of those with a new page load every time, or spread out into individual static pages, but that'd take 10x longer for the user. I built something that did all of that in a box that fit into one screen and one page load, and only 1 ajax request for autocomplete search box. Some things just demand 'desktop style' complex browser UIs that server side simply can't provide... Which is why every serious company that makes $$ uses it. Backend devs like to pretend they can throw the baby out with the bath water and call it day, then deliver poor UX because they limit themselves artificially, just because some people abuse JS. That's not the solution.

busterarm 2y ago
None of what you did requires vite or nextjs and all of the tooling that comes with all of that. And then in three years when the undermaintained bit of software needs to be updated the entire landscape has changed in the JavaScript world 4x over already and the tooling needs to be entirely redone along with the desired change. Again, nobody is saying "you don't need JavaScript". We're saying that the way you folks are going about it is Hell's Treadmill. At least if I have a languishing, old, unrebuildable bit of code on the server side, I can find some exploit to make it run my code changes without modifying any of the original code :D