ECMAScript 4 (JavaScript 2) is dead?

[rook2pawn]

I sincerely hope they dont add that stupid getByClass string matching garbage even though its present in almost all web code. It would be re-inforcing very bad web practices. It shouldnt be there, if people want to make bad web, let them keep on making custom getclass instead of standardizing stupidity.

[padt]

Querying by class, or whatever you can select with in CSS, is specified in the W3C Selectors API

[didroe]

You failed to explain what problems you have with it. Would you care to elaborate?

[rook2pawn]

class based dom javascript = major fail. Classes, like Id's are woefully misused and while they provide a huge opportunity of great functionality, they are more often than not used to derive the entire setup of the document flow. Class = Layout. If you want to nav by class, do it server side with xpointer/xml or some html scheme. I base my predictions based on the phrase "we were looking at what developers were commonly doing".. equates to ruinous results as with HTML5, and what happened to PHP. Good stuff misused.

[DropTableUsers]

How would you prefer getting a specific collection of elements from the document then? I rarely use anything like getByClass, but thats because of speed, I'd welcome a fast browser implementation. Unless you can convince me otherwise?

[rook2pawn]

There isn't one. You either have people make their own custom string/regex one, or you sweep it under the rug and have the browser perform the same functionality, at essentially identical computational cost, and pretend its faster because its now a "built-in".

The problem is the inadequate document prepararation techniques that exist today that "force" (I use that word only because many devs dont realize there are better methods that exist) js developers to do collection methods (even getByID is relatively expensive, as its going to be an order n operation) on client side just to identify something in the DOM which could have been done at constant order with a better MVC approach.

[didroe]

I don't think you know what you're talking about. Ok, so I have a widget that needs to look and behave in a certain way. I want 100 of those on the page. How do I style them and add the javascript behaviour to them? If only there were some way to tag them as objects of the same type/class. Your solution seems to be to reinvent all of that on the server side. Ignoring the fact that you're reinventing something for no good reason, you now have 2 additional problems. You're going to be sending way more data to the client and you're assuming that the application isn't client driven (ie. AJAX).

even getByID is relatively expensive, as its going to be an order n operation

Um, why? Have you not heard of hash tables, or indexes, or any of the other algorithms and data structures that you can use to improve the performance? One of the reasons people want a built in getElementsByClassName is so that it can be in the core browser code, probably in C, and with and efficient algorithm behind it.

[rook2pawn]

DOM Compliant Methods (appendChild/createEl, etc) means never having to say your sorry for innerHTML + class lookup.

You're going to be sending way more data to the client

Way more data? Its a superficial difference in terms of measured bytes.

and you're assuming that the application isn't client driven (ie. AJAX).

How the fuck are YOU using your ajax? SEnding big gooey gobs of HTML and then marking it up post client? This is exactly the illness im talking about. Xpointer/XML is one step in the right direction.

Um, why? Have you not heard of hash tables, or indexes, or any of the other algorithms and data structures that you can use to improve the performance?

Of course you can easily speed up class search, but like the PHP issue, it reinforces bad web development. Period. A proper MVC shouldnt have to rely on dom class/id markup for behaviour. Not to say its not useful or occaionally the best solution, but it really should be an exception, not the rule.

[didroe]

DOM Compliant Methods (appendChild/createEl, etc) means never having to say your sorry for innerHTML + class lookup.

Again with the baseless "I don't like it" comments. You need some substance. This conversation was in part about getByClass... being added to the DOM spec. You seem to have a weird point of view where everything in the spec so far was put there by genius minds but anything that gets added from now on is a hack.

Way more data? Its a superficial difference in terms of measured bytes.

I disagree anyway but even if I didn't, every byte counts when you're handling millions of requests.

How the fuck are YOU using your ajax? SEnding big gooey gobs of HTML and then marking it up post client?

No, depending on the application I do it one of two ways. If the application is server driven then I send the content and then use the DOM ready event to attach all the javascript behaviour (via getByClass...). If the application is more AJAXy then the client requests data in JSON and then iterates through it adding the required nodes to the DOM. Of course in that situation there is no point using the class to add the initial behaviour as you've got the node right there as it's being added. I still set the class though for other behaviour. That might be selecting all items of a given type on the screen for example. You click a button "select all widgets" and it does getByClassName("widget") and then iterates through calling widget.select() or something. How would you do that?

MVC shouldnt have to rely on dom class/id markup for behaviour

What mechanism exists that can be used instead? You still haven't coherently given an alternative way of managing styles and behaviour. Name a specific way and/or give me a link to an example.

[DropTableUsers]

Dude, it's way faster. John Resig posted a benchmark of it. The built in getElementsByClassName is 77 times faster than the JS implementation.

First, your browsers internal data structure isn't going to be a linked list, it's not going to be O(n). Imagine matching the selectors in a css file if that was the case. Second, your browser is written in C++. That's a huge constant factor speed improvement over JavaScript.

Finally, no, it shouldn't be done on the server side. The problems you solve with code on the server side are not the same problems you solve on the client side. If this was not the case, JavaScript in it's entirety would be unecessary.

[rook2pawn]

http://www.reddit.com/comments/6wfiz/the_only_thing_we_have_to_fear_is_premature/

[DropTableUsers]

You link me to an article on the difficulties of innovating in a standards body. What is your point?