DEV Community

HTML Imports & Component-Driven Development

TJ Fogarty on September 16, 2018

This was originally posted on my blog. I was thinking about the process of building a site today vs maybe 8 years ago. When WordPress was called f...

Read full post

Benny Powers 🇮🇱🇨🇦 • Sep 16 '18

As discussed, HTML imports have been deprecated in favor of JavaScript modules. New apps should not use them.

There's an early proposal for HTML modules which might interest you.

github.com/w3c/webcomponents/issue...

TJ Fogarty • Sep 16 '18

Thanks, Benny. I suppose what I was getting at is exploring a potential replacement for depending on a server or build tools for this kind of stuff, which mimicked an older process I had. HTML Imports came closest to what I was looking for.

I'll read up more on this for sure, thanks for the link!

Benny Powers 🇮🇱🇨🇦 • Sep 16 '18

There's no need for a server or build tools when using javascript modules

<script type="module">
  import { makeDom } from './my-dom-module.js'
  const someDom = makeDom();
  document.body.append(someDom);
</script>

Easy peasy, lemon squeezy!

TJ Fogarty • Sep 16 '18

Ah ok, cool! Pardon my ignorance here, but how do I get a HTML partial out of the JavaScript module? Can I import HTML?

Benny Powers 🇮🇱🇨🇦 • Sep 16 '18

Great question, one that's inspired me to write a post on web components standards (watch this space!)

You could do something like

// partial.js
const template = document.createElement('template');

template.innerHTML = `
<div>
  <p>Here's my reusable partial</p>
  <button>OK</button>
</div>
`;

export function partial() {
  return template.content.cloneNode(true)
}

And elsewhere...

import { partial } from './partial.js';
document.getElementById('container').append(partial())

Take a look at the lit-html library for a functional way of building UI with template literals

import { html } from 'lit-html'

const messageBox = message =>
  html`<span class="message-box">${message}</span>`;

const showMessage = message =>
  render(messageBox(message), document.getElementById('container'))

TJ Fogarty • Sep 16 '18

Thanks for taking the time to give an explanation, looking forward to your post!

My experiment was to see if I could avoid complicating things with JavaScript, and reduce the barrier to entry for a developer working on styling up the front-end. I'll be interested in seeing how this space grows.

Benny Powers 🇮🇱🇨🇦 • Sep 16 '18

Yeah, that's exactly what HTML imports were designed for. The loss of that API was a pretty difficult pill to swallow, but the tradeoff is that web components are now standard across almost all browsers.

yucer • Sep 16 '18

Ohh, I think the next October 23th will be the 20th anniversary that Microsoft has proposed this to W3C under the name of HTML Components. It was available since IE 5.5.

I have tested it in the year 2000, creating an HTML component for the selection of date & time values (Calendar). The nice stuff is that you could also easily associate "events" to this components and reuse them easily in many pages and HTML tags, this way.

The problem is that the other browsers have not implemented it. The same might have happened with other standards like HTML+TIME. One drawback of standards is that everybody should implement them, otherwise they don't have success.

My guess is that the javascript community was in one stage where they wanted to have more freedom to implement such stuff in different ways. And maybe the lack of such implementations in the browser gave rise to the incredible amounts of javascript frameworks that exist nowadays. I like how the javascript components are implemented in Odoo

It is a kind of a trade-off. If you implement more in the browsers, they become complex (and hence difficult to implement) and there is less competition in the javascript frameworks. Maybe this aggressive evolution of Internet Explorer was the cause of its complexity, the amount of security issues and other negative stuffs in its story.

After that, I think Microsoft did put more efforts defining the components in the server side in order not having to deal with those delays in browser implementations. ASP.NET allows you to group the HTML, CSS and Javascript in an extensible unit called ASP.NET Control and reuse it many times. The engine make sometimes optimization according to the client browser.

I think you are right. Re-usability is the key word for the success, and component-ware is good way to achieve it.

Congratulations! Not every developer has the vision to look out-of-the-box. ;-)

TJ Fogarty • Sep 16 '18

Thank you, and great comment! Loads of reading material in there to dig in to.

Fabian Holzer • Sep 16 '18 • Edited

HTML imports have been deprecated, and they'll be removed from Chrome within less than a year. For packaging web components it seems that ES6 modules will become the mainstream approach.

TJ Fogarty • Sep 16 '18

Thanks, Fabian! I've added a link for that thread.

Max Cerrina • Sep 17 '18

I've done a decent amount with React and so am pretty familiar with components -- and they, and the other JS tools I've used similarly including "normal" browser-based script modules -- are just never what I want. Last year I did a ton with PHP and also JSP in school and side projects, and then work was very React-heavy; this current project, however, is Phoenix-based, which means I am back in the land of imports and includes and ... man, the JS-based stuff just doesn't hold a candle to it. I've rigged up some neat stuff combining React and traditionally-done server-side stuff like Phoenix etc and done some neat stuff with both (and, IMHO, they're a fabulous compliment to each other, as so much of the maddening "I just want a goddamn link to another page, this shouldn't be a huge issue" that is part of the single-page-app-ness is gone)

I totally get why you wanted to see what you could rig up yourself. I really prefer that style as well.