23 ms·

The problem is, of course, that JSX, Flux, and Webpack came to be because of problems that people ran into when using just raw react. JSX solves the problem of

The problem is, of course, that JSX, Flux, and Webpack came to be because of problems that people ran into when using just raw react. JSX solves the problem of not being declarative enough and being too foreign to designers. Flux solves the problem of having to cascade data through dozens of children for mundane tasks. Then of course Webpack solves the problem of needing to transpile JSX and ES6 to plain JavaScript and minifying/uglifying/etc your assets. There is no such thing as "raw React" because building a web application is complicated no matter how you slice it. You either use a svelte library like React or Backbone and bolt on everything else you need yourself, or you just use a batteries-included framework like Ember, Angular, or Aurelia and let someone else provide a convention for you to follow. Complexity, sadly, is impossible to avoid.

BinaryIdiot 11y ago
> 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.
proc0 11y ago
Webpack is awesome, and sort of unrelated to React.js. It's a SPA bundler that works across server and client. It virtually works with anything, so I'm not sure why it's getting mentioned with React.js necessarily.
- rejschaap 11y ago
  React and Webpack are both awesome, they both work across server and client, they complement each other rather well. Obviously they are mentioned together a lot. You can use React without Webpack just fine, as the article shows you can use React without any bundler at all. But it is just so much better with Webpack. When you really start making components and put them in separate files, the raw approach in the article will not scale very well.
Retozi 11y ago
Not every application faces all the problems you mention: A lot of teams don't have the "designer" problem and are just fine without JSX. Passing data through dozens of children is not a problem in every application, a lot of simple CRUD stuff can do just fine without Flux. Even bundling is not necessary for progressively enhanced websites, and for most SPAs a really simple, naive strategy will do just fine. If the requirements of your project are ambitious, some complexity is not avoidable. But the problem today is that a lot of unneeded complexity is introduced into projects because people want to adhere to "best practice" and don't question what they need and what they don't need. In my opinion, it is a huge mistake to not actively resist complexity creeping into your project. You should only give in if it there is proof that it makes sense economically. This issue is another variant of "premature optimization is the root of all evil"
- michaelwww 11y ago
  Another quote I try to live by is from Brian Kernighan, who said "Controlling complexity is the essence of computer programming." It's common programmer humor that early in our career we fall in love with building beautiful and complex machines, but as we gain experience learn how to keep it simple, short and concise while accomplishing the same task.

BinaryIdiot 11y ago

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

proc0 11y ago

Webpack is awesome, and sort of unrelated to React.js. It's a SPA bundler that works across server and client. It virtually works with anything, so I'm not sure why it's getting mentioned with React.js necessarily.

rejschaap 11y ago
React and Webpack are both awesome, they both work across server and client, they complement each other rather well. Obviously they are mentioned together a lot. You can use React without Webpack just fine, as the article shows you can use React without any bundler at all. But it is just so much better with Webpack. When you really start making components and put them in separate files, the raw approach in the article will not scale very well.

Retozi 11y ago

Not every application faces all the problems you mention: A lot of teams don't have the "designer" problem and are just fine without JSX. Passing data through dozens of children is not a problem in every application, a lot of simple CRUD stuff can do just fine without Flux. Even bundling is not necessary for progressively enhanced websites, and for most SPAs a really simple, naive strategy will do just fine. If the requirements of your project are ambitious, some complexity is not avoidable. But the problem today is that a lot of unneeded complexity is introduced into projects because people want to adhere to "best practice" and don't question what they need and what they don't need. In my opinion, it is a huge mistake to not actively resist complexity creeping into your project. You should only give in if it there is proof that it makes sense economically. This issue is another variant of "premature optimization is the root of all evil"

michaelwww 11y ago
Another quote I try to live by is from Brian Kernighan, who said "Controlling complexity is the essence of computer programming." It's common programmer humor that early in our career we fall in love with building beautiful and complex machines, but as we gain experience learn how to keep it simple, short and concise while accomplishing the same task.