The article "Overengineered Anchor Links" explores excessively complex methods for implementing smooth scrolling anchor links, ultimately advocating for a simple, standards-compliant approach. It dissects common overengineered solutions, highlighting their drawbacks like unnecessary JavaScript dependencies, performance issues, and accessibility concerns. The author demonstrates how a concise snippet of JavaScript leveraging native browser behavior can achieve smooth scrolling with minimal code and maximum compatibility, emphasizing the importance of prioritizing simplicity and web standards over convoluted solutions. This approach relies on Element.scrollIntoView() with the behavior: 'smooth' option, providing a performant and accessible experience without the bloat of external libraries or complex calculations.
The underscore in target="_blank" is a relic of older HTML versions where custom target names were conventionally prefixed with an underscore to distinguish them from predefined targets like _top, _self, _parent, and _blank. While underscores are no longer technically required for custom target names in modern HTML, the convention persists, especially with _blank, due to its widespread historical use. Essentially, the underscore was originally a way to signal a developer-defined target, separating it from the reserved target names built into the HTML specification.
Hacker News users discussed the historical context of the underscore in target="_blank", attributing it to the legacy of SGML and HTML's early evolution. Some pointed out that the underscore was used as an escape character for non-standard attributes, allowing developers to introduce custom attributes without breaking the existing parser. This was especially important during the transition from SGML to HTML, as browsers were still evolving. The underscore acted as a signal that this was an extension, potentially browser-specific, and not part of the official standard at the time. Others questioned the current necessity of the underscore and whether modern HTML specifications still require it, suggesting it's primarily a historical artifact. A few comments also touched upon the security implications of target="_blank" without rel="noopener", a common topic often paired with discussions about this attribute.
Summary of Comments ( 12 )
https://news.ycombinator.com/item?id=43570324
Hacker News users generally agreed that the author of the article overengineered the anchor link solution. Many commenters suggested simpler, more standard approaches using just HTML and CSS, pointing out that JavaScript adds unnecessary complexity for such a basic feature. Some appreciated the author's exploration of the problem, but ultimately felt the final solution was impractical for real-world use. A few users debated the merits of using the
<details>element for navigation, and whether it offered sufficient accessibility. Several comments also highlighted the performance implications of excessive JavaScript and the importance of considering Core Web Vitals. One commenter even linked to a much simpler CodePen example achieving a similar effect. Overall, the consensus was that while the author's technical skills were evident, a simpler, more conventional approach would have been preferable.The Hacker News post "Overengineered Anchor Links" discussing the article at thirty-five.com/overengineered-anchoring has generated several comments. Many commenters appreciate the author's deep dive into a seemingly simple problem and the exploration of various solutions.
A recurring theme is the trade-off between complexity and benefit. Several users acknowledge the cleverness of the solutions presented but question their practical application given the existing, simpler alternatives. One commenter points out that using
:targetin CSS is often sufficient and less complex for most use cases. They argue that while the proposed JavaScript solutions offer smoother animations and more control, the added complexity might not be justified for the marginal improvement in user experience. This sentiment is echoed by others who suggest that native browser behavior is often good enough.Some commenters discuss specific aspects of the proposed solutions. One points out potential accessibility issues with the JavaScript approach, particularly concerning focus management and keyboard navigation. They suggest ensuring proper focus handling for users who navigate with keyboards rather than mice. Another commenter raises concerns about the reliance on JavaScript, noting that it can introduce performance overhead and potential points of failure. They advocate for progressive enhancement, suggesting starting with a simple CSS-only solution and adding JavaScript enhancements only when necessary.
Several users delve into the technical details of the code, discussing alternative implementations and potential optimizations. One suggests using the Intersection Observer API to detect when an element is in view, potentially improving performance and reducing complexity. Another commenter proposes a different approach using scroll snapping, arguing that it might offer a smoother and more native-like experience.
The discussion also touches upon the broader topic of over-engineering in web development. Some commenters argue that while the author's exploration is interesting from a technical perspective, it highlights the tendency to overcomplicate simple solutions. They suggest that developers should prioritize simplicity and maintainability whenever possible.
Finally, a few commenters share their own experiences with implementing anchor link behavior, offering alternative solutions and sharing resources for further exploration. One commenter links to a library that provides smooth scrolling functionality, while another shares a code snippet demonstrating a simple CSS-based approach.
In summary, the comments section on Hacker News reflects a mixed reaction to the author's overengineered anchor link solutions. While appreciating the technical ingenuity, many commenters express concerns about complexity, accessibility, and performance overhead. The discussion highlights the ongoing tension between creating sophisticated user experiences and maintaining simplicity and practicality in web development.