Code sample and polyfills

[hemanth]

I would be useful to have sections for code samples and if any polyfill?

I am trying to maintain the code samples at es-next.

[codehag]

Hey Hemanth! Yes we are working on the code samples. This will take some collaboration with proposal champions. Would you like to get involved?

[xtuc]

There is also https://github.com/lukehoban/es6features. Also I made https://github.com/xtuc/link-to-babel-repl-generator if we want to try out the proposal in Babel's REPL.

[hemanth]

@codehag count me in!

[hemanth]

@xtuc https://jsfeatures.in too, a PWA ;)

[codehag]

@hemanth would you be interested in joining our monthly call?

[hemanth]

@codehag I would love to!

[ljharb]

I’d be very hesitant to have TC39 appearing to officially endorse polyfills; and using the MDN approach of having code inline would lead to the same problem it has (most of the polyfill code on MDN is substandard and not fit for production use).

[codehag]

Thanks for your input @ljharb, hopefully I can address some of your concerns. In regards to endorsement, polyfills are one type of implementation expected as part of stage 1 in the TC39 process to show the intended behavior (see stage 1 https://tc39.github.io/process-document/). This makes me wonder what you mean by "appearing to officially endorse polyfills" -- perhaps you mean that you do not want to see a specific set of non-proposal polyfills being used? or polyfills being written for proposals that may not be up to spec, but being authored just for the proposals? I am a bit hesitant here because I am trying to guess what you meant. Perhaps you have a more specific concern that I didn't quite understand from your comment?

To be clear, we haven't decided to use polyfills. In the above comments, there is a suggestion for having a repl to try out proposals. I understand your hesitation in trying to reproduce MDN's approach. I myself am also hesitant about bringing executable code snippets into the website at all. Dan and I had a discussion about how MDN does things in one of our calls, and specifically went over "not replicating MDN as MDN already exists". It is completely unrealistic for us to do this. If you like, you and I can have a 1:1 chat and I can go into detail about what we looked into.

Thinking out loud: This website is meant primarily to reflect proposals in a more accessible, centralized way. If we continue with this line of thinking, one idea might be make the polyfills of the proposals that have them more accessible. Instead of a user having to go to each proposal, checking if they have a polyfill, download it and set it up, we might have a REPL that has flags containing polyfills that are part of proposals for people to play around with. It is an interesting idea, as this would allow people who learn in a specific way (by trying out) to have a good central location to see what something might look like. It lowers the barrier. Since the goal of this site is primarily to help people understand the spec, it fits quite well, but is technically very challenging to keep up to date.

At the moment it is unclear if this specific part of this issue is realistic. I would say that the code samples are more important and what we should focus on. We need more hands on deck to come up with efficient ways of keeping the proposals up to date. Since we have someone here who is already maintaining a database, we might learn something. However, rather than discourage experimentation and brain storming so early in the process, I would like to see where this polyfill topic goes and what we can come up with.

Let me know if I missed what you meant with this topic. Happy to discuss further.

[codehag]

@hemanth we have a meeting on the last Tuesday of every month, are you on irc already? The channel we use is #tc39-website on freenode. You can find connection instructions here.

[hemanth]

@codehag Yes, I am on IRC. Will join there. Thanks!

[ljharb]

@codehag just like TC39 does not endorse or recommend a specific browser (a specific implementation), we should not be endorsing or recommending a specific polyfill implementation. If we list a polyfill, we have a duty to list every polyfill in the ecosystem, and I don't think that's a list we want to commit to maintaining - and if we don't do that, then we're "blessing" some polyfills over others.

[codehag]

@ljharb Ok, that lines up pretty much with what I thought you might be objecting to. Rest assured we are not planning on that! It is too much work.

The website is primarily geared towards exposing the proposals in a better way, so that people can grasp what is happening on the committee more easily. The proposal repositories are our source of truth and we will not deviate from it just to make the site interactive. If (and that is a big if) we at some point do include polyfills, it will be the ones that are already included in the proposal, in order to make the intention of the Champion more accessible to those trying to grasp the proposal.

[hemanth]

I noticed the _data dir with ymls.

Would it make sense to have a single proposals.yml and amend the attributes to have a stage key, based on which we can render it in the right section on the UI?

The advantage being that we can just change the stage value as a proposal progresses and it shall end up in the right section.

[codehag]

That sounds good to me, @xtuc do you have any thoughts?

[xtuc]

Yes, that sounds easier to maintain for us.
I hope the file will not grow too much even if we track every proposals. In #96 we're adding a lot of code, might be worth to consider using other .js files instead.

[codehag]

@hemanth thank you so much for the work you did here. I think this is closed out by #96 and we will be looking into the crawler separately, does this sound good?

[hemanth]

@codehag Happy to see that being merged!

Sure, we can plan for the crawler.

Meanwhile, it would be great if we could conclude on this.

[codehag]

@hemanth since we don't record other stages at the moment, I am not sure we need it -- It might be a good improvement if we decide to eventually include a page with all of the stages. What are your thoughts?

[hemanth]

@codehag Oh okies, I had missed that point, the only advantage I see with having a stage attribute in the data is that just changing the stage value would result in it landing at the required section.

[codehag]

ok, I will close this for now then. We can revisit at a later date