5 ms·

I find it fascinating that the author is leaving one fringe language with a small community for another fringe language with a small community- in this case Buc

I find it fascinating that the author is leaving one fringe language with a small community for another fringe language with a small community- in this case Bucklescript. I've never found the productivity benefits of these JS alternatives worth the risk and cost. There is an understandable desire to move away from the messy reality of JS and it's browser friends, I get it. Having written many thousands of lines of CoffeeScript, experiments with ClojureScript and Elm, I see the appeal. But you can easily find yourself stranded. Following the herd is important if you want to hire and maintain projects for the long term.

hombre_fatal 6y ago
The upsides make more sense if your Webpack/JS tool chain was growing out of hand. For example, once you take on Typescript, you take on quite a bit of idiosyncrasies. And your Webpack config may grow pretty large over time. We have some hacks in our Webpack config just to avoid some thing like double ESLint/TS evaluation. And it all can start to feel quite precarious. We even found bugs in Webpack's circular dependency plugin. Meanwhile, Elm does a lot of this right out of the box. There's a point where you may be easily reducing complexity and idiosyncrasies by using a tool like Elm.
- tobyhede 6y ago
  I agree that opionated frameworks can reduce complexity. I was Rails for a very long time. But moving to a new language that you can't hire for seems like an extreme reaction to "our config is complex". One good thing about a mainline technology like TS is that thinga get attention. Manual config today may be supported feature in the future.
  - bravura 6y ago
    Isn't the real risk, in moving to a fringe frontend framework, not just that you can't hire, but that you run into some roadblock you just can't get around? That you have some abstraction leak or messy interactions with JS?
    - tobyhede 6y ago
      This too. And then you're only as good as the interoperability your platform is providing.

hombre_fatal 6y ago

The upsides make more sense if your Webpack/JS tool chain was growing out of hand. For example, once you take on Typescript, you take on quite a bit of idiosyncrasies. And your Webpack config may grow pretty large over time. We have some hacks in our Webpack config just to avoid some thing like double ESLint/TS evaluation. And it all can start to feel quite precarious. We even found bugs in Webpack's circular dependency plugin. Meanwhile, Elm does a lot of this right out of the box. There's a point where you may be easily reducing complexity and idiosyncrasies by using a tool like Elm.

tobyhede 6y ago
I agree that opionated frameworks can reduce complexity. I was Rails for a very long time. But moving to a new language that you can't hire for seems like an extreme reaction to "our config is complex". One good thing about a mainline technology like TS is that thinga get attention. Manual config today may be supported feature in the future.
- bravura 6y ago
  Isn't the real risk, in moving to a fringe frontend framework, not just that you can't hire, but that you run into some roadblock you just can't get around? That you have some abstraction leak or messy interactions with JS?
  - tobyhede 6y ago
    This too. And then you're only as good as the interoperability your platform is providing.