I like this proposal in principle. A few comments, in no particular order:

• Before formalizing, I thikn we should be explicit about supported browsers. ", etc" is not very actionable 😁 We may want to add a compatibility list/chart/grid somewhere.
• Do we have concrete examples yet where we're certain ES 2015+ will help GopherJS, or are the examples provided still hypothetical?

• Before formalizing, I thikn we should be explicit about supported browsers. ", etc" is not very actionable 😁 We may want to add a compatibility list/chart/grid somewhere.

This is exactly the question I was trying to dodge 😅 But since you saw right through it, here are my thoughts:

• I called out browsers that I'm reasonably confident will have a decent market share for the foreseeable future. We won't be able to ignore them anyway.
• I wanted to leave the list open because new browsers may become significant in future (e.g. Opera, Brave, or perhaps some Chinese browsers I am currently ignorant about).
• On the other hand, most of those browsers are likely to be either WebKit or Blink-based, so as long as Chrome supports a feature, they will too, with some lag.
• I am unsure if we can formulate an objective criteria that wouldn't require us to test GopherJS against 20 different browsers. Doing that would be lovely, but I don't think that either you or me have time to do so, and I'm not aware of any volunteers who could help us on that front. As such, I don't want to make promises I won't be able to keep.

If you can think of a better solution, that would be great :)

• Do we have concrete examples yet where we're certain ES 2015+ will help GopherJS, or are the examples provided still hypothetical?

I gave a few examples in the background section that seem very plausible to me and have been requested by our users. I can't say definitively that they will 100% work out, since they haven't been prototyped yet. Doing so would be a lot of work, so I haven't bothered without having this discussion.

However, I can give at least two examples of low-hanging fruits:

Reducing generated code size with destructuring assignments and object property shorthands.

Consider the following Go code:

func blocking() {
	x := 1
	y := 2
	runtime.Gosched()
	x++
	y++
}

Currently the generated code for this function looks like this:

	blocking = function() {
		var x, y, $s, $r;
		/* */ $s = 0; var $f, $c = false; if (this !== undefined && this.$blk !== undefined) { $f = this; $c = true; x = $f.x; y = $f.y; $s = $f.$s; $r = $f.$r; } s: while (true) { switch ($s) { case 0:
		x = 1;
		y = 2;
		$r = runtime.Gosched(); /* */ $s = 1; case 1: if($c) { $c = false; $r = $r.$blk(); } if ($r && $r.$blk !== undefined) { break s; }
		x = x + (1) >> 0;
		y = y + (1) >> 0;
		$s = -1; return;
		/* */ } return; } if ($f === undefined) { $f = { $blk: blocking }; } $f.x = x; $f.y = y; $f.$s = $s; $f.$r = $r; return $f;
	};

Notice the second and the last lines where we restore and save the local context when the function gets blocked. With ES 2015 syntax they could be rewritten in a more compact form:

blocking = function() {
  var x, y, $s, $r;
  /* */ $s = 0; var $f, $c = false; if (this !== undefined && this.$blk !== undefined) { $f = this; $c = true; [x, y, $s, $r] = $f; } s: while (true) { switch ($s) { case 0:
  x = 1;
  y = 2;
  $r = runtime.Gosched(); /* */ $s = 1; case 1: if($c) { $c = false; $r = $r.$blk(); } if ($r && $r.$blk !== undefined) { break s; }
  x = x + (1) >> 0;
  y = y + (1) >> 0;
  $s = -1; return;
  /* */ } return; } if ($f === undefined) { $f = { $blk: blocking }; } $f = {x, y, $s, $r}; return $f;
};

In this example, the ES 2015 syntax saves us 46 bytes of the generated code size for a function with just two local variables, and this will grow for more complex functions. For a real-life program this may add up to a decent few kilobytes of smaller output. I think lexical this could enable even more compact code, but haven't figured out all corner cases yet.

#136 has been the single biggest pain point called out in our user survey, so I assign a lot of weight to any improvement in that regard.

Proper implementation of the internal/intern package with WeakMap

Instead of hacking net/netip package in 7b2b95a we would be able to implement internal/intern package using a WeakMap and not worry about any future places that package may get used in.

A somewhat longer shot in the same vein would be using a WeakMap to assign actual integer values to pointers, which would enable a much better unsafe support. That ideal, however, requires a lot more design, which I haven't done yet, so I won't go into much more detail now.

This is exactly the question I was trying to dodge

Haha sorry. Well, I would be happy with a fairly narrow list of officially supported browsers. Chrome, Firefox, Safari, Edge, iOS, Android may be enough. (with the addition of version numbers/dates)

I would word our compatibility goals broadly enough, though, that it doesn't look like we aim only to support those, and that we expect many other browsers to work.

I am unsure if we can formulate an objective criteria that wouldn't require us to test GopherJS against 20 different browsers.

I agree, I don't want to get into the business of running tests (manual or automated) on 20 browsers. We haven't needed that yet, so I think we should avoid it.

To that end, I'd suggest we word the supported browser policy something like "We give priority to bug reports against supported browsers."

Updated to:

Chrome (on Android and desktop), Firefox, Safari (on Mac and iOS) and Edge have had complete support of the standard for at least two years. Compatibility with other browsers will be taken into account, but won't be necessarily blocking.

WDYT?

Ping @flimzy.

So far it seems like no strong objections have been made. If none arise by the end of the next week, I will declare this proposal accepted.

Since no objections have been raised I am declaring the proposal accepted and that GopherJS 1.18 will be using some of the ES 2015 features to reduce the output size (I'm thinking about descructuring assignments primarily).

P.S. I was sort of expecting more debate, but perhaps very few people care about ES5 compatibility indeed :)