Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why can't HTML alone do includes?

frontendmasters.com

Post reply on HN
Print view View original

341–350 of 367 posts

Re: Why can't HTML alone do includes?

#341

Post by msie »

thayne wrote: post #159
simonjgreen wrote: post #150

I know it’s not straight HTML, but SSI (server side includes) helped with this and back in the day made for some incredibly powerful caching solutions. You could write out chunks of your site statically and periodically refresh them in the server side, while benefitting from serving static content to your users. (This was in the pre varnish era, and before everyone was using memcached) I personally used this to great…

One benefit of doing it on the client is the client can cache the result of an include. So for example, instead of having to download the content of a header and footer for every page, it is just downloaded once and re-usef for future pages

It’s amazing how people vociferously argue against this. If it was implemented we would be arguing over something else.

Re: Why can't HTML alone do includes?

#342

Post by NorwegianDude »

lelanthran wrote: post #334
NorwegianDude wrote: post #324

Earlier quoted context omitted.

Then you just pre-build the page before publishing it. It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests.

> Then you just pre-build the page before publishing it. That's "using a programming language to solve the problem", isn't it? > It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests. What work do client-side includes have to do other than fetching the page (which will get cached anyway)? It's less work to have a ` ` builtin than even a simple…

It does not have to be a programming language on the server, no, unless you want to. The server can have a static site, that you build as you deploy it.

Fetching another resource is expensive. It's another round trip, and depending on many factors it could be another second to load the page. And if the HTML includes other nested HTML then it can be much slower.

This is the exact thing we try to avoid when building websites that perform well. You want as few chained requests as possible, and you want the browser to be aware of them as soon as possible, with the correct priority. That way the browser can get the important stuff needed to display content fast.

Including HTML client side for templating is just wasteful, slow and dumb from a technical standpoint.

Every client would have to do another request for each include. It would literally be many thousands of times slower(or worse) than doing it locally where the templates can be in memory as you render the pre-render the pages. You also save a ton of CPU cycles and bandwidth, by not serving more files with additional overhead like headers.

Re: Why can't HTML alone do includes?

#343

Post by msie »

dfabulich wrote: post #218

We know why HTML alone can't do includes! In https://github.com/whatwg/html/issues/2791 the standards committee discussed this. The issue has been open for years. The first naysayer was @dominic: https://github.com/whatwg/html/issues/2791#issuecomment-3113... > I don't think we should do this. The user experience is much better if such inclusion is done server-side ahead of time, instead of at runtime. Otherwise, you…

I bet a lot of other features were implemented without as much forethought and we were ok.

Re: Why can't HTML alone do includes?

#344

Post by alabastervlog »

echelon wrote: post #217
int_19h wrote: post #183

Earlier quoted context omitted.

We also had a brief detour into XML with XHTML, and XML has XInclude, although it's not a required feature.

It's too bad we didn't go down the XHTML/semantic web route twenty years ago. Strict documents, reusable types, microformats, etc. would have put search into the hands of the masses rather than kept it in Google's unique domain. The web would have been more composible and P2P. We'd have been able to slurp first class article content, comments, contact details, factual information, addresses, etc., and built a wealth…

I kinda bailed on being optimistic/enthusiastic about the Web when xhtml wasn't adopted as the way forward.

It was such a huge improvement. For some reason rather than just tolerating old tag-soup mess while forging the way for a brighter future, we went "nah, let's embrace the mess". WTF.

It was so cool to be able to apply XML tools to the Web and have it actually work. Like getting a big present for Christmas. That was promptly thrown in a dumpster.

Re: Why can't HTML alone do includes?

#345

Post by msie »

mixmastamyk wrote: post #177

Lots of rationalization in here—it's always been needed. I complained about the lack of when building my first site in '94/95, with simpletext and/or notepad! It was not in the early spec, and seems someone powerful wouldn't allow it in later. So everyone else made work arounds, in any way they could. Resulting in the need being lessened quite a bit. My current best workaround is the tag, which has a few better defau…

Some people are too smart for their own, and ours, good.

Re: Why can't HTML alone do includes?

#346

Post by lelanthran »

NorwegianDude wrote: post #342
lelanthran wrote: post #334

Earlier quoted context omitted.

> Then you just pre-build the page before publishing it. That's "using a programming language to solve the problem", isn't it? > It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests. What work do client-side includes have to do other than fetching the page (which will get cached anyway)? It's less work to have a ` ` builtin than even a simple…

It does not have to be a programming language on the server, no, unless you want to. The server can have a static site, that you build as you deploy it. Fetching another resource is expensive. It's another round trip, and depending on many factors it could be another second to load the page. And if the HTML includes other nested HTML then it can be much slower. This is the exact thing we try to avoid when building we…

> It would literally be many thousands of times slower(or worse) than doing it locally where the templates can be in memory as you render the pre-render the pages.

Yeah, it's not. I'm doing client side includes and the includes get cached by the browser. I'm sure I would have noticed if my pages went from 1s to display to 1000s to display.

If you have a site/webapp with (say) twenty pages, that's only two extra requests for both header and footer.

Re: Why can't HTML alone do includes?

#347

Post by NorwegianDude »

mikeg8 wrote: post #326
NorwegianDude wrote: post #324

Earlier quoted context omitted.

Then you just pre-build the page before publishing it. It's way cheaper as you do the work once, instead of every client being much slower because they have to do additional requests.

An additional requests for html isn’t slow, and now I have to have a whole “build” process for something that is basically static. Not ideal

Well, that very much depends on your definition of slow, doesn't it?

An additional request is another round trip. That can be very slow. Average TTFB on the internet in the US is ~0.7 seconds.

It's much faster to send it as part of the same request as you then don't have to wait for the browser to discover it, request it, wait for the response and then add it.

A build process does not have to be complicated, at all. If you can write HTML then using something that can simply read the HTML includes you wish existed and swap it with the specified filename is trivial.

Ofc, the idea has many other issues, like how to handle dependencies of the included HTML, how to handle conflicts, what oath to use and many more.

Re: Why can't HTML alone do includes?

#348

Post by nitwit005 »

This seems to be forgetting the need to render other site's content. That's the main reason for iframes to be used, as people need to render ads, email previews, games, and so forth, without potentially breaking the rest of the page.

The "extremely awkward" aspect they complain about is a side effect of needing to handle that case.

You could add some nicer way to include content for the same domain, but I suspect having two highly similar HTML features would be fairly awkward in practice, as you'd have to create a whole new set of security rules for it.

Re: Why can't HTML alone do includes?

#349

Post by bazoom42 »

immibis wrote: post #275
int_19h wrote: post #250

Earlier quoted context omitted.

Me personally, I didn't even care that much about strict semantic web, but XML has the benefits of the entire ecosystem around it (like XPath and XSLT), composable extensibility in form of namespaces etc. It was very frustrating to see all that thrown out with HTML5, and the reasoning never made any sense to me (backwards compatibility with pre-XHTML pages would be best handled by defining a spec according to which t…

If XHTML was literally just HTML but with XML syntax, it would be pretty cool.

It is.
Post reply on HN