I’m beginning to think that the best thing for the future of JavaScript would be for TC39 to go back to a 5-10 year release cycle.

Yesss

What if companies had to pay $$ per feature in addition to the TC39 membership :)

I've felt at least some kind of choke point toward the latter stages would be helpful. A time where we can apply some amount of vision and executive control over mostly finished proposals (ensure they work great together, have cohesive semantics, etc).

There exists a requirement to consider cross-cutting concerns, but the process could encode this more forcefully and ensure sufficient "bake" time is dedicated to uncovering and addressing these issues (even if no one knows of any issues prima facie).

In other words, some small yearly releases are maybe fine, so long as the pipeline is deep enough?

I think it would be helpful to make it clear to champions what kinds of progress can/should be made within bake time. For example, discuss with various stakeholders, experiment with non-shipping implementations. Just waiting in itself doesn't really serve much purpose.

"just waiting in itself" isn't what anybody is suggesting I think? You listed a couple of activities that seem good. Could add: consider proposal with others in the "wave", gather evidence on how the new thing plays together with other new things (or doesn't), vision alignment...

Yeah, I think those are good ideas. Implementing early (e.g., as a Babel early stage proposal) and doing studies with JS programmers, jointly with other proposed language features, could be a good common step.

In our current process, I feel like discomfort with the speed of progress leads some people to become really specific about their preferences. The way this is currently expressed in committee discussion often doesn't give a lot of actionable next steps.

I'd prefer if we could focus on discussing higher-level issues, like what sort of data and experience are needed to understand better whether the proposal should move forward.

Often, it's claimed that the champion hasn't thought cross-cutting concerns. This can be frustrating, as often the things have been thought about, but it's difficult to present them all clearly to the whole committee. Ask questions rather than attacking to make more progress.

High-level design issues are extremely important. If someone has concerns about the direction of a proposal, I hope we can make an environment where they can say that directly, rather than couching it as a technical issue with the proposal.

IMO the process doesn't set us up for success in this conversation. See also last meeting's "syntax budget" discussions. Without some framework under which to evaluate a proposal in a broader context and see very clearly what trade-offs are being made, we're kind of adrift.

I'm not even sure if this is a process thing; I think people get the idea that some topics are out of scope for what is an appropriate agenda item. You did well by organizing for those vision talks. What if we had a second set of vision talks to get more concrete?

Yeah, that's basically my suggestion here I think: : vision talks kick off a wave that proposals have to align with.

I think what you may be missing is the context — the long term plan. What is the purpose of adding new features. What is trying to be collectively achieved by the combination of features.

Right, it takes more than considering cross-cutting concerns. A good language design is a carefully considered set of features selected to be useful and powerful in combination. You can’t get there one feature at a time.

How about: 1. Keep yearly releases. 2. Define "waves". Waves are created by committee consensus up-front, have defined vision and scope, and represent a group of mutually beneficial features. 3. Proposals need to be bug fixes, very minor features (lib only), or in a wave.

Yes, something like that. The upfront plan is very important. I suspect that most TC390 delegates haven’t seen the plan that ES6/Harmony operated under web.archive.org/web/2010070121…

I've been so jealous of that plan as I've been working on class features. It'd be great to recuperate something like that. At the same time, I imagine we'll come up with the feature set differently this time, with input from a much broader group.

Note that the first version of that plan didn’t list any features. The plan guided the exploration and selection of features.

It's important to remember there there were enough flaws in that plan that TC39 quickly accepted the staged proposal. That said, at the time, we expressed worry about cross-cutting concerns, and it's time we revisited that question.

Maybe a group of the champions of class features, pipeline, null coalescing (I think those are the main cross cutting features) can get together to propose some changes to how proposals with that much cross-cuttingness go through the process?

I definitely like the idea of champions getting together and working out these issues, but I don't know if it needs to be all at once. From a technical perspective, I don't think there's much "cross-cutting-ness" between class features and the expression-related features.

The cross-cutting concern is the very nature of the language. What is JavaScript? What characterizes it as a unique language? What fits in and what does not?

There are some things we can discuss in plenary, about the whole language, and then there are more fine details that we can work out in groups that are focused on details on a group of closely related features.

At minimum, there's questions around whether sigils like # could be used in pipeline in light of their use as private. But I didn't mean that we should come together to discuss all the features at once, but rather ...

that we should get together to see what we could do to improve the process for these features.

I haven't been around enough to have a strong sense, but maybe there's a need for some periods where the language moves in big ways, and other periods where change is more incremental. Big steps, then consolidation.

I think we also need a stronger sense that a feature might be good in isolation, but nonetheless not gonna make it right now. Increasingly, it feels like a very serious personal affront to object to an early stage feature.

I personally try to push back against features I think are "good but not good right now" before Stage 2, and then focus on fine-tuning after Stage 2.

and not just “right now”. Not every good language features idea is necessarily a good fit to every language.

Part of that is figuring out how to demonstrate that you care about people and their use cases without taking their feature suggestions.

The idea of waves seems reasonable, but won't it be a constant battle and hard to figure out what goes in what waves. Might be good to look back and write down the principles and goals to start with... and then reconcile with the learnings from past and more.

Agreed, this is what I meant by "waves have defined vision and scope". If we work really hard to lay out the principles and goals in advance we can evaluate proposals against those goals. Of course it will be a debate, but hopefully manageable if we're all aligned in principle.

Suggested waves: - Standard library expansion - Functional programming/expression grammar - Class/object features v3 - Value types

We could form seven groups to work through problems--one for each of the above waves, plus groups for (some of these already exist) - Bug fixing/maintenance - Intl library - Inclusion/documentation Identifying new subgroups to form and solve problems is always welcome!

I like these categories, and I think subgroups would help the process a lot. It might be interesting to have the first day of committee meetings be a subgroup break-out, and then the next two days be group.

People can go to the subgroup of the proposals they care about, and the questioning actually gets more time and thought before being presented to the broader group.

I think that could eventually be a good structure, but I was wondering if we should start by organizing more calls outside of meetings to get these groups started, allowing people who can't make it to physical meetings participate as well.

We now have had regular calls for Intl, Code of Conduct, and documentation, and irregular calls for various aspects of class features. I think we can build on that experience to start.

If TC39 is going to have more small group meetings/teleconference then it needs to be more rigorous to ensure that minutes/meeting notes are made and distributed for those meetings. Such notes are important both for members who didn’t attend and for the historic record.

In my ongoing research on the history of TC39/ECMAScript I’ve found periods when such records where kept and periods where they were not, and for the latter it is very difficult to determine why and by whom significant decisions were made.

Perhaps it is time for TC39 to have a formally elected Secretary officer position who is responsibly for establishing and policing the record keeping process. I.E., not personally responsible for taking notes but responsible for making sure notes are taken.

has been our acting secretary with respect to notes taken in committee, and he's done a great job. @IgnoredAmbience has been setting up archives on previous TC39 websites, building on work from @Dherman. There's room for more; let us know if you want to help.

Thanks for the prompt, this was my plan for this afternoon.

You already archived the bugzilla tracker, and this has already been incredibly useful.

Getting it into a more useful format than raw xml was the plan 😊

Yeah, it's a bit difficult to read. That will be very appreciated. Sounds like time for some XSLT!

I don’t think that this is a volunteerism issue. It should be a formal leadership matter for the TC. Note ECMA talks about “Task Groups” (and defacto, that’s what these are) and requires reports from them be included in TC minutes.

I don't think Ecma requires all discussions that relate to the Technical Committee topics to be in Task Groups. I've discussed our informal groups with the Ecma secretariat, and my understanding is that TGs, Ad-Hoc Groups are tools Ecma makes available for when they are useful.

We are not making any final decisions in these meetings. Those all happen in the TC. Of course, I'd like these additional discussion groups to be as open as possible, and think we should go and publish notes and make sure they are available to whoever needs them.

It is a leadership responsibility to make sure notes and contribution documents are captured and archived. We (including me) have done a spotty job of this over the years.

At the least, the leadership should be regularly communicating (at each TC meeting) that importance of notes for all meetings, establish a place where they are submitted, and raise a concern if they aren’t being submitted.

Also all presentations to the the TC or an ad hoc group really need to be captured in a TC controlled place (TC39 github is fine). An offsite link to a private site isn’t a permanent record.

Very good point. I wonder how many links in previous agendas still work?

I bet a lot of them work. The time to archive all the linked slides is now! But also a lot of champions don't even link slides from the agenda; there would be another task to get in touch with all of them :(

Feel free to go through the notes, click on all of the Google slide decks, export PDFs and open a PR with all of the decks in the right directories. I will except the PR and forward the materials to Ecma

I used to ask for people to export and submit PDFs, but it was like herding cats and champions just didn't submit them. I just stopped asking when I started getting attitude about it… "But is in a permanent link better?" Whatever

But this does exist and I've been doing this post meeting submission process with Istvan for 6 years. Every meeting since May 2012 is archived

I was referring to reminding people to take and publish notes for side meeting as such as the electronic meetings Dan mentioned. Thanks for the great work on the regular TC39 meeting notes.

What I’m saying is that if you read the the Rules what you are describing sound a lot like an ad hoc Task Group. Regardless, the capture of notes is essential for tracking the source of contributions and decision making which is one of the purposes of a standards organization.

We've considered formalizing these as TGs and have so far decided to not take that step. The reasoning you stated is why we make sure that notes are taken at the meetings. For IPR protection, we require that non-member attendees of the Intl meeting sign our contributor form.

Lol, sorry @Dherman we meant @littlecalculist

That's basically me

Pre 2012 is definitely mysterious

We're taking notes at the regularly scheduled meetings, but we haven't gotten around to cleaning them up and publishing them for non-attendees. However, we've been updating public bugs and giving TC39 presentations which explain the results. I'd welcome help with notes!

This won't delay the current stage 2/3 class features we've all been waiting on though, will it????????? :)

I like this as a rough starting point for revising the process

and a standard library - you can't make that one function at a time randomly picked from community suggestions

Also FWIW I think this is happening anyway to some extent. Notice none of the new classes proposals has made it in to ES2018. They're all piling up at Stage 3!

I've been keeping this to myself for a while now... I completely agree.

I agree about an adjustment. However I think we need to take a critical retrospective look at ES2015 and see all the things that went wrong. I don’t think it was such a success story that we congratulate ourselves on in hindsight. We should avoid those mistakes.

I've said this before, and I'll say it again, the most problematic new features in JS, the most controversial features in JS, were all ratified *before* the new staging process.

I don't see a compelling stability argument for going back to old processes other than a knee jerk belief that "less change is more stable" which I just don't think is true given the history.

I'd appreciate some slowdown so I can consolidate my mastery of the new language. And it does feel like a totally different language now than it was even 4 years ago. Dunno if it needs to slow down that much again, though.

problem is that it takes minimum 5 years to have features widely available anyway, and transpilers will adopt any vomited idea from the community in the meanwhile, making that future even worst, imo 😅

what would be the main reason for that? is there any pressure to ship some features? 10 years is a lot though...

I mostly wish the release cycle was more thematic. Pick a few parts of the language and focus all the minds on it instead of 20+ scattershot proposals

I hear ya evan.

How about 15? Is 15 good for you?

Possibly interesting idea, but ignores the fact that people including Babel and even Chrome itself will go barreling ahead with new ideas, not to mention TypeScript iterating rapidly, so the likely outcome would be the complete marginalization of TC39.

Last few years were vital to make js more mature and competitive against other languages. Lambda and sugar syntax for classes were really needed. You did an awesome job. I think we can slow down now 😁

Nobody is forcing you to use the new stuff, you can still use ES5 only if you want 😄👍

Only after the pipeline operator is good to go

I've thought the same since loong time ago :)

But I don't think that #JavaScript would be as world eating and an evolutionary specimin if we didn't have the process we have today. Quick, tight feedback loops are super super powerful.

JavaScript was already well on its way to be "world eating" with ES5, I'd argue time had more of an impact than ES6 or anything else that happened since ES5

IDK, you can't chalk all of JS's growth to the growth of the Web, or vice versa. For most of the period of stagnation there was also not much ecosystem building compared to now. jQuery and Dojo built a fraction of the reusable libraries we see in modern ecosystems.

You also had the rise of new proprietary ecosystems on "native" mobile that may have won if not for improvements to the web and the explosion of the JS ecosystem.

Only two things changed in the interim: JS language evolution and Node.js/npm. Without those the landscape would be totally different.

I wholeheartedly agree on the Node/npm front. Both of these were major improvements over what we had before. Node (browserify) proved a huge boon to the ecosystem because in combination with npm it meant reusability to a degree that was previously unimaginable. ES6? Meh

I think that the modern iterative improvements to JS we've seen post-ES6 will be harder to correlate directly to growth, but I don't see a compelling argument that stagnation would not slow growth given we are not in a vacuum and other languages are evolving.

I don't think stifling growth is the answer either. I am only contesting the "ES6 made JS what it is today" point. If anything, ES6 was informed by nearly a decade of postponed changes to ES plus real-world usage in cases like React as you mentioned earlier

Long release cycle would also screw TS and flow in that they would have to strike out on their own

That said, TC39 seems to be focusing on wrong thing a bit. Just give us |>, ?. and class fields and then take a years break

Add decorators and yeah, I agree. Take a few years off at that point - they’ll have earned it.

Then attribute the current growth trajectory to Node and React, both of which came out before ES6?

React implemented many ES6 features in tooling so I don't see the argument for it being categorized as pre-ES6. If you are arguing that we don't have a lot of post-ES6 features to attribute growth to I would say that you just need to give it time.

It predates the current model of yearly spec releases

It's not like we still don't have everything other languages are doing to inform each spec.

Don't forget npm. That played a HUGE part IMO.

Absolutely 100000%.

Certainly. twitter.com/nzgb/status/98…

Heck no; what happens when a supposed change in such a situation ends up being bundled up with so many contested things all at once to the point everyone involved w/ TC39 figuratively take their ball and go home (arguably associated with what happened to ES4)?

Could you please explain the reason?