5 ms·

I shared your fear of toolchains, but with Webpack, Babel, and Hot Module Replacement, I've been won-over. Those tools make it painless to sculpt out a UI in r

I shared your fear of toolchains, but with Webpack, Babel, and Hot Module Replacement, I've been won-over. Those tools make it painless to sculpt out a UI in real-time, using the latest ES sugars and a sane module system. Webpack has Uglify built-in, so you can target a minified file for production. With Babel and JSX, you're still writing idiomatic JS, so you don't have the same lock-in problems you might with something like CoffeeScript. In my mind, it's a clear value-add with no observed downside. What's your hesitation?

mbrock 11y ago
Yeah, those things are nice and compelling. I've used them, often happily! Some of the new language features are hard to live without once you're used to them; I especially like async/await and the destructuring syntax. The flip side is simply that it's more technology, more stuff to learn, more stuff to keep running on your computers, and more potential bugs and strange interactions to run into. I don't like to talk about it in a negative way, because it can sound like I'm disparaging the technology. But, there are nice things about having your project be written in the actual language that the browser already supports. Like simply never having to think about transpilers. Of course once you've learned about tools like Webpack and Babel, you can use them to your heart's content if they make you more productive. I just wanted to emphasize to the person I replied to that you don't NEED any of them. Especially not to just get started. You don't need minifying until there's a problem with your page load time and until you actually know that minifying will help with that -- until then, it's strictly speaking a premature optimization. (Writing less complex code may be more important!) And so on. And "no observed downside" is not strictly true if you consider the cost of added complexity. For someone who is overwhelmed by infrastructural proliferation, it should be nice to hear that you can develop actual applications with just plain JavaScript and maybe a small Makefile.
- bsimpson 11y ago
  By "no observed downside", I meant once the toolchain is set up. Now, I get Hot Module Replacement and JS Harmony sugars for free, without having to worry about which browsers natively support which new features. Your point about perceived complexity/intimidation is a good one, but for me, removing cross browser inconsistencies simplifies development more than Webpack complicates it.
  - nostrademons 11y ago
    There's always a cost to complexity, and it's usually in interop. What happens if you want to share a quick technology demo with a non-technical person over e-mail? What if you want your business cofounder to be able to tweak CSS by herself, and not have to learn what "setting up a toolchain" means? What if you're leading a team (or worse, a department or company) of people who aren't familiar with the latest in the JS world, need to do minor tweaks to the frontend, but can't justify learning a whole stack of technologies for something they spend 20% of their time in? All of these are real scenarios from my professional career. I like Babel too and the bulk of my new development is in ES6, but ubiquity is a really nice feature for development tools, probably the nicest of all.

mbrock 11y ago

Yeah, those things are nice and compelling. I've used them, often happily! Some of the new language features are hard to live without once you're used to them; I especially like async/await and the destructuring syntax. The flip side is simply that it's more technology, more stuff to learn, more stuff to keep running on your computers, and more potential bugs and strange interactions to run into. I don't like to talk about it in a negative way, because it can sound like I'm disparaging the technology. But, there are nice things about having your project be written in the actual language that the browser already supports. Like simply never having to think about transpilers. Of course once you've learned about tools like Webpack and Babel, you can use them to your heart's content if they make you more productive. I just wanted to emphasize to the person I replied to that you don't NEED any of them. Especially not to just get started. You don't need minifying until there's a problem with your page load time and until you actually know that minifying will help with that -- until then, it's strictly speaking a premature optimization. (Writing less complex code may be more important!) And so on. And "no observed downside" is not strictly true if you consider the cost of added complexity. For someone who is overwhelmed by infrastructural proliferation, it should be nice to hear that you can develop actual applications with just plain JavaScript and maybe a small Makefile.

bsimpson 11y ago
By "no observed downside", I meant once the toolchain is set up. Now, I get Hot Module Replacement and JS Harmony sugars for free, without having to worry about which browsers natively support which new features. Your point about perceived complexity/intimidation is a good one, but for me, removing cross browser inconsistencies simplifies development more than Webpack complicates it.
- nostrademons 11y ago
  There's always a cost to complexity, and it's usually in interop. What happens if you want to share a quick technology demo with a non-technical person over e-mail? What if you want your business cofounder to be able to tweak CSS by herself, and not have to learn what "setting up a toolchain" means? What if you're leading a team (or worse, a department or company) of people who aren't familiar with the latest in the JS world, need to do minor tweaks to the frontend, but can't justify learning a whole stack of technologies for something they spend 20% of their time in? All of these are real scenarios from my professional career. I like Babel too and the bulk of my new development is in ES6, but ubiquity is a really nice feature for development tools, probably the nicest of all.