Cataloging ECMAScript #579
Comments
|
@Elchi3 thank you so much, I thought that would be a massive undertaking, and maybe it was, but you sure did it quickly! Looking at this tells me that "Why not have both" from #558 is the right path here. We already have an entry for Flattening Arrays, and that's part of ECMAScript 2019 apparently. My main question at this point is whether we should map at the level of BCD or in web-features. In other words, should we record that BCD's When we have a high level feature that fits in a group like ECMAScript 2019, why not just associate those? But if there are ever cases where a feature straddles ECMAScript releases, and developers nonetheless think of it as one feature, then we'll need to deal with it some other way. Building on #217 (comment), I'm inclined to suggest something like this. First, the tree of groups we'd define Then, the When needed, BCD could also use the tag "web-features:group:ecmascript-2019" to put individual BCD entries into a group. @Elchi3 WDYT? Is it messy to split this across web-features and BCD like this? |
|
If we go with groups as distinct from features, we need to decide whether groups are a namespace or not. In other words, should consumers of web-features have to use "group:ecmascript-2019" or similar to point to a group? It comes down to whether it's good that it's obvious at the "call site" that it's a group and not a concrete feature, and I think it probably is. |
Yes, as always, 90% is easy and then the remaining 100 or so data points aren't as easy to sort. I ignored all non-standard features in the end as well. Still some more things to sort. Can be seen in this branch mdn/browser-compat-data@main...Elchi3:browser-compat-data:ecmascript-tags (I forgot the link in my initial comment above, added now and also updated the data above with the latest cataloging for ECMAScript version snapshots).
I think, given BCD is a moving target and the source of all this cataloging, I find all this easier to do with BCD tags. The synchronization between the two will be work otherwise. But I could be convinced to do it in web-features. I think we are still at the phase where we explore what data model we need to have (more below).
To me, so far, it was really useful to associate an ECMAScript snapshot version with individual BCD data points. See Array above. Just by looking at that, you can see how Array evolved and you can determine Array features from there (like I did in my step 3 above). And, yes, there are features that straddle ECMAScript releases, and so the snapshot tag is optional but useful in case we have it.
To me, snapshots are different to groups. In fact, I think I found it useful to think about three things as my data model in my cataloging exercise:.
I played with this in BCD and it looks like this: Array.at: Commit: mdn/browser-compat-data@89722af Now you can do interesting queries against BCD:
|
|
I see, it does make sense to think of spec snapshots differently from groups. For example the HTML5 snapshot would certainly span multiple groups like "workers", "form controls", "media elements", and so on. I wonder if web-specs might make more sense than web-features as the source of truth on snapshots. Have you checked if older spec snapshots are recorded there, or is it only current specs? I also wonder about consumers, do you think BCD consumers would make use of snapshot data? |
From what I can tell, it doesn't record snapshots. It would be an idea to get the list of allowable snapshots from web-specs indeed. I don't think we want to make up our own snapshots (I think indexed-db-1 and indexed-db-2 are real levels observed from the specs, and e.g. CSS4 is also officially defined as a kind of snapshot). So, yes, maybe we could propose this for web-specs and use it for validation for the
Yes, I think tags are powerful to any BCD consumer because currently you only get lists of BCD features by tree (e.g. javascript.builtins.array.*). If we had the three tags that I described, you could already get much more nuanced feature lists as described in my comment above and without having to go through other data sources like web-features. |
|
We discussed the feature vs. group vs. snapshot idea at yesterday's WebDX meeting: https://docs.google.com/document/d/1ree75ImLZjf60lTZ3BhCaLHygxgywr7SBXp-q0xPs8A/edit#heading=h.tm9h5efbalpr A few highlights from the discussion:
|
A lot of complexity comes different browsers shipping things in different order and bundles. I'm sure that all of the following happen for two granular APIs A and B that seem like they form a reasonable group at first:
And so on. A problem is that if we base groups on bundles of shipping, then when another browser ships only part of it, we need to split that feature group. Some amount of updating to match reality is reasonable, but I think trying to determine how and when to split manually and picking good names for the feature groups is going to be overwhelming. Rather I think we'll need to find a way to handle small amounts of "skew" in a way that doesn't require minting new features for every unique combination of "initial support" versions. This kind of thing has already been a problem with at least Clipboard API, custom elements, the input event, and scrollbar-* properties. |
|
I got to have lunch with @Elchi3 today and we had a very wide-ranging discussion, but we talked a lot about this issue specifically. I will not attempt to recap everything, but I thought I would share some things that I learned: Terminology: We had a hard time talking about this because the terms are unclear. Specifically, "feature" is overloaded: everything's a feature, at different resolutions. For the purposes of our conversation, we settled on
Bundling: Talking to Florian, I finally understood what he meant by "combin[ing] the high-level capability groups with the snapshots." Florian is concerned (rightly) that if we start authoring bundles we might very well compose groups that are ungrounded (e.g., "Daniel's favorite Array methods") or motivated (e.g., seeking specific Baseline statuses or mapping to browser engineering's incremental steps toward a genuine feature), instead of descriptive. I originally misunderstood, thinking that Florian was suggesting (for example) "Array x ES2024" is a group that must exist, given the plausibility of the other two groups. Instead, the intersection might help us author the most meaningful bundles we might find in that intersection. This seems like a great way to unblock certain discussions about whether a feature is or is not in a given feature (e.g., whether to omit a given BCD key or to override a Baseline status and so on). This might help guide us in deciding whether to (as @foolip says above) skew or split a bundle. Scaling: This struck me as especially important in the absence of developer salience. The bundles needed for the most visible features and proposals will be pretty transparent to developers (e.g. developers themselves will have a good sense of what is and is not "subgrid"). But when it comes to cataloguing the whole of the platform, drawing boxes around features becomes much more difficult: do we really expect developers to make clear distinctions between older cohorts of features? Using the intersection of snapshots and capabilities can give us a starting point other than vibes or recapitulating dubious legacies (e.g., wiki-era MDN information architecture choices).
|
|
@Elchi3 The terminology shared by @ddbeck above mentions three levels (on top of the BCD key level of course). In the draft pull request you prepared, I see 4 types of tags:
What does the 4th type represent? Or is a leftover, to be replaced by |
Yeah, leftover. I didn't touch the generic |
|
Does someone have more context on bundles? If we adopt that terminology, would web-features not have anything called a "feature" any longer? Or are only some features bundles? (We have some entries which correspond to zero or one BCD key.) |
|
I don't have a good definition yet and I'm not sure bundle is a good name for it but calling these things bundles was easier in this discussion because "feature" is already overloaded. We could also say I guess the core of the problem is not really the name but missing guidelines about what goes into a bundle/feature-set and what doesn't. To me, a bundle consists of one or more BCD keys that we can reason about as a logical/evolutional extension to the web platform. I think it would be good to agree on some rules what "logical/evolutional" means. To me,
I'd love to hear how others approach bundling things together. Would definitely help me to catalog/bundle all of ECMAScript. |
|
Agreed that the name isn't the issue here. In fact, if we manage to land on a clear definition for this, I'd love for this lower level to just be called "feature" again. Even if it's overloaded, as long as we define it clearly in the repo.
We need to think from a user's perspective which, I think, Can I Use does pretty well. For example, if "Can I use CSS Anchor Positioning yet?" is a question that a web developer is likely to ask themselves in an attempt to accomplish a particular task, then CSS Anchor Positioning is probably a feature/bundle. It's definitely a feature/bundle if CSS Anchor Positioning can't itself be broken down further into smaller features/bundles which we could ask similar questions about. For example, "Can i use colors on the web?" is a valid developer question. Does that mean Colors is a feature/bundle? No, because you can break it down further into "Can I use relative color syntax?". This question makes sense from a web developer's perspective. They've heard of relative colors, have a need for it to accomplish a given task, and want to know if they can use it. |
I'm not sure I agree with this. I think bundles ought to be descriptive of web developers' view of the platform. I think it's very likely that most bundles are logical or evolutionary—and that's probably a safe default in the absence of other information about web developers' perspective—but I think it's possible for them to be arbitrary. Imagine it's 2007 and some web developers are thinking about AJAX. Such a bundle would probably have something like It's not hard to imagine descriptive groups having meaning in 2024. For instance, we might want to map to historic caniuse features (approximately, "Alexis's best judgment at the time he created the feature on caniuse") or a blogger might coin a term relating to a development pattern that catches on (probably not me, but I bet there are certain versions of " |
I think if we want to catalog the web platform it requires a Birds Eye view down to the individual features. So I thought it'd be a good exercise to do that with everything defined in ECMAScript as it doesn't really interfere with the other technologies (unlike HTML, CSS which have API reflections etc.). I removed
TemporalandIntlout of the discussion for now and then this exercise is about how to sort 901 features present in thejavascript.*BCD tree. I would love to hear what others think about how to catalog ECMAScript.I'm building on the idea of snapshots and capabilities in #558 (comment) and I'm using BCD's tags. A branch with tags applied to BCD can be found here: mdn/browser-compat-data@main...Elchi3:browser-compat-data:ecmascript-tags
First, I came up with snapshots tags (in BCD I tagged them as
"web-features:ecmascript-1"etc. but we could also make clear these are snapshots by using a prefix or so:"web-features-snapshot:ecmascript-1"). I went through the specs and categorized ~750/901 features by their snapshot (rest TBD):ECMAScript 1 (194 features)
ECMAScript 3 (79 features)
javascript.builtins.Array.concat
javascript.builtins.Array.pop
javascript.builtins.Array.push
javascript.builtins.Array.shift
javascript.builtins.Array.slice
javascript.builtins.Array.toLocaleString
javascript.builtins.Array.unshift
javascript.builtins.Date.toDateString
javascript.builtins.Date.toLocaleDateString
javascript.builtins.Date.toLocaleTimeString
javascript.builtins.Date.toTimeString
javascript.builtins.Error
javascript.builtins.Error.Error
javascript.builtins.Error.message
javascript.builtins.Error.name
javascript.builtins.Error.toString
javascript.builtins.EvalError
javascript.builtins.EvalError.EvalError
javascript.builtins.Function.apply
javascript.builtins.Function.call
javascript.builtins.Number.toExponential
javascript.builtins.Number.toFixed
javascript.builtins.Number.toLocaleString
javascript.builtins.Number.toPrecision
javascript.builtins.Object.hasOwnProperty
javascript.builtins.Object.isPrototypeOf
javascript.builtins.Object.propertyIsEnumerable
javascript.builtins.Object.toLocaleString
javascript.builtins.RangeError
javascript.builtins.RangeError.RangeError
javascript.builtins.ReferenceError
javascript.builtins.ReferenceError.ReferenceError
javascript.builtins.RegExp
javascript.builtins.RegExp.RegExp
javascript.builtins.RegExp.exec
javascript.builtins.RegExp.global
javascript.builtins.RegExp.ignoreCase
javascript.builtins.RegExp.lastIndex
javascript.builtins.RegExp.multiline
javascript.builtins.RegExp.source
javascript.builtins.RegExp.test
javascript.builtins.RegExp.toString
javascript.builtins.String.concat
javascript.builtins.String.localeCompare
javascript.builtins.String.match
javascript.builtins.String.replace
javascript.builtins.String.search
javascript.builtins.String.slice
javascript.builtins.String.substr
javascript.builtins.String.toLocaleLowerCase
javascript.builtins.String.toLocaleUpperCase
javascript.builtins.SyntaxError
javascript.builtins.SyntaxError.SyntaxError
javascript.builtins.TypeError
javascript.builtins.TypeError.TypeError
javascript.builtins.URIError
javascript.builtins.URIError.URIError
javascript.builtins.decodeURI
javascript.builtins.decodeURIComponent
javascript.builtins.encodeURI
javascript.builtins.encodeURIComponent
javascript.grammar.regular_expression_literals
javascript.regular_expressions.backreference
javascript.regular_expressions.capturing_group
javascript.regular_expressions.character_class
javascript.regular_expressions.character_class_escape
javascript.regular_expressions.character_escape
javascript.regular_expressions.disjunction
javascript.regular_expressions.input_boundary_assertion
javascript.regular_expressions.literal_character
javascript.regular_expressions.lookahead_assertion
javascript.regular_expressions.non_capturing_group
javascript.regular_expressions.quantifier
javascript.regular_expressions.wildcard
javascript.regular_expressions.word_boundary_assertion
javascript.statements.do_while
javascript.statements.label
javascript.statements.throw
javascript.statements.try_catch
ECMAScript 5 (35 features)
ECMAScript 2015 (355 features)
ECMAScript 2016 (5 features)
ECMAScript 2017 (35 features)
ECMAScript 2018 (8 features)
ECMAScript 2019 (10 features)
ECMAScript 2020 (22 features)
ECMAScript 2021 (13 features)
ECMAScript 2022 (7 features)
ECMAScript 2023 (14 features)
ECMAScript 2024 (10 features)
Second, I came up with some capability groups. Here I'm trying to be user-oriented as I believe we want to show what the web can do (and ignore its evolution for a moment). I guess we want to ask: ECMAScript, what do you offer? And here we need to figure out how detailed we want to be. I drafted some high-level capability groups for ECMAScript. Would love to hear thoughts on these.
Third, we probably want to combine the high-level capability groups with the snapshots. One assumption we make is that the older/un-enhanced the capabilities are, the less interesting it is to break them down into sub groups. For example, the Date API has not seen substantial updates since ECMAScript 3 and so it is just the Date API as a whole without any meaningful iterations or new capabilities. For other high-level capabilities, like Arrays, this is very different. Here we probably want to break down what Arrays can do and since when; the snapshots help with that enormously. Compare Arrays and Date API:
Arrays
Date API
(As you can see, I have just exercised this for Array and Date for the moment and not for all high-level capabilities listed above, but I can do that if y'all think this is useful for cataloging ECMAScript in web-features.)
One thing to say here is that the snapshot tags are useful, but maybe they aren't as meaningful as we want them to be. Instead of using the ECMAScript versions/years, we could also tag them with smaller capability groups and break Array down into some sub groups like these. This is a lot harder and more work, though. Example for Array:
Okay, that was a lot. Thanks for reading this far!
Now: How would you group/catalog 901 ECMAScript features?
The text was updated successfully, but these errors were encountered: