HTML is designed for structuring content, not for complex logic like file inclusion. Including external files requires fetching and parsing them, a task handled by the server (server-side includes) or the browser (client-side JavaScript). While templating languages and build tools can pre-process HTML with includes, native HTML lacks the capability because it prioritizes simplicity, performance, and security. Implementing includes directly in HTML would introduce significant complexity, potentially impacting rendering speed and opening up security vulnerabilities if HTML files could arbitrarily execute external scripts. Therefore, the responsibility of assembling the final HTML document typically falls to other tools and technologies better suited to handle the complexities involved.
The GNU Make Standard Library (GMSL) offers a collection of reusable Makefile functions designed to simplify common build tasks and promote best practices in GNU Make projects. It provides functions for tasks like finding files, managing dependencies, working with directories, handling shell commands, and more. By incorporating GMSL, Makefiles can become more concise, readable, and maintainable, reducing boilerplate and improving consistency across projects. The library is designed to be modular, allowing users to include only the functions they need.
Hacker News users discussed the GNU Make Standard Library (GMSL), mostly focusing on its potential usefulness and questioning its necessity. Some commenters appreciated the idea of standardized functions for common Make tasks, finding it could improve readability and reduce boilerplate. Others argued that existing solutions like shell scripts or including Makefiles suffice, viewing GMSL as adding unnecessary complexity. The discussion also touched upon the discoverability of such a library and whether the chosen license (GPLv3) would limit its adoption. Some expressed concern about the potential for GPLv3 to "infect" projects using the library. Finally, a few users pointed out alternatives like using a higher-level build system or other scripting languages to replace Make entirely.
Go's type parameters, introduced in 1.18, allow generic programming but lack the expressiveness of interface constraints found in other languages. Instead of directly specifying the required methods of a type parameter, Go uses interfaces that list concrete types satisfying the desired constraint. This approach, while functional, can be verbose, especially for common constraints like "any integer" or "any ordered type." The constraints package offers pre-defined interfaces for various common use cases, reducing boilerplate and improving code readability. However, creating custom constraints for more complex scenarios still involves defining interfaces with type lists, leading to potential maintenance issues as new types are introduced. The article explores these limitations and proposes potential future directions for Go's type constraints, including the possibility of supporting type sets defined by logical expressions over existing types and interfaces.
Hacker News users generally praised the article for its clear explanation of constraints in Go, particularly for newcomers. Several commenters appreciated the author's approach of starting with an intuitive example before diving into the technical details. Some pointed out the connection between Go's constraints and type classes in Haskell, while others discussed the potential downsides, such as increased compile times and the verbosity of constraint declarations. One commenter suggested exploring alternatives like Go's built-in sort.Interface for simpler cases, and another offered a more concise way to define constraints using type aliases. The practical applications of constraints were also highlighted, particularly in scenarios involving generic data structures and algorithms.
Summary of Comments ( 170 )
https://news.ycombinator.com/item?id=43878728
Hacker News users discuss the limitations of native HTML includes and the reasons behind them. Several commenters point to the complexity of implementing a robust include system within the browser, particularly regarding caching, dependency management, and potential security vulnerabilities. One highly upvoted comment suggests that the desire for includes often stems from a misunderstanding of HTML's purpose as a document format, not a programming language. Others argue that server-side includes (SSI) and build tools effectively address the need for modularity during development, making browser-native includes unnecessary. The lack of standardization and potential performance issues are also cited as reasons for the absence of this feature. Some commenters express a preference for using JavaScript and build tools, while others lament the added complexity this introduces. The historical context of frames and iframes is also brought up, highlighting their shortcomings and why they aren't suitable replacements for true includes.
The Hacker News post "Why can't HTML alone do includes?" generated a moderate amount of discussion, with several commenters offering their perspectives on the complexities of implementing a native HTML include mechanism.
Several commenters highlight the inherent challenges in defining the scoping and behavior of included HTML fragments. One commenter points out the difficulty in determining how
<script>tags within included files should behave, questioning whether they should execute immediately or be deferred. Another echoes this sentiment, emphasizing the potential for conflicts and unexpected behavior if includes were to modify the global scope. This discussion around scoping touches on the broader problem of managing dependencies and ensuring predictable execution order in complex web pages.One user suggests that the desire for HTML includes might stem from a misunderstanding of web development principles, arguing that the separation of structure (HTML), style (CSS), and behavior (JavaScript) intentionally promotes modularity and maintainability. They propose that using a build system to assemble HTML components is a more robust approach.
A recurring theme is the historical context of server-side includes (SSI), which offered a partial solution to this problem. Several commenters mention SSI and its limitations, with one suggesting that the complexity of implementing a full-featured include mechanism in the browser might outweigh its benefits, especially given the availability of build tools and JavaScript frameworks that address similar needs. Another user points to the potential security risks associated with server-side includes.
One commenter questions the framing of the article's title, suggesting that iframes already offer a form of HTML inclusion, albeit with acknowledged limitations. They point to the
<object>tag as another potential mechanism, though with its own set of drawbacks.The conversation also touches on the performance implications of client-side vs. server-side includes, with one commenter noting that client-side includes would necessitate additional network requests.
Finally, there's some discussion about the role of web components and how they address the need for reusable components. One commenter explains how web components, while not a direct equivalent of HTML includes, provide a more structured and powerful way to create and manage reusable UI elements.
In summary, the comments offer a nuanced view of the complexities surrounding HTML includes, exploring the technical challenges, historical context, and alternative approaches to achieving modularity in web development. They also highlight the trade-offs involved in different solutions and the ongoing evolution of web technologies to address these challenges.