4 ms·
Different definitions of interactive
by willsmith72 2y ago
Different definitions of interactive
- dmix 2y agoThat's really the distinction the whole "just use HTML + serverside" crowd glosses over. As soon as you have the need for complex UI interfaces (anything beyond a multi-select box and modals) in the browser, which almost every serious SaaS app requires at some point, you're going to need complex JS components. I still think its crazy to use React/Vue beyond very isolated components of functionality and 100% simple server side should be the default unless absolutely necessary. But that's why the frontend industry is already moving to 'islands' of complex JS that is SSR by default. That said, there still seems to be a high burden of adoption of SSR "islands", where you have these complex frameworks like Rewind/Next that still assume React/Vue as the composition of server side views instead of just pieces of the page. Which is probably why so many sites end up with a TON of JS views that are unneeded. Because frontend devs are in their own world/dev enviornment. We really need React/Vue SRR+hydration that blends well into Rails/Python/etc frameworks without needing to commit heavily.
- busterarm 2y agoEnd 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 agoAnd 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 agoWe agree on the importance of accessibility, but it can be both terrible and brilliant in every language or framework.
- agos 2y agoThere 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