3 ms·

> Complexity, sadly, is impossible to avoid. Complexity is impossible to avoid? Reading this just makes my heart sad. There is no reason you can't avoid comple

> Complexity, sadly, is impossible to avoid. Complexity is impossible to avoid? Reading this just makes my heart sad. There is no reason you can't avoid complexity here. Minifying and concatenating of assets is a very understood thing. It's really easy to do in fact. Whatever building solution you use (grunt, gulp, plain scripts), minifying and concatenating of resources should be a few lines of code if that. Transpiling I don't get. Yeah I'd love to use the new hotness of ECMAScript 6 but ECMAScript 5 has awesome support everywhere and isn't so significantly different to 6 that productivity is horrible; why can't we just use ECMAScript 5 until 6 is more readily available? But I digress because if you have to transpile that's still an easy build step. If you want to do it with every file change then that sucks, stop doing that. That's only useful in edge cases like debugging older browsers. For JSX just don't use it. HTML and JavaScript is kinda awkward to begin with; combining them together in some mixed format only to be separated seems like a way to just obfuscate the real way it works. I find it far, far better to understand how they work than trying to abstract them to some awkward degree that can't be used without transpiling. Maybe I'm an old timer not using the new hotness that is JSX, Webpack, etc but I just don't understand why anyone would bother bringing in that extra complexity when it's unnecessary even from a productivity standpoint. But I digress, maybe I'll just get downvoted here I just don't get it.

1stop 11y ago
Once you add a transpile step, your "transpile step" can give you a lot more confidence, with linting, and flow, and ecmascript 6. Minifying, concatenating, and compiling only used code paths/files and assets is only a few lines of code (with webpack). JSX to me is the more natural way to use React. I don't understand what the benefit of moving away from <html> is. It's more verbose, and harder to read if you construct your views in pure-js. (imo) To me, using webpack is avoiding complexity. It's a set and forget exercise, sure it's a bummer upfront. But once it's running, it's pretty smooth.
- BinaryIdiot 11y ago
  > Once you add a transpile step, your "transpile step" can give you a lot more confidence, with linting, and flow, and ecmascript 6. Linting is separate. Transpiling, for me, gives me less confidence because I write in one language, it has to run a transpiler to turn into another language giving me an extra point of failure (transpiler bugs suck; I ran into a few with CoffeeScript a few years back. Turned me off from ever using one again). Unless you have mappings debugging also has to be done in a separate language than what you write in which is really hard for me to get used to (I had to debug CoffeeScript back before it had chrome mappings). > Minifying, concatenating, and compiling only used code paths/files and assets is only a few lines of code (with webpack). Also only takes a few lines without webpack. For example my open source project, msngr.js, uses grunt and it's only a few lines of code specifying input and output. I also have a private project that does the step with a loop and a few additional lines of code (uses no grunt or gulp). > JSX to me is the more natural way to use React. I don't understand what the benefit of moving away from <html> is. It's more verbose, and harder to read if you construct your views in pure-js. (imo) JSX is probably a more natural way of working with React but it still abstracts away from the awkward JavaScript and HTML realities of the day. I've become jaded with frameworks that do that because I've run into far too many developers that don't understand how HTML and JavaScript really work and run into errors that are easily fixed if they understand how the underlying technology works. HTML's relationship with CSS and JavaScript is still kinda awkward so I understand why there are seemingly dozens of frameworks that abstract away from the whole thing. > To me, using webpack is avoiding complexity. It's a set and forget exercise, sure it's a bummer upfront. But once it's running, it's pretty smooth. I've used it and just didn't get the point of the thing. It helps that I avoid pretty much anything that gets transpiled (otherwise I could see it being more useful). If you don't do anything with transpiling I don't think it's very useful.
  - 1stop 11y ago
    I think I mostly agree with you. But with source mappings, trans-piling is pretty neat. With ECMAScript 6, Coffee, or Typescript. I remember the days of buggy Coffee and agree it was ridiculous when you hit a compile bug. But all the transpilers are much more mature now, and with source mappings you always know which line is wrong, and can even breakpoint and debug etc.

1stop 11y ago

Once you add a transpile step, your "transpile step" can give you a lot more confidence, with linting, and flow, and ecmascript 6. Minifying, concatenating, and compiling only used code paths/files and assets is only a few lines of code (with webpack). JSX to me is the more natural way to use React. I don't understand what the benefit of moving away from <html> is. It's more verbose, and harder to read if you construct your views in pure-js. (imo) To me, using webpack is avoiding complexity. It's a set and forget exercise, sure it's a bummer upfront. But once it's running, it's pretty smooth.

BinaryIdiot 11y ago
> Once you add a transpile step, your "transpile step" can give you a lot more confidence, with linting, and flow, and ecmascript 6. Linting is separate. Transpiling, for me, gives me less confidence because I write in one language, it has to run a transpiler to turn into another language giving me an extra point of failure (transpiler bugs suck; I ran into a few with CoffeeScript a few years back. Turned me off from ever using one again). Unless you have mappings debugging also has to be done in a separate language than what you write in which is really hard for me to get used to (I had to debug CoffeeScript back before it had chrome mappings). > Minifying, concatenating, and compiling only used code paths/files and assets is only a few lines of code (with webpack). Also only takes a few lines without webpack. For example my open source project, msngr.js, uses grunt and it's only a few lines of code specifying input and output. I also have a private project that does the step with a loop and a few additional lines of code (uses no grunt or gulp). > JSX to me is the more natural way to use React. I don't understand what the benefit of moving away from <html> is. It's more verbose, and harder to read if you construct your views in pure-js. (imo) JSX is probably a more natural way of working with React but it still abstracts away from the awkward JavaScript and HTML realities of the day. I've become jaded with frameworks that do that because I've run into far too many developers that don't understand how HTML and JavaScript really work and run into errors that are easily fixed if they understand how the underlying technology works. HTML's relationship with CSS and JavaScript is still kinda awkward so I understand why there are seemingly dozens of frameworks that abstract away from the whole thing. > To me, using webpack is avoiding complexity. It's a set and forget exercise, sure it's a bummer upfront. But once it's running, it's pretty smooth. I've used it and just didn't get the point of the thing. It helps that I avoid pretty much anything that gets transpiled (otherwise I could see it being more useful). If you don't do anything with transpiling I don't think it's very useful.
- 1stop 11y ago
  I think I mostly agree with you. But with source mappings, trans-piling is pretty neat. With ECMAScript 6, Coffee, or Typescript. I remember the days of buggy Coffee and agree it was ridiculous when you hit a compile bug. But all the transpilers are much more mature now, and with source mappings you always know which line is wrong, and can even breakpoint and debug etc.