Performance inquiry

[jasonkarns]

I'm curious what the current state of browsers is, with regards to attribute-based selectors. For quite a while, attribute selectors were nearly an order magnitude slower in IE. But I'm no longer aware if that's the case.

Has there been any research or benchmarks done to see what performance would be across the current browser landscape using this attribute-based approach? (Keeping in mind that selector speed is not limited to CSS since most client-side-heavy apps will be making heavy use of selectors for the JS component of the app itself.)

[Jayphen]

Well, that's a little comforting. I've started using it in a web app I'm working on & it's working out well… I have just been ignoring the performance issue (if one exists) for now.

[kevinpeno]

I don't believe it is practical for a standard to consider current performance as a requirement/limitation to development of the standard (though it should be documented). Primary reason is that User Agents (UAs) tend to optimize based on feature usage.

How do we know this? Classes are the perfect example of exactly this in CSS UAs. Classes, as defined in the standard, are literally a shortcut of the form [class~="classname"].

From CSS 3 Selectors 6.4. Class selectors

Working with HTML, authors may use the "period" notation (also known as "full stop", U+002E, .) as an alternative to the ~= notation when representing the class attribute.

If you look a couple of lines down, the non-normative examples describe *.pastoral as equivalent to .pastoral. However, because universal selectors (of which only element selectors are not) are so expensive and because of the prevalence of use for this shortcut, CSS UAs have improved performance for selection via class quite a number of times over the years (hell...only element and ID were worth using back in the day because of performance issues).

As such, I don't think it is right that any body should use current implementation as an indicator for the capability of standardization, unless current implementation is driving the standard itself (such as deciding on the best way to write gradients in css). To discount this idea as a failure because current implementations suck at using [attr] selectors is a terrible way to make progress happen. I mean, if that were the way to think, we'd still be stuck with IE6 "standards".

I'd suggest that this ticket's conversation keep to how the performance of current implementations can be tested and documented rather than whether this kills the project out of the gate. Anything else just comes off as naysaying, which is not conductive to the success of the standard.

[jasonkarns]

@kevinpeno :+1:

[hellomedia]

:+1:

[yuvii]

@kevinpeno

The need for this standard are nowhere near as the needs for classes. Comparing them is ridiculous.

Yes - the discussion should be about whether it kills the project. I'm sorry, but relying on browsers adapting themselves to your library instead of the other way around is naive and unrealistic.

You should be asking whether you are wasting your time on a useless tool instead of blindly going at it while saying it'll sort itself out somewhere along the way

[benschwarz]

This issue is so full of back and forth FUD.

@geelen spent the last few months working on the Coinjar site and application — its all written using AM as a single page angular app. I'd encourage you to test it on some low powered devices, your desktop… get an account, sign in and mess around.[1]

Its plain to see that this site which uses AM exclusively has no perceivable front-end performance issues. Certainly none that could be put down to the CSS selectors that are in use.

If you spend some time with @jonrohan's talk "Githubs CSS performance", you'll note that their performance woes came from styling code diffs with 48K(!) elements. They minimised the markup being used, as well as simplified the selectors that were in use and saw some huge performance gains. (Its a great deck, somewhat essential reading if you're commenting in this thread).

Your sites maybe probably don't have 48K elements present in the page, suffice to say that they do, then AM probably isn't for you.

However, for those who fall into the 98% case, may find that AM allows them to have a more maintainable, simple and elegant way to write components.

[1] I don't work for / on Coinjar, and have no commercial interest in mentioning their site/app.

[yuvii]

@benschwarz

Nothing of what you are saying is in any way contradictory of my point - I'm not saying amcss is bad for performance (though I have my reasonable doubts). What I'm saying is that if that doubt proves to be true, than you should definitely consider abandoning it because assuming browsers will adapt is unrealistic and (quite frankly) ridiculous.

[MaciekBaron]

We have already explained here why browsers simply cannot optimise for this concept (it is impossible for browsers to index every attribute of every node).

Performance is an issue. Reflow has terrible performance with AM.

Nothing will change in that aspect.

However simple websites might not suffer from these issues.

[hellomedia]

I suppose if this became a html specification, browsers could optimize for it (they could index attributes starting with am- ).

Scope is needed for css -- however, it's coming with web components.

[MaciekBaron]

Yes, but let's be realistic, it will never become an HTML specification, therefore performance will always be an issue; possibly small for some cases, but still. Lets not pretend this can be completely ignored.

[benschwarz]

@MaciekBaron, you've stated your thoughts (Thanks!) and it seems we're not aligned in our thinking. Its not that you're being ignored, its that your arguments have failed to convince us of a diabolical issue.

---

Browsers & devices getting better in the future is a given. I'm not relying on that, as you pointed out, it would be naive to do so. Browsers (and hardware) will get better and selector performance will be less of an issue. Theres no need to become fixated on "browsers will get better", because we're not.

I've/we've already stated that for a HUGE document, selector performance is really important. But, that for most cases it holds little to no significance (Which, as I pointed out @geelen was able to demonstrate on the coinjar site).

At this point its a matter of taste — we build for the web every day just like you do, and, we're concerned with performance on the web. However, we've deemed AM to be "safe" for the purposes that we've outlined (most things you'll ever work on). Its up to you to decide if its right for you and your team and deal with the consequences (much like the decisions surrounding including ANY library in your code).

Unless we've got some interesting insights here (No one has presented any since September), I'm closing and locking this issue. Ping me elsewhere if you've got something enlightening to say here.

In summary:

• Browsers are optimised for ID and class selectors, and will get faster on a whole. (Of course, we don't rely on this, but its still a fact)
• Micro optimisations are exactly that. Bigger wins can be easily made, and often aren't. (Start there, then tell me all the testing you haven't done on selector performance)
• We measured AM performance and deemed it acceptable for use (yes, even widespread use). We still recommend that you run your own benchmarks and decide for yourself. (Just like you'd evaluate adding a dependency to your codebase)
• Huge documents (48K elements) will likely be an issue with even simple selectors. (Especially when targeting large amounts of elements with a given selector).

[jasonkarns]

Speaking as the OP, I didn't want this issue to turn into a debate about purpose or viability or anything. My original goal for opening this issue was to have a single place to showcase (or at least raise awareness) of any performance testing and benchmarks that were made using the AM technique. I would love if this issue could at least result in a pointer to some documentation within the project itself where performance results and benchmarks can be collected and shared moving forward.

Thanks to the project owners for your work. This technique is interesting and if nothing else, at least showcases a different approach.

[curtisblackwell]

+1 for the close and lock. Nothing new is being added to the discussion.

[MaciekBaron]

Me and others also joined the conversation because we were surprised that performance issues weren't even mentioned anywhere and just wanted to explain the details to the authors of this project. Now that they fully understand the problem, hopefully they will add a paragraph about potential performance issues.

I think this whole project is nice to show an alternative approach, but personally I think there are too many problems with it. Regardless, good luck to the developers working on it.

[kevinpeno]

I'm with @jasonkarns here. My understanding of this ticket was for the purpose of creating documentation around, or at a minimum researching a way to document/test for, performance today as the spec is currently implemented. It is very common for a spec to provide such information, not as a negative for the spec but, for implementers to reference and optimize for. Having a starting point or tests to verify against are indeed necessary.

There's already a good amount of information in this ticket in that regard, it just needs to start to be organized. If we could just stop saying "this project is dead because of this" and start documenting the this's we'd be well on our way! (Hell, might even be well on our way to a transpiler).

I'd suggest not closing (since the issue isn't resolve), locking the conversation, and setting to PR requested or something.