7 entries tagged "frontend" — 1 post, 6 links.
This is an evergreen frontend architecture link because URL state is not just routing trivia. It affects sharing, refresh behavior, deep links, browser history, analytics, support, and whether a product feels native to the web.
The caveat is that not every bit of state belongs in the URL. The discipline is deciding which state is part of the user's task context.
This is one of the React links that still earns a place because it explains the runtime model instead of another surface API. Understanding React as a way to describe, schedule, and reconcile UI work ages better than memorizing patterns.
Useful for the site's TypeScript and React writing because it turns framework behavior into architecture vocabulary.
This is an evergreen frontend architecture piece because it names the hard parts of UI work: state, latency, consistency, environment, and synchronization. Those problems do not disappear when the framework changes.
It fits the product-minded engineering theme because UI quality is usually system quality made visible.
This is a small but practical product-engineering link. Browser-native form behavior is often ignored while teams rebuild validation, accessibility, and UX affordances from scratch.
The caveat is that native validation is not a complete product policy. It is a baseline capability that should be combined with clear copy, server-side checks, and accessible error handling.
This is worth keeping because it questions the default assumption that app-like experiences require a full client-side framework. That is a healthy pressure test for product architecture.
The useful takeaway is not "always use htmx." It is that interaction patterns should fit the job, the team, and the maintenance cost.
This is a useful frontend architecture link because it pushes beyond taste and asks what tradeoffs teams inherit when React becomes the default answer.
It belongs next to the React runtime links, not against them. Better engineering judgment comes from understanding both why a tool works and where it costs too much.