Building towards a reusable, modular web

iFrame – Background and Use Cases

The iFrame or Inline Frame element is used to embed another HTML document into the body of the currently browsed page. This creates a nested browsing context in which useful content from third-party sites or services can be directly enclosed without much configuration. A second and related use-case for iFrames is to enable reuse of business logic already implemented in an existing web application as embedded widgets (think of real-time chat widgets).

Drawbacks of iFrame technology

There are, however, several drawbacks in using iFrames for either of the use-cases described. These include (and are not limited to):

1. The nested context created in embedded pages could result in decreased SEO credit for the host page, as search engines will attribute content to the iFrame’s source URL.

2. iFrames effectively create “browser windows” within the existing page, a potential User Experience nightmare resulting in unintended nested and vertical scrollbars if not carefully configured.

3. The isolated browsing context of an iFrame means that any link within an iFrame will redirect the iFrame’s location to that link, while remaining on the original host URL inside the web browser.

Despite these drawbacks, precautions can be taken to minimise and event eliminate problems faced.

The Promise of Web Components

Enter Web Components; a set of four web technologies to help developers implement customised UI controls which are strongly encapsulated (non-conflicting) and reusable (modular and composable).

1. The Custom Elements API enable custom HTML elements (named and defined with custom attributes/events) to be defined and used like any other element.
2. The Shadow DOM API allows an encapsulated DOM element which is attached to a host DOM element. CSS styles applied in the Shadow DOM will not bleed into the host document, and vice versa.
3. The HTML Templates API provides <template> and <slot> tags to easily markup UI for reuse, without rendering them.
4. The HTML Import API allows the import of Web Components from separate resource definitions.

Together, Web Components technology points towards a future of more streamlined, less repetitive (more DRY — don’t repeat yourself!), and extensible web application development. Weather widgets which have to “look and feel” different across multiple sites will no longer custom development in multiple projects. Instead, a custom <weather> element could be developed once and potentially imported, configured and run on any other site.

The Future is Now

Given the lofty promise of Web Components, the reality of limited developer tools and poor browser compatibility mean that this future will not be realised soon. As developers, we can only realistically target newer, feature-ready browsers like Chrome or Firefox, and not evergreen browsers which are still part of hard requirements set by clients. Choice is also limited when it comes to libraries and frameworks to build Web Components in:

• Create “Vanilla” web components using the “(non-)standard” Web Component APIs
• Polymer: library developed by Google to build and distribute web components
• Wrapping other web app libraries by registering Vue/React/Angular components as Web Components 
  • Vue-web-component-wrapper (Web Component as build target in Vue CLI)
  • Web-react-components

Hands-on @ Factorial and Conclusion

At Factorial, we combined our experience with Vue.js development in delivering two Web Components based projects. The first was a real-time chat interfacing integrated in a hybrid Drupal 7/Socket.IO setup. The second project was a reusable UI component library proof-of-concept targeted at progressive, decentralised design overhaul across a suite of existing web apps. The first-class developer experience the Vue.js ecosystem provides made creating reusable Web Components a breeze compared to “vanilla” or Polymer approaches. We hope that support for targeting Web Component builds will mature over time and across more frontend frameworks.

In conclusion, despite its shortcomings, iFrame technology looks set to stay for the foreseeable future. For the core use-case of embedding content like videos and maps, iFrame solutions are quick, dependable and well documented by providers. For more complex use-cases in building reusable and modular interfaces, Web Component technology is exciting and promising. It now requires a concerted effort from browser vendors, UI framework contributors, and us as web developers to drive Web Components forward.