3 ms·

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, an

by 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.

by 1stop 11y ago

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.