Can we have a document.templates for <template> elements with IDs:


<template id="temp1"></template>
<template id="temp2"></template>
<template id="temp3"></template>



All three above return the corresponding elements.

This helps with auto completion, and no need to use getElementById() and make new variables.

It’d be nice to have all my templates in one object document.templates

When HTML Imports are used they will automatically be added to document.templates as well

I’d rather just have this for all elements with IDs, on a sub-element of document rather than maybe-it’ll-be-overwritten-later access on window as we have now.

I’m aware that Global IDs exist, I was thinking of that which I do take advantage of.

Only thing I’ve read is that it shouldn’t exist because it can conflict with future global variables. Imagine someone had the following:

<div id="Symbol"></div>

Then boom! Came ES6 Symbols that they were never aware of would come in the future.

So I’m with you on that, and thought about it:


That would take care of it, and now I’ve never have to use document.getElementByID() again. Yay!

Yet I’d still like to seperate my templates, what would be possible yet not sure if wanted is:

<template name="temp1"></template>


It’d be nice to seperate my templates from the IDs even if I have an ID on them. Mostly because of autocompletion.

What document.templates and document.IDElements would return is the future Elements collection.

Browsers used to automatically add elements to Javascript properties on document - such as document.all - but AFAIK this was widely regarded as a mistake and all features of that kind have since been deprecated or removed. I’m not familiar with the precise reasons why, but I thought I’d point out you’re suggesting something that seems to have already been tried and then removed.

Personally, I don’t think it’s a big deal typing getElementById anyway.

It’s not about how much typing, having a reference to the Elements is faster, even though getElementsByID() is already fast.

Also yes I agree those HTMLCollections were mistakes, same thing with NodeList which led me to writing my library NodeList.js and now Elements collection is coming.

Also about seperating your concerns, I don’t mind the IDElements because their always unique, I don’t like the document.scripts and document.links and document.forms because as a beginner I may get the thought of why not have one for each type element, which would be dumb, and more work for a browser and developer. That’s why you use getElementsByTagName() you could say the same with writing document.getElementByID() But ID elements would be perfect IMO.

But why get them through getElementsByID() if their always 1, compare to document.all which change. And yes when dynamically create another Element with an ID the document.IDElements would change as well, but again their unique. Which is really neat.

[quote=“Edwin_Reynoso, post:5, topic:1057”] It’s not about how much typing, having a reference to the Elements is faster, even though getElementsByID() is already fast.[/quote]

For what reasons do you think it will be faster? In which cases is getElementsById() not fast enough and why do you think this will solve the problem? I think it could in fact be slower since the browser has to maintain a large, dynamic set of Javascript object properties, and dynamic properties typically cause JS engines to de-optimise the object and put it on the slow path.

Slower?? really document.all already exist what do you have to say about that.

By the time document.all is dropped (which Idk it will) document.IDElements will be implemented making things faster because it will always be less elements than document.all

Just because doument.all already exists has nothing to say about its performance. I don’t know much about internal browser implementations to differentiate these two cases (although I think @AshleyScirra was on to something) , but if current browser performance is anything to go by… well…

Talk of performance is useless without measurements, thanks @nemzes for making some!

document.all[id] is completely different to document.IDElements[id]

and its a LIVE HTMLCollection so I’m not suprised that document.getElementById(id) is way faster (which AFIK is also optimized).

Which I didn’t even say that document.all is faster.

What’s faster is having reference to the Element already:

var el = document.getElementById('theElement');

function foo() {
 return document.getElementById('theElement');

function foo2() {
 return el;

Which one you think would be faster? In this above example, the difference probably aren’t even measurable. This is too simple of an example, the point is having reference to a value is always faster than getting the value again.

Just like how when we use a for loop:

var arr = [1000000000000x length] // an array with a length of: 1000000000000
for(var i = 0; i < arr.length; i++) {..}


for(var i = 0, l = arr.length; i < l; i++) {...}

I’m sure we all know that the second one is much faster and performant, and recommended, and its caching the value, so I still stand clear with my statement.

You want a jQuery example too??

$('div').css('color', 'red');
$('div').css('background', 'black');


var divs = $('div');
divs.css('color', 'red');
divs.css('background', 'black');

And yes I’m aware I can do:

$('div').css({ color: 'red', background: 'black'});

// or
$('div').css('color', 'red').css('background', 'black');

You are making underlying assumptions about the JIT which really can’t be made without proof. You are also making assumptions about how browsers would implement a feature which can’t be made either.

For me the development savings just are not there in convenience or performance to justify adding these.

1 Like

Making performance arguments without measurements, especially when measurements have already been provided, is going to be pretty fruitless. getElementById() is such an obvious optimisation target for browser makers that it probably has a lot of optimisation work already done on it including surrounding/calling code to eliminate redundant calls etc. So in fact I think it’s entirely plausible that getElementById() could be faster than your proposal.

For example you could probably implement IDElements in Javascript using ES6 Proxies, but… Proxies are slow!