This post explores the ever-evolving landscape of web technologies and their compatibility across different browsers and platforms. It examines tools like iwanttouse.com and other resources to determine what web features can be safely used in 2021. The discussion will also include insights from industry experts like Jason and Mathias Bynens regarding JavaScript best practices. Finally, the post proposes the innovative concept of adopting a "quirks mode" but tailored to specific years, which could offer greater control over web development.
This post discusses the importance of using push notifications responsibly in Progressive Web Apps (PWAs). It highlights the negative impact of intrusive notification prompts and emphasizes the need for providing context and respecting user preferences. The post links to a helpful article and video by Thomas Steiner that provides further guidance on best practices for web push notifications, including avoiding immediate prompts and clearly communicating the value and frequency of notifications.
I recently conducted an experiment challenging common documentation "best practices." I found that some widely accepted guidelines may not be as effective as we think. My experience highlighted the need for data-driven approaches to documentation, such as using "was this page helpful?" feedback widgets, to truly understand what makes documentation helpful. I encourage everyone to adopt more rigorous methods for evaluating documentation effectiveness.
Feature Policy is a new web platform API designed to help developers maintain control over their web app's performance, security, and user experience. It allows developers to define policies that restrict access to certain features or modify the browser's default behavior. Examples include controlling autoplay, access to sensitive APIs, usage of fullscreen, preventing use of outdated APIs, and managing image sizes. Policies act as a contract between the developer and the browser, ensuring the developer's intent is followed even as the project grows and evolves. While adoption is a concern, its potential benefits for performance, security and privacy are substantial, especially if tied to incentives like app store listings.
I'm exploring the best way to load web components, focusing on how to include styles and templates without creating uncontrolled blocking requests. I've experimented with using a single JavaScript file that encapsulates everything, including styles and a dynamically created template element. This approach avoids external requests but raises questions about extensibility and best practices. Should we revive HTML imports, embrace ES modules, or find a common model for handling templates and styles? Is inlining templates a reasonable solution? I'm looking for community input on how to balance performance and developer experience when deploying web components.
AppCache, while crucial for offline web apps, has significant issues. One major problem arises when integrating with APIs like registerProtocolHandler or registerContentHandler, which use query parameters. AppCache caches each unique URI, including query strings, separately. This is fine online, but offline, only previously cached URIs with specific query strings will work. Updating the app cache also causes every unique URL stored in the app cache group to be re-downloaded, even if they're not in the current manifest, potentially leading to server overload. This post highlights these issues and calls for better documentation and patterns for offline app development.
In response to a comment on Abhinaba's blog, I argue that verbosity in code is generally preferable, especially when defining enums. While Intellisense can be helpful, it shouldn't dictate design decisions. Enums should ideally be defined within the class they're used, unless they're shared across multiple classes from the outset. This improves code clarity and makes dependencies explicit. For example, separate FileFilter and DirectoryFilter enums within their respective classes are better than generic namespace-level filters.
This post discusses the best placement for enum declarations in C#. While some argue that defining enums outside the class avoids extra typing, I believe that placing them inside the class improves code clarity, reduces ambiguity, and makes it easier to handle similarly named enums from different classes. IntelliSense helps with the extra typing. The original article argues against this, prioritizing less typing, but I find that less important than clarity and proper scoping.
I finally took my own advice and watched the MSDN videos, specifically "Designing .NET Class Libraries: Member Types." I was impressed with the discussion on .NET class library design principles, especially regarding method overloading and cohesion. I highly recommend checking it out and plan to incorporate these best practices into my own coding.
