521–530 of 551 posts
Earlier quoted context omitted.
Many bad things are popular. Java, C++, JavaScript. Popularity doesn't preclude something from being shit. The front end UI isn't a collection of evolving standards. It's the same standard with more and more cruft added on top. HTML wasn't designed for what we are doing with it now. Each additional layer... css, JavaScript, the dom, typescript, react, is a new layer over an old thing. It's like never buying a new car…
There's a difference between being popular, and being the most popular thing in a category ever and keeping that title for decades with no serious challengers. The browser as we know it with the DOM is the latter. Maybe that will change with new APIs that hook into the canvas, but we're still a ways off from that and I suspect the DOM will remain in the picture even then.
You're right the dom will remain in the picture for a long time. Doesn't change the fact that it's horribly designed.
Earlier quoted context omitted.
button { all: unset; } This removes all the preset browser css styles. An accessible,styled is much easier to achieve than an accessible, styled
What makes it more accessible? I suspect the answer is that screenreaders don't look for all clickable elements and are naively focusing only on buttons.
Earlier quoted context omitted.
Present a form with a 25 item native multiselect to 10 of your non-prgrammer family members. Ask them to perform two tasks: - Select 5 non-adjacent items - Select 5 adjacent items. Report back with success rates.
The nice thing about native behaviors is you only have to teach them once. Custom behaviors per application make it harder for people to develop a model of how their computer works because you have to learn a new interaction model per application. I’m pretty anti the notion that UX is intuitive in any sense: all human-computer interaction is learned at some point and we should focus more on educating people how to do…
I actually like native web multi-select widget because I know how it works and it works well. But most people don't know how it works, no one is going to teach them, and they aren't going to look it up (they probably don't even know what to search for to learn!). So you need one that works just with clicks and no modifier keys or most people won't actually be able to use it. In other words, it's not accessible.
Earlier quoted context omitted.
What kind of web dev can't handle React? Meanwhile, htmx uses clunky, non-standard attributes that rely on logic and templates that are split up in a million different places. Plus it requires a context switch to do anything client side.
Don't underestimate the learning commitment it takes to learn react. Learning the basics of react and its component architecture is one thing, learning all the tricks and gotchas related to hooks, accidental re-renders, accidental no-renders, etc takes time. Throw in the usual pile of libraries used with any larger react app and it can easily take months to really get moving.
Earlier quoted context omitted.
Sounds like we're agreeing with each other and disagreeing with the big SPA framework guy?
I mean, I am a big SPA framework guy. That's pretty much the main thing I use, day-in, day-out, because most of the projects I'm working on are complex enough that simply hand-coding the entire UI will not work. And, while only a minority of projects are that complex, those projects are the ones most developers are working on. Most other projects are probably better served with a wordpress install and a bit of theme…
I've used SPA frameworks, but try to avoid it if I can, because most of the logic is in the backend. I don't want to create and sync API interfaces, have 1-2 additional contexts (JS + frontend framework) and debug an extra layer.
With htmx I can now have interactivity via the backend. I use Alpine.js for some interactivity.
Earlier quoted context omitted.
I am very happily listening to UX thoughts from people who specialize in UX. What I am decidedly NOT happy with, is the frontend using as much, or even more, internal logic, magic, and build steps as the actual business logic. To put this another way: I will happily listen to an interior designer on his thoughts about the color of the drapes. But if he tells me that this color means he has to bring his own crew of st…
That applies to backends equally, but you don’t get thinkpieces on how that makes it a great idea for frontend devs to avoid all those silly DTOs and design patterns that complicate the server code.
Overly complicated, architecture-astronaut code, that leans on frameworks for no good reason, is bad, no matter what part of the stack. And yes, this is true for the backend as well. There are people who will happily import 3 different frameworks to make a POST request in Go.
Earlier quoted context omitted.
Why? Why does it need to be good for big projects in order to be good practice? I’m genuinely asking. I never understood this argument that people bring. In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.
Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects. Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all. I personally…
Earlier quoted context omitted.
> the more it benefits the development team to write that code in their language of choice on the backend Why? TS is maintainable and very pleasant to code in. Most people’s computers are way faster than making round trips to a server. You talk about serializing everything to/from JSON, but my phone can do that in milliseconds (if not faster). Compare that to 100-200ms of latency between a faraway server, and all of…
> Compare that to 100-200ms of latency between a faraway server A complex booking engine like an airline or Stubhub needs constant, almost real-time connectivity with a database, otherwise you risk selling product at a stale price, double-selling, selling to an unauthenticated person, getting taxes and fees wrong, missing custom post-sale add-on opportunities, and lots of other potential problems. The client has to m…
If only they actually worked like this. I’ve experienced, as I’m sure many other people have, problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails because I was too slow. It’s also much faster to only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page.
All that to say, there are tradeoffs. Finding the solution with the best latency and the best experience requires a careful analysis of all these details and figuring out which approach (or combination of approaches) solves that problem the most efficiently. Of course it’s not easy, but nothing you’ve said here indicates one solution would always outperform another solution.