Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wonder why HTML never got includes.

It would be so nice to just write:

    <include src="footer.html">
On Hacker News, for the first pageview, this would load the whole "Guidelines | FAQ | Support ..." section. On all other pageloads, the browser would already have it in the cache. So it does not have to be loaded again.

Building complex websites would become so much nicer. Because each part of a page would be an include.



There are html "includes" in Chrome, used as such:

<link rel="import" href="/path/to/file.html">

But alas, Google was not able to convince other browser vendors to adopt them, and they will be removed from Chrome 75.


If you are looking for just a simple load some html and replace this where my <include> tag is kind of thing you are right, nothing does that because it’s more complicated then that... what about the styles of the included html? What about the behaviors (JavaScript) for it. How does that translate with the include?

But, if you use Web Components, organize your code, and plan ahead, this is very doable today with Web Components. You just create say a <reddit-footer> component complete with style and behavior, and then drop that into your page html along with an import of the component definition. It’s clean and simple and the encapsulation of all your footer needs in one place is really nice.

ZephJS, the library I am promoting, or another Web Component engine, makes this even easier and allows your components to be bundle yup really nicely. ZephJS, for example, offers a cli bundler command that does this (via rollup) and it makes for a really clean component experience. https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...

B


    It’s clean and simple
How so? What is the Web Components equivalent of <include src="footer.html">?


As an example HN here on might structure things like this:

<script src="./hn-components.js"></script> <hn-header></hn-header> ... all the main body content ... <hn-footer></hn-footer>

To answer your direct question, the WC equivalent of <include> is the <script> tag. The <script> loads the component definition and all the resources related to them (See ZephJS for how this is super easy to do: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...)

<hn-header> and <hn-footer> are defined in the script. They carry with them all the content, layout, and behavior for those parts of the site. This provides a nice clean separation between the page and the header and footer pieces. Changing the header or footer becomes just changing those parts. This is absolutely easier then using react or angular for the equivalent kind of things. Does it provide all that react/angular does, of course not. But it is infinitely cleaner then using either. Especially with ZephJS (gratuitous plug).


    the WC equivalent of <include> is the <script> tag
I beg to differ. My <include src="footer.html"> would insert the html in the footer.html file. While <script src="components.js"></script> will execute javascript. Then the javascript has to somehow prepare magic so that <hn-footer> will be replaced by some html.

The link to the library you gave does not help here. Because I am thinking about browser technology here. What has to go into components.js (without using a library) to make <hn-footer> be replaced with the html in footer.html?


Because that would cause cascade of tens or even hundreds of http requests just to download the html.

On the other hand new JS modules work like that, this is less of a problem on http2 and also can be mitigated by tooling.


Frameset / iframe?


You are right. IFrame creates an almost but not totally isolated page-environment. So in a sense IFrames are 'web-components".

So what can Web-components offer over that? A simpler way of including them on a page with a single tag. Well, you must load the js-file too but a single js-file could contain multiple web-components I assume.

The whole (?) point of components is isolating the interface from implementation, encapsulation, which WebComponents does nicely by providing a standard way of writing methods of the underlying ES6 class.

We could say that WebComponents are smarter IFrames with a cleaner way to declare their interface.

Another great thing about WebComponents is extending existing tags which makes it easy to prototype improvements to existing tags. For instance I wonder if IFrame could be made better by creating a web-component that extends them?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: