7 ms·

Sorry, but even the “Getting Started” guide on React's website requires that you have a "CommonJS module system" installed which, if you don't, means you have t

Sorry, but even the “Getting Started” guide on React's website requires that you have a "CommonJS module system" installed which, if you don't, means you have to make an intelligent choice between Browserify and webpack, which means you have to do some minimal research into what those are (and probably research "babel-js", while you're at it), install one of them using npm, which may require that you install or upgrade node.js which, if you're on a Mac, may require that you install homebrew, which can sometimes open another, deeper can of worms... And that's just to get your tool chain in place. When you actually get into the tutorial, it starts with "Running a server". Running a server? I submit that writing even basic, toy applications in React requires a trip to dependency hell and back, unless you already use these tools on a regular basis and keep up with the ever-rapidly-changing debate around build scripts, dependency managers, language preprocessors, etcetera, etcetera.

foota 10y ago
Any language or environment has it's hoops that you have to jump through in order to use it, in some cases these happen to be installed for you so it's less noticeable.
deleted 10y ago
[deleted]
swanson 10y ago
I'm looking here: https://facebook.github.io/react/docs/getting-started.html https://facebook.github.io/react/docs/getting-started.html And seeing a JSFiddle link that is fully configured to work and zip file that includes all necessary files. What am I missing?
- joesb 10y ago
  the first line of HTML code in that Fiddle link is: https://facebook.github.io/react/js/jsfiddle-integration-babel.js https://facebook.github.io/react/js/jsfiddle-integration-bab... What you are missing is that you probably don't want to develop by putting your code in JSFiddle.
- EdwardDiego 10y ago
  A generalised hatred for the JS ecosystem, I believe.
wmil 10y ago
Yeoman.io is supposed to solve the 'getting started' problem. But the quality of generators varies wildly, so it's hard to recommend. You could probably build a tutorial around generator-react-webpack-redux.
- leoalves 10y ago
  react-cli is pretty good
- stylesuxx 10y ago
  I would very much appreciate this. Pull requests are welcome. I have been working on some examples, but did not have the time to refine them yet. Started to implement the Todo App in this branch => https://github.com/stylesuxx/generator-react-webpack-redux/tree/feature/examples https://github.com/stylesuxx/generator-react-webpack-redux/t...
eagsalazar2 10y ago
Submission largely accepted but you aren't making a real point with what you've submitted. I say "largely" because I agree with gp that 2 hours is hardly hell for a larger project but agreed that is pointless for basic/toy applications. This isn't really a solid indictment against React and webpack however. If you are really making a tiny/toy app, and not doing so for educational reasons, then yeah probably you should just use jquery and edit js/html/css (vs ES6/JSX or Jade/SASS + redux, testing, etc, etc which is not trivial).
spicyj 10y ago
I'm having trouble understanding your comment. Neither the homepage, Getting Started, the tutorial, nor the downloads page mentions CommonJS. If you do choose to use browserify or webpack, you'll want Node and npm, but Node's homepage doesn't suggest using Homebrew so I'm not sure why that would be necessary. (Besides, in my experience, most programmers using a Mac have Homebrew already.) > When you actually get into the tutorial, it starts with "Running a server". Running a server? We included this as a sample because most people write clients against an app server so we thought it instructive to show how to fetch and post data via AJAX. Nothing about it is inherent to React and people make React apps without any server component all the time. It sounds like this was misleading to you, which is good feedback for us. I was thinking about revamping the tutorial soon anyway and my new example wasn't going to have any server component.
- jimmytucson 10y ago
  My comment was based on notes I took from a little over a month ago, when the Getting Started guide said "We recommend using React with a CommonJS module system like browserify or webpack." https://web.archive.org/web/20160411175140/https://facebook.github.io/react/docs/getting-started.html https://web.archive.org/web/20160411175140/https://facebook....
  - spicyj 10y ago
    Ah, indeed. Looks like we tried to simplify it recently: https://github.com/facebook/react/pull/6148 https://github.com/facebook/react/pull/6148
tracker1 10y ago
By the same note, you likely won't be writing a complex desktop application without some tooling installed, with similar pre-requisites. I don't know why people get so irritated at "JS tooling is hard". Try writing an (INSERT FRAMEWORK HERE) app outside the browser. People assume that writing an APPLICATION for a browser is easy, which is why people get stuck maintaining monstrosities that are disorganized, not composed and tens of thousands of lines of spaghetti. Writing an application in the browser deserves just as much respect as one would give towards setting up the database & schema or creating a service layer. That lack of respect for front end code is a big reason as to why front end projects have crappy code. React is a real break from this on so many levels... Yes, you'll need (webpack|jspm|browserify) with (babel|typescript), and likely (postcss|less|scss) in place closer to the start than the end. Much like if you're writing code for a desktop application you'll likely need at least an IDE installed, and potentially several libraries close to the start. My current tooling of choice is webpack + babel, depending on the project I may bring in scss or less, and react tooling as needed. Using CSJ or ES6 style module syntax means cleaner code that's easier to restructure. Using webpack means being able to bundle resources in a logical flow. Working on a project without webpack + babel is just painful by comparison... I'm working on an ng1 app at work that's less than 6 months old, and feels like it was written in 2011... having to add .js files to some common point, and not being able to easily refactor services/controllers/directives/components into discrete modules is pretty painful in general. What does it take to get a Java application going? Maven, some build system, some other tooling, and understanding the component/class hierarchies? It's not any easier than working with any new tooling. Is there some churn, yes... is it that bad, not really... going to browserify mainly means that you can have references from a starting point into your application's code... each piece requires in its' dependencies. From there going to webpack adds in other dependencies and custom loaders. Babel is a translation layer... these tools generally build on or are supersets of the tools that came before.
- intrasight 10y ago
  There is much less tooling and much less churn even for a very complex Java application
  - 10y ago
bigpeopleareold 10y ago
A decent toolchain of various libraries and build tools is an opportunity to avoid bigger problems and nasty, subtle bugs when you are working on large codebases. I continue to have my share of them, which tend to be in areas of the codebases I worked on that is principally jquery spaghetti or undisciplined Backbone code. I'd rather deal with the dependency hell; that's an opportunity cost. I'd rather deal with my current toolchain than having to tell stakeholders that a particular aspect of bad code is beyond repair and needs to be replaced badly, at the cost of a large time sink.

foota 10y ago

Any language or environment has it's hoops that you have to jump through in order to use it, in some cases these happen to be installed for you so it's less noticeable.

deleted 10y ago

[deleted]

swanson 10y ago

I'm looking here: https://facebook.github.io/react/docs/getting-started.html https://facebook.github.io/react/docs/getting-started.html And seeing a JSFiddle link that is fully configured to work and zip file that includes all necessary files. What am I missing?

joesb 10y ago
the first line of HTML code in that Fiddle link is: https://facebook.github.io/react/js/jsfiddle-integration-babel.js https://facebook.github.io/react/js/jsfiddle-integration-bab... What you are missing is that you probably don't want to develop by putting your code in JSFiddle.
EdwardDiego 10y ago
A generalised hatred for the JS ecosystem, I believe.

wmil 10y ago

Yeoman.io is supposed to solve the 'getting started' problem. But the quality of generators varies wildly, so it's hard to recommend. You could probably build a tutorial around generator-react-webpack-redux.

leoalves 10y ago
react-cli is pretty good
stylesuxx 10y ago
I would very much appreciate this. Pull requests are welcome. I have been working on some examples, but did not have the time to refine them yet. Started to implement the Todo App in this branch => https://github.com/stylesuxx/generator-react-webpack-redux/tree/feature/examples https://github.com/stylesuxx/generator-react-webpack-redux/t...

eagsalazar2 10y ago

Submission largely accepted but you aren't making a real point with what you've submitted. I say "largely" because I agree with gp that 2 hours is hardly hell for a larger project but agreed that is pointless for basic/toy applications. This isn't really a solid indictment against React and webpack however. If you are really making a tiny/toy app, and not doing so for educational reasons, then yeah probably you should just use jquery and edit js/html/css (vs ES6/JSX or Jade/SASS + redux, testing, etc, etc which is not trivial).

spicyj 10y ago

I'm having trouble understanding your comment. Neither the homepage, Getting Started, the tutorial, nor the downloads page mentions CommonJS. If you do choose to use browserify or webpack, you'll want Node and npm, but Node's homepage doesn't suggest using Homebrew so I'm not sure why that would be necessary. (Besides, in my experience, most programmers using a Mac have Homebrew already.) > When you actually get into the tutorial, it starts with "Running a server". Running a server? We included this as a sample because most people write clients against an app server so we thought it instructive to show how to fetch and post data via AJAX. Nothing about it is inherent to React and people make React apps without any server component all the time. It sounds like this was misleading to you, which is good feedback for us. I was thinking about revamping the tutorial soon anyway and my new example wasn't going to have any server component.

jimmytucson 10y ago
My comment was based on notes I took from a little over a month ago, when the Getting Started guide said "We recommend using React with a CommonJS module system like browserify or webpack." https://web.archive.org/web/20160411175140/https://facebook.github.io/react/docs/getting-started.html https://web.archive.org/web/20160411175140/https://facebook....
- spicyj 10y ago
  Ah, indeed. Looks like we tried to simplify it recently: https://github.com/facebook/react/pull/6148 https://github.com/facebook/react/pull/6148

tracker1 10y ago

By the same note, you likely won't be writing a complex desktop application without some tooling installed, with similar pre-requisites. I don't know why people get so irritated at "JS tooling is hard". Try writing an (INSERT FRAMEWORK HERE) app outside the browser. People assume that writing an APPLICATION for a browser is easy, which is why people get stuck maintaining monstrosities that are disorganized, not composed and tens of thousands of lines of spaghetti. Writing an application in the browser deserves just as much respect as one would give towards setting up the database & schema or creating a service layer. That lack of respect for front end code is a big reason as to why front end projects have crappy code. React is a real break from this on so many levels... Yes, you'll need (webpack|jspm|browserify) with (babel|typescript), and likely (postcss|less|scss) in place closer to the start than the end. Much like if you're writing code for a desktop application you'll likely need at least an IDE installed, and potentially several libraries close to the start. My current tooling of choice is webpack + babel, depending on the project I may bring in scss or less, and react tooling as needed. Using CSJ or ES6 style module syntax means cleaner code that's easier to restructure. Using webpack means being able to bundle resources in a logical flow. Working on a project without webpack + babel is just painful by comparison... I'm working on an ng1 app at work that's less than 6 months old, and feels like it was written in 2011... having to add .js files to some common point, and not being able to easily refactor services/controllers/directives/components into discrete modules is pretty painful in general. What does it take to get a Java application going? Maven, some build system, some other tooling, and understanding the component/class hierarchies? It's not any easier than working with any new tooling. Is there some churn, yes... is it that bad, not really... going to browserify mainly means that you can have references from a starting point into your application's code... each piece requires in its' dependencies. From there going to webpack adds in other dependencies and custom loaders. Babel is a translation layer... these tools generally build on or are supersets of the tools that came before.

intrasight 10y ago
There is much less tooling and much less churn even for a very complex Java application
- 10y ago

bigpeopleareold 10y ago

A decent toolchain of various libraries and build tools is an opportunity to avoid bigger problems and nasty, subtle bugs when you are working on large codebases. I continue to have my share of them, which tend to be in areas of the codebases I worked on that is principally jquery spaghetti or undisciplined Backbone code. I'd rather deal with the dependency hell; that's an opportunity cost. I'd rather deal with my current toolchain than having to tell stakeholders that a particular aspect of bad code is beyond repair and needs to be replaced badly, at the cost of a large time sink.