4 ms·

X in Go seems to be the new Y in Rust. I am curious to know what is the benefit of doing this in Go? I thought that the reason why webpack is complex is becau

by wadkar 7y ago

X in Go seems to be the new Y in Rust. I am curious to know what is the benefit of doing this in Go? I thought that the reason why webpack is complex is because the whole JavaScript ecosystem is complex with respect to the ES20XX standards. I fail to understand how rewriting the logic in another language is going to reduce the complexity. Speed is important, sure, but certainly not at the cost of correctness!

_bxg1 7y ago
Not sure anyone said anything about reducing complexity. Webpack and Babel in tandem are pretty much "the compiler of modern JavaScript". They do a lot of crunch work and can take a long time to run. Makes perfect sense to me to try and do that in a faster language.
tmpz22 7y ago
I think X in Go preceded Y in Rust by several years. In short Go is a simple language with minimal syntax and explicit design patterns that make it very easy to read and understand once you’ve learned the ropes. It’s a typed and compiled language with all the benefits that entails, with great concurrency support. It’s standard library is fantastic, compile times are great (one of the original goals for Go was to reduce c++ compile times at Google), with out of the box support for networked/web applications on the standard library. Finally the community for Go is very strong with things like the gophers slack channel which is insanely popular and friendly.
- wadkar 7y ago
  Haha, yes. 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.
  - tmpz22 7y ago
    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.
anderspitman 7y ago
You could potentially not need node installed in order to do "modern" frontend development.

by wadkar 7y ago

_bxg1 7y ago

Not sure anyone said anything about reducing complexity. Webpack and Babel in tandem are pretty much "the compiler of modern JavaScript". They do a lot of crunch work and can take a long time to run. Makes perfect sense to me to try and do that in a faster language.

tmpz22 7y ago

I think X in Go preceded Y in Rust by several years. In short Go is a simple language with minimal syntax and explicit design patterns that make it very easy to read and understand once you’ve learned the ropes. It’s a typed and compiled language with all the benefits that entails, with great concurrency support. It’s standard library is fantastic, compile times are great (one of the original goals for Go was to reduce c++ compile times at Google), with out of the box support for networked/web applications on the standard library. Finally the community for Go is very strong with things like the gophers slack channel which is insanely popular and friendly.

wadkar 7y ago
Haha, yes. 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.
- tmpz22 7y ago
  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.

anderspitman 7y ago

You could potentially not need node installed in order to do "modern" frontend development.