> It’s a lot like using polyfills when needed.
Never thought of it this way, thanks for that! As is state in the conclusion, the study would likely be more convincing with ES6 and build steps. So yeah, ES5 is questionable :)
The only pain point of not building during development is when I need to pull in a third party dependency (since node and browsers pull from different sources; and import-maps is not is still not a standard), but if your are not using any third party dependencies, you should be fine.
Using ES5 is pretty much always a mistake in 2020.
That being said, the page still didn't load properly for me when I actually tried it in IE11, but it's not because of Object.assign.
Nobody writes ES5 because they want to; many developers are still forced to support Internet Explorer for one reason or another.
However, this number will only continue to decrease as time goes on, and it also has to be questioned for any specific product whether that number is bigger or smaller on average.
Both for the (near?) future when ES6 is near-universal and for projects that have the luxury of just ignoring older browsers even today, it would be nice to have a proof of concept project like this that uses modern ES6 features, since many of them address precisely the types of problems that many pre-processors also fix.
Template-strings, custom elements, etc. add a huge amount of possibilities for web-application development and imo should get way more attention outside of a small circle of excited people.
As for ES5 support, would you consider using something like Babel to be close enough to using polyfills to consider them? Transpiling ES6 into ES5 fixes your compatibility issue with ES6 just like I would argue adding a polyfill for WebP images would.