Thanks, I’ll certainly check out the gophers community.
As the sibling points out babel/webpack are like compilers of JavaScript world so reducing compile times have a huge impact on developer experience.
I am just wondering where does the complexity of juggling various ES* standards go? Also, the webpack plugins and loads of config examples might require this project to support additional complexity. Will the compiled/typed nature of Golang make it difficult to correctly maintain parity with babel/webpack?
I am really looking forward to learning golang this year. I am almost done ~~suffering~~ learning JavaScript/React + CSS3/media-queries this winter.
Browsers lag so hard behind the ES standard that most developers are using shims provided within Babel or Typescript to use the features early. Normally you specify whatever ESNext features your using in your tsconfig, webpackconfig, babelrc, etc.
I'm not sure if the implementations are always formalized such as the shim you use is identical to whatever implementation that major browsers end up going with.
Ultimately you just end up bloating your bundle because you need added code in your shims for backwards compatibility of these advanced features.
Thanks, I’ll certainly check out the gophers community.
As the sibling points out babel/webpack are like compilers of JavaScript world so reducing compile times have a huge impact on developer experience.
I am just wondering where does the complexity of juggling various ES* standards go? Also, the webpack plugins and loads of config examples might require this project to support additional complexity. Will the compiled/typed nature of Golang make it difficult to correctly maintain parity with babel/webpack?
I am really looking forward to learning golang this year. I am almost done ~~suffering~~ learning JavaScript/React + CSS3/media-queries this winter.