17 ms·

Create React Apps with No Configuration

777 points by vjeux 10y ago

jfdk 10y ago
This is actually pretty huge. #1 complaint/barrier/hate with getting started with React is all the tooling to do it "the right way" Kudos to React team for bringing a superior pattern and making it actually practical to use.
- terda12 10y ago
  I'm really hoping to see the React team make React more user friendly. Maybe an all in one React framework much like Meteor, where you can just do `react createapp myapp` or something and start coding right away.
  - tlrobinson 10y ago
    React is so versatile (raw React, React + Redux, React + Relay, to name a few) I don't think they should tie it too closely to one framework. I would love to see a more official/opinionated framework that uses React, but call it something besides "React". Ditto for Redux. They're both low-level building blocks that could benefit from some official "opinions".
msoad 10y ago
This is lacking tons of features that other boilerplates already have but I think this was a great move because we needed a source of truth for doing app structure in React. In a different note, I think if you write it yourself from scratch you'll have more control and knowledge down the road when it comes to nasty bugs but I won't blame you for choosing this over spending weeks setting up a React app.
- donjh 10y ago
  I think it's the right move for people new to React. A lot of those features in other boilerplates aren't really necessary for building out a simple app. Furthermore, the Eject feature (https://github.com/facebookincubator/create-react-app#converting-to-a-custom-setup https://github.com/facebookincubator/create-react-app#conver...) allows someone to move from the default configuration to their own when they feel comfortable.
- city41 10y ago
  If you work with React a lot, you can setup a React project to your taste in about 30 minutes. But the catch being if you leave React for a while then come back, all bets are off. I think most boilerplates add way too much and are overly opinionated. I like that this is simple, and "eject" gives power users an even better starting point.
  - happyslobro 10y ago
    Totally. My first React setup took me two days to get right. Now, starting a new project is a 5 minute exercise in CLI autocomplete that has me wishing npmjs downloads were faster. It's surreal to think that for any popular technology, there will always be newcomers, no matter how long that technology has been around. I would write up my process in a blog post, but I'm sure that that has already been written several times.
    - happyslobro 10y ago
      Going back over my old projects and finding four different flux implementations, that is a new and interesting kind of suffering. The crazy thing is, I never even liked flux in any of its forms. What I really want, is pouchdb / couchdb, but even that is not perfect, and my team has no problem poking holes in weird ideas. Right now, I'm going through the Om.next tut series, and it is pretty awesome so far. I think I'm going to pass on datascript, though. This is total skunkworks though, if people at work found out that was using clojurescript on the front end, they would be very concerned about me. The killer feature for Om.next, imo, is using a reader function to define the relationship between a component and the one application state atom. Combine that with an identifying function that associates a component with a field in the application state, and you enable the framework to make very precise component updates.
  - underwater 10y ago
    The problem is not really being overly opinionated. It's being unnecessarily opinionated. React Starter Kit comes with GraphQL as its API layer. I love GraphQL, and have written tons of it when writing Relay code, but I wouldn't ever expect someone getting up to speed on React to use it. You have to limit the number of things you throw at newcomers.
- mambodog 10y ago
  Most features in boilerplates are completely unnecessary for most beginner users of React. Off the top of my mind: - Server or Universal rendering - Hot Module Reloading (refreshing is fine!) - (early stage) proposed JS syntax The main thing that is missing from this package is testing, but that's a very opinionated kettle of fish.
  - danabramov 10y ago
    We’ll add testing, just need to make some decisions: https://github.com/facebookincubator/create-react-app/issues/80 https://github.com/facebookincubator/create-react-app/issues...
firasd 10y ago
This is great. React has this weird dual nature in that on one hand, you can drop it in as a <script> tag and it 'just works'. On the other hand, if you want to build using it, you're going to end up needing things like webpack, babel, etc, not to mention other common libraries, to the extent that it takes over your front-end stack (also because it takes over any rendered document nodes, and if you want to build a SPA you eventually use it to render everything inside <body> if not the whole document). So it's good to resolve this conflict by providing quicker ways to get started with common tools.
amavisca 10y ago
Under the hood this is Webpack + Babel + ESLint with sane initial configuration. Love it.
- griffinmichl 10y ago
  This is all I ever want in a React boilerplate, but everyone feels the need to throw a bunch of random shit into them that others probably do not even want. Glad they kept it sane and simple.
  - seangrogg 10y ago
    In all fairness, I think that flags that provide some basic bootstrapping for Redux and/or React-Router would be very spiffy - those tools are useful for many React applications.
    - amavisca 10y ago
      I think Redux and React-Router are very opinionated and distract people new to React from React itself. My workflow for ramping someone up on React and eventually Redux looked like: - A single React component with React.createClass - ES6 class React components - Add a component hierarchy and treat the top level component's state as the entire app state - pass down callbacks to update state. Look how this becomes harder to scale as we get more depth in our component hierarchy! - Redux without the redux-react bindings. Also stateless function components.
      - seangrogg 10y ago
        I agree. That's why I would put them behind flags. Even though most of my own projects wind up using them, I tend to start from a clean slate and apply things only as they become relevant.
  - amavisca 10y ago
    As someone not new to React, I'm seeing this tool as a solid replacement to the old JSX Transformer script they used to provide. Let me get up and running just a bit more quickly.
vicapow 10y ago
I'm sucker for self descriptive "boring" names like "create-react-app" Also, sweet project!!
arianvanp 10y ago
This is really neat. especially the fact that I can 'eject' at any time when I need more power. Love it!
vlunkr 10y ago
My team has wasted so much time configuring webpack. This is a big win for React IMO.
- abritinthebay 10y ago
  This right here is why I actively suggest not using webpack. It's Grunt 2.0 all over again and not worth the mess. IMO it's the worst choice Facebook could have made for this toolkit, as it breeds some awful habits.
  - amavisca 10y ago
    Can you add some clarity to your complaints about WebPack? What are the similarities with Grunt that aren't worth the mess and what are some of the awful habits that WebPack breeds? What are your preferred ways to handle modules and build steps in general?
  - danabramov 10y ago
    What’s wrong with using webpack under the hood? The problem is webpack being a lower level tool. This is why we abstract it away from you (and we can swap it for something better if it comes along, but actually webpack is pretty powerful).
    - abritinthebay 10y ago
      We discussed this on Twitter Dan, fyi, no need to rehash here. But they very fact you had to spend time abstracting away WebPack speaks volumes IMO...
      - danabramov 10y ago
        Sorry, didn’t realize it was you :-) >But they very fact you had to spend time abstracting away WebPack speaks volumes IMO... Speaks volumes about its poor public API. I don’t understand how this this affects create-react-app, really. But if you can suggest something better that solves the same problems, please do.
ola 10y ago
I created something similar a month ago https://github.com/olahol/reactpack https://github.com/olahol/reactpack Doesn't seem like this project differs that much, although this looks to have the backing of core React developers.
- pbreit 10y ago
  I don't get why they would need to lock down the configuration and then have to offer the eject thingy. Couldn't they just offer a "facebook-certified" starter pack/bootstrap? I guess you could just do an immediate eject? Edit: looks like they contemplated that in the survey: "Yes, and I will run `eject` straight away"
  - danabramov 10y ago
    Many people (especially beginners) appreciate automatic updates of their dependencies. If you eject straight away you’ll have to manage them yourself, which is a big turnoff to many.
    - pbreit 10y ago
      Could there be some sort of npm feature that incorporates a remote list of dependencies & versions?
      - danabramov 10y ago
        Yep, it’s called a “package”. ;-)
        pbreit 10y ago
        So could whatever create-react-app is delivering be substantially approximated with an npm-based solution?
        danabramov 10y ago
platonichvn 10y ago
Definitely a great way to lower the barrier to entry. The eject feature is sweet since it removes the risk of lock in. Looking forward to integrated unit testing libraries in a future release. While you're at it let's add redux. :)
- danabramov 10y ago
  We won’t add runtime dependencies besides React for now. We are focused on solving build tooling first.
dack 10y ago
This is really great! However, I think this speaks to the need for a better API in general for this sort of stuff. At the moment it's "all or nothing" in that you can decide to let everything be configured, or nothing be configured ("ejecting"). This makes perfect sense, but I think a more ideal solution would be having layers of configurability that let you more gracefully set your preferences without completely abandoning this tool's utility. I'm not saying that's easy, but it's a direction I'd be excited to see.
- danabramov 10y ago
  I’d love that to be possible but “all or nothing” is useful as a forcing function for us to choose great defaults. We might want to relax it a little someday, but doing it too early will harm the project.
wrong_variable 10y ago
Just wanted to know, am I the only person who is unhappy with react ?
- mrspeaker 10y ago
  There are 7.4 billion people in the world. It's safe to assume you hold no unique opinions.
- spicyj 10y ago
  What's got you down and what could we make better?
marknadal 10y ago
The day we now see "compiled successfully" in the Command Line as the necessary "easy" starting point for frontend web devs.
rhinoceraptor 10y ago
What the heck is that terminal font?
- jaytaylor 10y ago
  Other than a nasty eyesore? Good question.. http://i.imgur.com/2suYgKq.png http://i.imgur.com/2suYgKq.png http://i.imgur.com/FnLVfw6.png http://i.imgur.com/FnLVfw6.png
- deleted 10y ago
  [deleted]
- madjam002 10y ago
  Operator Mono
- i336_ 10y ago
  Thanks so much for asking, I was wondering the same thing.
deleted 10y ago
[deleted]
kcorbitt 10y ago
Sane defaults and pieces made to go together are critical to lowering the adoption barrier and building a community, so huge props for that. But no ability to configure anything at all? I think that for most people, at some point there will be some small change to the default configuration their environment will require[1], and that means they'll need to jettison the entire project. It's nice that this is easy to do, but it would be better if it weren't necessary. [1]: For example, I run my app from within a Vagrant Virtualbox machine that doesn't forward filesystem notifications correctly, so I have to configure Webpack's hot reloader to poll for changes instead of listening for fs events.
- sotojuan 10y ago
  https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html#no-lock-in https://facebook.github.io/react/blog/2016/07/22/create-apps... > “Ejecting” lets you leave the comfort of Create React App setup at any time. You run a single command, and all the build dependencies, configs, and scripts are moved right into your project. At this point you can customize everything you want, but effectively you are forking our configuration and going your own way. If you’re experienced with build tooling and prefer to fine-tune everything to your taste, this lets you use Create React App as a boilerplate generator.
  - danabramov 10y ago
    We’ll start with extremes (no config vs all config is yours) and see how people use it. Perhaps we’ll add some configuration later but if we do it too early, we might as well become another webpack. Configuration makes it very hard to move forward or swap underlying tools. So we’ll stick with no configuration for as long as we can, and try to figure out a way to solve common problems by other means (e.g. smarter detection, platform-specific code, etc).
    - andrewstuart 10y ago
      Please Dan keep it zero configuration. If a person knows enough to want to configure, then they have learned enough to venture out on their own via eject. The difference in cognitive load between "zero config" and "some config" is enormous. "zero configuration" === minimal mental model, no scope for misunderstandings, misconfigurations, minimal documentation, almost no scope for user errors and also minimal learning time "some configuration" - even one single switch/option === learning the mental model, understanding, version problems with the old way of configuring, documentation of configuration, potential for errors, old & out of date blog posts on the Internt telling how to do it the old way, beginner pain You will come under constant pressure from people who want to add "just this one teensy option" and will criticize the project for not having it. Resist the criticism - beginners need zero config. The root of all evil in JavaScript development and build systems is configuration.
matthoiland 10y ago
> Some features, such as testing, are currently missing. This is an intentional limitation, and we recognize it might not work for everybody. With Ember CLI you get a great testing setup with Qunit. While I prefer Mocha over Qunit, I'm at least glad that testing is a first class citizen in the CLI.
- iamstef 10y ago
  and its easily swappable: https://github.com/switchfly/ember-cli-mocha https://github.com/switchfly/ember-cli-mocha (and fully integrates with the existing test harness, regardless of the test framework you choose.)
orf 10y ago
> Having just attended EmberCamp a week ago, I was excited about Ember CLI. Ember users have a great “getting started” experience thanks to a curated set of tools united under a single command-line interface. This is one of the best things about Ember. `ember new`, `ember serve`, ember generate component my-component`, `ember build`, `ember deploy`, `ember install`. It's opinionated but it lets you get productive right off the bat. I tried React but after a couple of days I just couldn't get it working, waaay to many options. So I switched to Ember and haven't looked back.
- sotojuan 10y ago
  Don't forget: https://www.ember-fastboot.com/ https://www.ember-fastboot.com/ Also two commands to get server rendering working.
  - matthoiland 10y ago
    Also don't forget: https://github.com/felixrieseberg/ember-electron https://github.com/felixrieseberg/ember-electron One command to wrap your Ember app in Electron.
  - orf 10y ago
    I personally use Django as a backend for my Ember stuff, which means I miss out on the whole fastboot experience. It does look really nice though.
    - ebryn 10y ago
      Django / other backends aren't mutually exclusive with Fastboot. You can use them together.
- ctvo 10y ago
  Kind of interesting to think about the two projects and how they diverge based on the core developers. Ember is made by folks who work on / for small and medium companies[1]. They don't have the build infrastructure Facebook does and are able to create an anointed solution in Ember-CLI because they'll use it daily. React is stuck in a place where the environment it's developed in is unique from what any other user will see. It's difficult to solve a problem when you're not in the space. EDIT: This leads to things beyond CLIs too. React is still billed as just a view library instead of a solution for building an entire app. There's no official path from view layer -> complete app (no guidance for data flow, how to communicate with the server, server side rendering, routing on the client). I think the React team needs to take a little more responsibility for the eco-system it created. You can't call it just a view library when most use cases use it to develop entire applications. You have to provide more guidance, you can't fallback to Facebook not using it that way as the default response. In my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users trying to fill in the blanks left by the React team and producing one solution after another (and quickly abandoning ship as something iteratively better was released). 1 - Tom, Yehuda at tilde.io
thereact 10y ago
This is great since it provides an OFFICIAL opinionated set of tools for building React apps which is typically the largest barrier of entry for new developers looking to experiment with this technology. However, it is missing a lot of core features that typically come standard with Webpack/React boilerplates. Directly from their Github: Some features are currently not supported: Server rendering. Testing. Some experimental syntax extensions (e.g. decorators). CSS Modules. LESS or Sass. Hot reloading of components. So a great first set of features for a simple React starter project, but for those of you looking to expand the development toolkit from this currently limited configuration, check out the following link to search React boiler projects on github based on a number of criteria like the ability to search by features included such as CSS Modules, Hot Module Replacement, etc. http://andrewhfarmer.com/starter-project/ http://andrewhfarmer.com/starter-project/ For those looking to learn more about the ecosystem, the following resource lists might be useful. More React resources: https://github.com/enaqx/awesome-react https://github.com/enaqx/awesome-react React/Redux resource links: https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links
- afarrell 10y ago
  Lack of testing is a pretty big oversight given how helpful testing is for someone getting started. Hopefully it is easy to just add mocha on top of this with out any mucking around?
  - danabramov 10y ago
    It shouldn’t be too hard. This is not an oversight, we literally developed this project in a single week. We plan to add testing, just need to decide on the runner and good defaults: https://github.com/facebookincubator/create-react-app/issues/80 https://github.com/facebookincubator/create-react-app/issues....
    - afarrell 10y ago
      blushes oversight was a bad choice of a word. I'm excited to see this and excited to see testing tools a part of it.
smcgraw 10y ago
Amazing.
hex13 10y ago
it seems like a solution to the Vjeux's challenge: http://blog.vjeux.com/2015/javascript/challenge-best-javascript-setup-for-quick-prototyping.html http://blog.vjeux.com/2015/javascript/challenge-best-javascr... (If we don't count sharable requirement).
- vjeux 10y ago
  Integration with now.sh ( https://zeit.co/now/ https://zeit.co/now/ ) and uploading to gh-pages is something that was cut for the release but we are thinking about doing :)
  - deleted 10y ago
    [deleted]
venuzr 10y ago
As someone new to React, I wonder a) How is this different from getting a custom starter kit/generator from Yeoman. Searching in yeoman, I see several for "React" with the top one having over 9.5k stars http://yeoman.io/generators/ http://yeoman.io/generators/ b) Is Facebook planning to maintain and keep this generator current? Why don't they just contribute/recommend an existing generator
- danabramov 10y ago
  This is not a generator. It is a dependency, which means that we can (and intend to!) update the underlying tools without any work on your part. Additionally, unlike a generator, it doesn’t expose you to any configs so you can focus on your code. However you can “eject” if you really want to.
JoeCortopassi 10y ago
This is great for someone who wants to get started to learn React, but is missing a ton that is needed for a real world production app. * No isomorphic rendering * No hot module replacement * No generators * No dockerization * No Sass support * No test environment setup * No code splitting It would be cool to have a production ready tool from Facebook, but I'll stick with gluestick for now https://github.com/TrueCar/gluestick/blob/develop/README.md#why-your-project-or-boilerplate-isnt-enough https://github.com/TrueCar/gluestick/blob/develop/README.md#...
- mumphster 10y ago
  None of that is needed for a real world production frontend app, with the exception of maybe tests.
  - JoeCortopassi 10y ago
    Granted, some things like hot module replacement and generators are not necessary, most of the others are (isomorphic rendering, code splitting, sass, dockerization). I'm not saying you need those things for your personal react app going into production, but when dealing with bigger teams for a critical app they really become important tools
    - seangrogg 10y ago
      In all fairness, most "critical apps" won't be using a standardized boilerplate anyways. It makes little sense to optimize for the least-likely consumer.
    - hex13 10y ago
      1. Sass is not as needed as it used to be (native CSS variables, PostCSS, CSS Modules, Radium, inline styles etc.). But of course many users prefer Sass. But Sass in its CSS syntax (SCSS) is (if I'm correct) just super set of CSS. You can always start project using vanilla CSS and when project will grow, you can add Sass. There are two approaches to develop new projects: big design up front and YAGNI principle (you ain't gonna need it). I prefer YAGNI and I'm glad that Facebook generator is so minimal. But I don't know what they are planning to do with this project. I think this project would be a lot worse if they forced to use Sass(or Radium or any opinionated CSS solution). 2. code splitting? If I understand correctly it's Webpack feature needed mainly for production, not development. So why to add this on the very beginning of your project?
griffinmichl 10y ago
After spending hours yesterday teaching a colleague about webpack, babel, configuration, etc, this is exactly what the React community needs. Finally some fucking sanity in the ecosystem.
mcs_ 10y ago
Thanks !!!
stoikerty 10y ago
I'm fairly close to finishing the conversion of my `dev-toolkit` into an npm-module. It is almost no-config, has scss, server-side-rendering, hot-reload and more. I'm a one man band but will get there. It's all on https://github.com/stoikerty/universal-dev-toolkit https://github.com/stoikerty/universal-dev-toolkit The npm-version sits in a feature branch, just look for the corresponding PR if you're keen.
- stoikerty 10y ago
  I have a release ready. Just pinned it at 5.0.3 It is similar to `create-react-app` but also has CSS-Modules (with SCSS) and a few other features like Browsersync and root-relative imports. Hope anyone reading this finds it useful :) https://github.com/stoikerty/dev-toolkit https://github.com/stoikerty/dev-toolkit
kjhughes 10y ago
Does this help with React Native too?
- vjeux 10y ago
  React Native already has `react-native init <project-name>` command that works in a similar fashion.
lucaspottersky 10y ago
Expectation: - "Hey, look, this can SOLVE ALL THE PROBLEMS" Reality: - "Hey, look, this actually BRINGS IN A WHOLE LOT OF OTHER PROBLEMS too!" :sad:
- Splendor 10y ago
  Would you mind explaining which new problems this creates?
  - abritinthebay 10y ago
    WebPack for one. Using webpack brings in way more problems than it solves.
    - danabramov 10y ago
      Sure, if you use it directly. The biggest complaint about webpack is it’s hard to configure. We configure it for you. You don’t need to think about it. What other problems does webpack bring in your opinion? File an issue and let us know: https://github.com/facebookincubator/create-react-app/issues/ https://github.com/facebookincubator/create-react-app/issues...
    - Splendor 10y ago
      Again you've suggested the introduction of problems without mentioning a single one. I'm not saying you're wrong (because I don't know what you're saying yet), but I don't think you're adding much to the discussion here.
- danabramov 10y ago
  We’d love to hear about the problems. https://github.com/facebookincubator/create-react-app/issues/ https://github.com/facebookincubator/create-react-app/issues...
seangrogg 10y ago
I think one of the best things I've done to date is actually distance myself from the React community. While I love some of the tooling that has come out of it (Redux, React-Router) I think the community (as an amorphous entity) over-emphasizes the need/desire for transpiling, linting, testing, etc. Since then, I've "reverted" to building things in ES5, working in multiple files without bundling, etc. and I have to say the enjoyment I get out of using React has cranked up considerably. I am happy to see they are converging on some standards - that will definitely make building new apps much easier from a common starting point. I just hope they can walk the fine line between "opinionated" and "bloated".
- sotojuan 10y ago
  I was just talking about this with coworkers... I love React but the community (aside from the actual creators and leaders like Dan) is too much for me and seem to love bloat and unnecessary features. The cynical side of me thinks a lot just do it for GitHub stars and blog views, but maybe not. Of course, we just spent two days trying to decipher a React/Redux project whose lead dev decided to use every "latest" feature even though it's a good ol' CRUD app.
  - danabramov 10y ago
    We think ES6 is not the problem here. It’s just a language, and arguably a better one than ES5. The problem is the low level tooling around it. This is what we’re trying to fix with this project. Hopefully you’ll give it a go, and maybe it will give you just as much enjoyment as using <script> tags. If not, please let us know how we can improve. It’s not linting/transpilation/bundling that’s bad, it’s that it’s hard to do them without shooting yourself in the foot.
    - sotojuan 10y ago
      I definitely use ES6 for sure, though nothing too crazy (no decorators, bind :: thingy, etc). Do you remember how you were telling people on Twitter that they don't need every single crazy feature and every single thing in the Redux store (or even Redux at all) to do React? The kind of people I am complaining about are the ones that say the opposite.
Exuma 10y ago
Looks cool
deepsun 10y ago
Is there something like this for React Native? I'm interested in recommended directory structure.
- ed 10y ago
  This is kind of built in to React Native already, but they use their own packager (ReactPackager) instead of webpack. Would be neat for ReactJS and React Native tools to converge at some point!
tlrobinson 10y ago
I think the best part of this is the "eject" feature. It's great to be able to spin something up quickly but migrate to a custom solution if you outgrow it. However, it would be nice to be able to tweak some of the configurations (Babel, ESLint, Webpack) without completely "ejecting".
- danabramov 10y ago
  If we let you tweak them, any minor update on our part would be a breaking change. We wouldn’t be able to introduce new features or update the underlying tools without a lot of risk. This is why we don’t let you change the configs. If you have a specific pain point, please file an issue. I think we can make defaults better. It takes more work but is more rewarding in the end because it benefits everyone.
  - cheapsteak 10y ago
    This is super useful for helping beginners overcome initial barriers and quickly become productive, but do you see this as something that most will eventually grow out of?
    - danabramov 10y ago
      When you grow out of it, you run "eject" and customize everything you want. We think in the beginning many will "eject" but we will gradually make the defaults better to cover more and more use cases.
      - tlrobinson 10y ago
        That makes sense, but I think there will always be people who want to tweak ESLint rules or enable new Babel features, but would still like to take advantage of improvements to this project. Perhaps exposing a subset of those tools' configuration options would be sufficient. Alternatively, you could imagine a pretty simple system that allows you to pull newer versions of the "ejected" code and handle merge conflicts using your version control software. I'd also suggest reducing the amount of non-configuration code that's generated by "eject". I think basically everything in "scripts" could be put into a package ("openChrome.applescript" seems like it should be a feature of opn anyway). That would also reduce the number of devDependencies that need to be added to your project's package.json (rimraf, chalk, opn, etc)
mohsinr 10y ago
Loving it! I always wanted to get started with ReactJs but looks like time has come! I tried the module and I am loving the "Welcome to React" page on my localhost! Thank you!!! PS. Already in /src/App.js , and wow live reloading without gulp or browersync , it is so simple to get started! Thank you!
- robertfw 10y ago
  I thought the live reloading was just for CSS?
  - danabramov 10y ago
    Yep. For components we refresh the page now. (Automatically still.)
joemaller1 10y ago
This is great and I will be moving my React projects in this direction. At very least this project represents a de-facto standard and guidance about how to work with React. However I do wish the React team would pick between ES6 classes and `React.createClass`. I think I remember the main React tutorial was rewritten in ES6 at one point, but then switched back. I've read arguments both ways, but I suspect they ES6 is still too much of a barrier to entry. People who aren't up to speed with ES6 will still be shaving a lot of yaks before actually jumping into React.
- lacker 10y ago
  If you're using create-react-app then you're encouraged to use ES6 classes - that's how the default App.js is set up.
  - danabramov 10y ago
    >However I do wish the React team would pick between ES6 classes and `React.createClass` We’re going with ES6 classes. Expect createClass() to go into another package some time this year. (Obviously we’ll provide an automated “codemod” utility to convert your existing code.)
    - anthonybullard 10y ago
      Please say it isn't so! Class is terrible syntactic sugar to please old Java programmers. I'd be really interested in why this decision would be made. Im just getting going in React and am looking to make a move away from Angular, because Angular 2 is so hyper focused on classes and decorators. I like React because it's closer on the purity scale to something like Cycle.js. But nevermind me, React is a great tool, and this is a very nice and needed project!
      - acemarke 10y ago
        React's lifecycle methods and other similar features require some kind of "object instance" to exist. Since React was created prior to ES6, the React team created their own "inheritance"-ish approach, which is something that every JS library out there was doing as well. One of the main arguments for classes being included in the ES6 standard is that it's a common approach that libraries can converge on and use together, rather than every library inventing their own version of inheritance. Since ES6+ is now the actual Javascript language standard, it makes sense for React to move away from their homegrown class definition approach, and build on top of the approach that is now standardized in the language. The React community has already eagerly adopted ES6, and while React.createClass() isn't going to be deleted any time soon, it's time to start encouraging people to move away from using it. Either way, though, React's API _does_ depend on having something "class"-like available.
mfrye0 10y ago
This is awesome. Learning the whole modern build ecosystem was such a headache. It's great it see best practices rolled up for new users to experience.
silasb 10y ago
Very very awesome. This is very much needed. I work with a lot of older Java people and showing them the ins/outs of webpack/eslint/React is killing productivity. Thanks FB.
fdim 10y ago
Finally something that may convince me to switch from https://github.com/thardy/generator-ngbp https://github.com/thardy/generator-ngbp - all I want is to focus on writing components not figuring out how to link gazillion dependencies
robertfw 10y ago
I've solved my webpack config woes by using HJS-Webpack[0] which describes itself as "Helpers/presets for setting up webpack with hotloading react and ES6(2015) using Babel." It provides you with a base configuration object, which has been setup with any loaders that it has detected in your node_modules. You can then extend and customize as needed. [0] https://github.com/HenrikJoreteg/hjs-webpack https://github.com/HenrikJoreteg/hjs-webpack
deleted 10y ago
[deleted]
hoodoof 10y ago
This is a great idea and sorely needed. Too many frameworks rigidly avoid integration with the ecosystem because they do not want to be seen to bless any given third party technology. In the case of reactjs however it is extremely important because the ecosystem is absolutely necessary and absolutely damn complicated. This is precisely what needs to be done to help people get started. Well done.
andrewstuart 10y ago
This is the most exciting thing to come out of the ReactJS project since it started. The very best investment a technology platform can make is onboarding new developers. ReactJS is recognising that and it's great news that they are making the hardest bit easier. I whined a while back on exactly this topic. "Babel 6 - useless by default - a lesson in how NOT to design software. " http://fourlightyears.blogspot.com/2016/03/babel-6-useless-by-default-lesson-in.html http://fourlightyears.blogspot.com/2016/03/babel-6-useless-b... The last line of the above griping blog post says: "The right amount of configuration is none." So it is awesome to see someone who DOES know how to design software. Dan Abramov's blog post says: "Zero Configuration. It is worth repeating: there are no configuration files or complicated folder structures. " Babel gets it precisely wrong, this new ReactJS tools aims to correct the Babel complexity error.
- danabramov 10y ago
  Babel doesn’t get it wrong, it just wants to be a lower level tool. You can (and should) build on top IMO.
andrewstuart 10y ago
Covered on TechCrunch https://techcrunch.com/2016/07/22/facebooks-new-open-source-project-makes-it-easier-to-get-started-with-react/ https://techcrunch.com/2016/07/22/facebooks-new-open-source-...
crudbug 10y ago
Having a consistent API with ember-cli will make this more useful. $ react-cli <>
- erokar 10y ago
  Only for those used to ember-cli. For the huge majority this is irrelevant.
  - crudbug 10y ago
    It provides a consistent mental model across frameworks for building front-end applications via CLI.
    - danabramov 10y ago
      This would make people expect us to implement everything it does. We currently don't plan to.
- scarlac 10y ago
  How would it become more useful / what is more useful about it, and for who?
codenamekt 10y ago
This is great. One of the biggest hurdles is getting started which is why there are so many react boilerplates. It would be awesome to see projects like this grow so that it would auto configure based on libraries you would like to use. Want to use Redux? Just run the `create-react-app -m redux hello-world ` and you would get everything with the addition of redux and it's configuration.
mderazon 10y ago
In the spirit of zero configuration, it would be nice if it included Standard JS https://github.com/feross/standard https://github.com/feross/standard
- mrspeaker 10y ago
  Please no! One person's "standard" is another person's "Please no!".
smrtinsert 10y ago
This is not a react problem, this is a nodejs problem.
uptownhr 10y ago
wanted to share http://github.com/uptownhr/kube http://github.com/uptownhr/kube. I also wanted to tackle this problem but also handling SSR as well.
- uptownhr 10y ago
  but handles SSR as well.
thegayngler 10y ago
This was one of the downsides to us using React at work. I did a presentation on Webpack and React and my manager who is the VPE said having to figure out and choose tooling was a concern for him. I responded we should know what the tooling is doing and introduce pieces into our stack rather than go all the way in. This allows us more freedom on how and when to upgrade or change different tools in our front end stack.
deleted 10y ago
[deleted]
Bahamut 10y ago
This is great! Toolchain pain really sucks, and makes being able to get started on a project harder for many, when all you want to do is get a setup running and start creating app code. Having an opinionated CLI start up a scaffold is great - one can also peel apart this whenever one has to prepare for modifying the build chain for specific purposes (for example using Rollup to optimize bundled code, adding new build steps, etc.). The only thing I disagree with here is not allowing it to be pluggable - IMO it should be flexible and allow users to tweak the setup as desired. Of course, it should focus on getting the core experience right, but in the long term I absolutely think it would be better to have a pluggable CLI.
- andrewstuart 10y ago
  Toolchain pain is closely related to configurability i.e. "having a pluggable API". Your choices for this type of tool are zero configuration with no pain, or configurability with pain. You can't have it both ways. In the JavaScript world, configuration and pain are synonyms.
  - Bahamut 10y ago
    > In the JavaScript world, configuration and pain are synonyms. This is outright false. There is some relation, but not all configuration results in pain.
    - andrewstuart 10y ago
      It's a good enough slogan.... if more developers took it to heart then JavaScript development would not be the torturous process it is today. Any time anyone thinks about adding a configuration option they should think again and if humanly possible, take the configuration option out. Developers love making things configurable - it's a way of avoiding tough decisions about what software should and should not be able to do. The best developers are constantly looking for opportunities to remove configurability without compromising the goals of their software.
      - 10y ago
thegayngler 10y ago
So I was looking through the modules in react-scripts module and I noticed postCSS, HMR is activated (I tested this myself). I also installed react-router with ease and it appears to work just fine. So far so good from where I'm sitting. I was able to start coding right away while I was half assed looking through the modules to see what is actually in there and just play while I talked with my roommates. It took me all of 10 minutes.
brooklyndude 10y ago
Is it me, but is not Angular just taking over? Kind of Google vs Facebook thing. Just think Google won this one.
- Bahamut 10y ago
  Eh, it's not a winner takes all war - it's the quest for continual experimentation and improvement on the tools available to us for improving how we build apps. The winners are all of us.
ralusek 10y ago
For CLI generation utilities, I haven't found anything that comes close to this guy: http://fountainjs.io/ http://fountainjs.io/
bruth 10y ago
This is a great start. I too got frustrated with the overwhelming complexity of the "boilerplate" or "starter kits" that have all the bells and whistles. Having something very simple that you can exit if necessary is nice. The approach I took was just to document each tool or plugin that I may want to add to my project since it is generally very quick to do so: https://github.com/bruth/modern-javascript-starter https://github.com/bruth/modern-javascript-starter
pests 10y ago
Do not forget React is not equivalent to an SPA. Almost all SPAs give the entire body over to React but its also possible to choose a smaller DOM node and add React progressively to any existing website view that would benefit from the React paradigm. In this setup (at least) server-side rendering is no longer needed and thus simplifies setting up the build process. So its not all or nothing, you can pick and choose where to use React based on your needs and requirements.
dustinfarris 10y ago
Incredible turnaround! I remember seeing Dan Abramov's tweet [1] a while back saying React could learn from Ember's CLI. Two weeks later, here it is! Impressive! [1]: https://twitter.com/dan_abramov/status/752863664290553856 https://twitter.com/dan_abramov/status/752863664290553856
Bernastok 10y ago
The idea that Ember is made by/for small and medium sized companies is a bit dated. Several Ember and Ember-CLI core contributors have and continue to work at larger companies like LinkedIn and Yahoo. In particular, LinkedIn has been using Ember (with Ember-CLI) for over a year now and has found a lot of benefits from its adoption. Having a build system and conventions that a community maintains lets us focus on building applications instead of tooling (though we still have our share of internal tools). We also can give back to the community for things which matter more for applications "at scale". LI, for instance, funded a good portion of the FastBoot work and has been a key driver in the Ember Engines effort recently. All that to say, Ember (and Ember-CLI) can serve the needs of the whole spectrum of company/team sizes. While it still has some issues to sort out for larger applications, to say it isn't being influenced by large companies isn't really accurate any more
Lucretiant 10y ago
This is a very accurate description of the problem. We’re optimistic though. I’m sure that the community will help make Create React App even better
koistya 10y ago
There is an alternative solution that supports CSS Modules, PostCSS and HRM with React Hot Loader. Give it a try! Create a new folder for your project, then run: npm install -g react-app-tools react-app new react-app start https://hashnode.com/post/react-redux-without-webpack-ciqylw5ux02a2oh53w5k15cw1 https://hashnode.com/post/react-redux-without-webpack-ciqylw...

777 points by vjeux 10y ago

jfdk 10y ago

This is actually pretty huge. #1 complaint/barrier/hate with getting started with React is all the tooling to do it "the right way" Kudos to React team for bringing a superior pattern and making it actually practical to use.

terda12 10y ago
I'm really hoping to see the React team make React more user friendly. Maybe an all in one React framework much like Meteor, where you can just do `react createapp myapp` or something and start coding right away.
- tlrobinson 10y ago
  React is so versatile (raw React, React + Redux, React + Relay, to name a few) I don't think they should tie it too closely to one framework. I would love to see a more official/opinionated framework that uses React, but call it something besides "React". Ditto for Redux. They're both low-level building blocks that could benefit from some official "opinions".

msoad 10y ago

This is lacking tons of features that other boilerplates already have but I think this was a great move because we needed a source of truth for doing app structure in React. In a different note, I think if you write it yourself from scratch you'll have more control and knowledge down the road when it comes to nasty bugs but I won't blame you for choosing this over spending weeks setting up a React app.

donjh 10y ago
I think it's the right move for people new to React. A lot of those features in other boilerplates aren't really necessary for building out a simple app. Furthermore, the Eject feature (https://github.com/facebookincubator/create-react-app#converting-to-a-custom-setup https://github.com/facebookincubator/create-react-app#conver...) allows someone to move from the default configuration to their own when they feel comfortable.
city41 10y ago
If you work with React a lot, you can setup a React project to your taste in about 30 minutes. But the catch being if you leave React for a while then come back, all bets are off. I think most boilerplates add way too much and are overly opinionated. I like that this is simple, and "eject" gives power users an even better starting point.
- happyslobro 10y ago
  Totally. My first React setup took me two days to get right. Now, starting a new project is a 5 minute exercise in CLI autocomplete that has me wishing npmjs downloads were faster. It's surreal to think that for any popular technology, there will always be newcomers, no matter how long that technology has been around. I would write up my process in a blog post, but I'm sure that that has already been written several times.
  - happyslobro 10y ago
    Going back over my old projects and finding four different flux implementations, that is a new and interesting kind of suffering. The crazy thing is, I never even liked flux in any of its forms. What I really want, is pouchdb / couchdb, but even that is not perfect, and my team has no problem poking holes in weird ideas. Right now, I'm going through the Om.next tut series, and it is pretty awesome so far. I think I'm going to pass on datascript, though. This is total skunkworks though, if people at work found out that was using clojurescript on the front end, they would be very concerned about me. The killer feature for Om.next, imo, is using a reader function to define the relationship between a component and the one application state atom. Combine that with an identifying function that associates a component with a field in the application state, and you enable the framework to make very precise component updates.
- underwater 10y ago
  The problem is not really being overly opinionated. It's being unnecessarily opinionated. React Starter Kit comes with GraphQL as its API layer. I love GraphQL, and have written tons of it when writing Relay code, but I wouldn't ever expect someone getting up to speed on React to use it. You have to limit the number of things you throw at newcomers.
mambodog 10y ago
Most features in boilerplates are completely unnecessary for most beginner users of React. Off the top of my mind: - Server or Universal rendering - Hot Module Reloading (refreshing is fine!) - (early stage) proposed JS syntax The main thing that is missing from this package is testing, but that's a very opinionated kettle of fish.
- danabramov 10y ago
  We’ll add testing, just need to make some decisions: https://github.com/facebookincubator/create-react-app/issues/80 https://github.com/facebookincubator/create-react-app/issues...

firasd 10y ago

This is great. React has this weird dual nature in that on one hand, you can drop it in as a <script> tag and it 'just works'. On the other hand, if you want to build using it, you're going to end up needing things like webpack, babel, etc, not to mention other common libraries, to the extent that it takes over your front-end stack (also because it takes over any rendered document nodes, and if you want to build a SPA you eventually use it to render everything inside <body> if not the whole document). So it's good to resolve this conflict by providing quicker ways to get started with common tools.

amavisca 10y ago

Under the hood this is Webpack + Babel + ESLint with sane initial configuration. Love it.

griffinmichl 10y ago
This is all I ever want in a React boilerplate, but everyone feels the need to throw a bunch of random shit into them that others probably do not even want. Glad they kept it sane and simple.
- seangrogg 10y ago
  In all fairness, I think that flags that provide some basic bootstrapping for Redux and/or React-Router would be very spiffy - those tools are useful for many React applications.
  - amavisca 10y ago
    I think Redux and React-Router are very opinionated and distract people new to React from React itself. My workflow for ramping someone up on React and eventually Redux looked like: - A single React component with React.createClass - ES6 class React components - Add a component hierarchy and treat the top level component's state as the entire app state - pass down callbacks to update state. Look how this becomes harder to scale as we get more depth in our component hierarchy! - Redux without the redux-react bindings. Also stateless function components.
    - seangrogg 10y ago
      I agree. That's why I would put them behind flags. Even though most of my own projects wind up using them, I tend to start from a clean slate and apply things only as they become relevant.
- amavisca 10y ago
  As someone not new to React, I'm seeing this tool as a solid replacement to the old JSX Transformer script they used to provide. Let me get up and running just a bit more quickly.

vicapow 10y ago

I'm sucker for self descriptive "boring" names like "create-react-app" Also, sweet project!!

arianvanp 10y ago

This is really neat. especially the fact that I can 'eject' at any time when I need more power. Love it!

vlunkr 10y ago

My team has wasted so much time configuring webpack. This is a big win for React IMO.

abritinthebay 10y ago
This right here is why I actively suggest not using webpack. It's Grunt 2.0 all over again and not worth the mess. IMO it's the worst choice Facebook could have made for this toolkit, as it breeds some awful habits.
- amavisca 10y ago
  Can you add some clarity to your complaints about WebPack? What are the similarities with Grunt that aren't worth the mess and what are some of the awful habits that WebPack breeds? What are your preferred ways to handle modules and build steps in general?
- danabramov 10y ago
  What’s wrong with using webpack under the hood? The problem is webpack being a lower level tool. This is why we abstract it away from you (and we can swap it for something better if it comes along, but actually webpack is pretty powerful).
  - abritinthebay 10y ago
    We discussed this on Twitter Dan, fyi, no need to rehash here. But they very fact you had to spend time abstracting away WebPack speaks volumes IMO...
    - danabramov 10y ago
      Sorry, didn’t realize it was you :-) >But they very fact you had to spend time abstracting away WebPack speaks volumes IMO... Speaks volumes about its poor public API. I don’t understand how this this affects create-react-app, really. But if you can suggest something better that solves the same problems, please do.

ola 10y ago

I created something similar a month ago https://github.com/olahol/reactpack https://github.com/olahol/reactpack Doesn't seem like this project differs that much, although this looks to have the backing of core React developers.

pbreit 10y ago
I don't get why they would need to lock down the configuration and then have to offer the eject thingy. Couldn't they just offer a "facebook-certified" starter pack/bootstrap? I guess you could just do an immediate eject? Edit: looks like they contemplated that in the survey: "Yes, and I will run `eject` straight away"
- danabramov 10y ago
  Many people (especially beginners) appreciate automatic updates of their dependencies. If you eject straight away you’ll have to manage them yourself, which is a big turnoff to many.
  - pbreit 10y ago
    Could there be some sort of npm feature that incorporates a remote list of dependencies & versions?
    - danabramov 10y ago
      Yep, it’s called a “package”. ;-)
      - pbreit 10y ago
        So could whatever create-react-app is delivering be substantially approximated with an npm-based solution?
        danabramov 10y ago

platonichvn 10y ago

Definitely a great way to lower the barrier to entry. The eject feature is sweet since it removes the risk of lock in. Looking forward to integrated unit testing libraries in a future release. While you're at it let's add redux. :)

danabramov 10y ago
We won’t add runtime dependencies besides React for now. We are focused on solving build tooling first.

dack 10y ago

This is really great! However, I think this speaks to the need for a better API in general for this sort of stuff. At the moment it's "all or nothing" in that you can decide to let everything be configured, or nothing be configured ("ejecting"). This makes perfect sense, but I think a more ideal solution would be having layers of configurability that let you more gracefully set your preferences without completely abandoning this tool's utility. I'm not saying that's easy, but it's a direction I'd be excited to see.

danabramov 10y ago
I’d love that to be possible but “all or nothing” is useful as a forcing function for us to choose great defaults. We might want to relax it a little someday, but doing it too early will harm the project.

wrong_variable 10y ago

Just wanted to know, am I the only person who is unhappy with react ?

mrspeaker 10y ago
There are 7.4 billion people in the world. It's safe to assume you hold no unique opinions.
spicyj 10y ago
What's got you down and what could we make better?

marknadal 10y ago

The day we now see "compiled successfully" in the Command Line as the necessary "easy" starting point for frontend web devs.

rhinoceraptor 10y ago

What the heck is that terminal font?

jaytaylor 10y ago
Other than a nasty eyesore? Good question.. http://i.imgur.com/2suYgKq.png http://i.imgur.com/2suYgKq.png http://i.imgur.com/FnLVfw6.png http://i.imgur.com/FnLVfw6.png
deleted 10y ago
[deleted]
madjam002 10y ago
Operator Mono
i336_ 10y ago
Thanks so much for asking, I was wondering the same thing.

deleted 10y ago

[deleted]

kcorbitt 10y ago

Sane defaults and pieces made to go together are critical to lowering the adoption barrier and building a community, so huge props for that. But no ability to configure anything at all? I think that for most people, at some point there will be some small change to the default configuration their environment will require[1], and that means they'll need to jettison the entire project. It's nice that this is easy to do, but it would be better if it weren't necessary. [1]: For example, I run my app from within a Vagrant Virtualbox machine that doesn't forward filesystem notifications correctly, so I have to configure Webpack's hot reloader to poll for changes instead of listening for fs events.

sotojuan 10y ago
https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html#no-lock-in https://facebook.github.io/react/blog/2016/07/22/create-apps... > “Ejecting” lets you leave the comfort of Create React App setup at any time. You run a single command, and all the build dependencies, configs, and scripts are moved right into your project. At this point you can customize everything you want, but effectively you are forking our configuration and going your own way. If you’re experienced with build tooling and prefer to fine-tune everything to your taste, this lets you use Create React App as a boilerplate generator.
- danabramov 10y ago
  We’ll start with extremes (no config vs all config is yours) and see how people use it. Perhaps we’ll add some configuration later but if we do it too early, we might as well become another webpack. Configuration makes it very hard to move forward or swap underlying tools. So we’ll stick with no configuration for as long as we can, and try to figure out a way to solve common problems by other means (e.g. smarter detection, platform-specific code, etc).
  - andrewstuart 10y ago
    Please Dan keep it zero configuration. If a person knows enough to want to configure, then they have learned enough to venture out on their own via eject. The difference in cognitive load between "zero config" and "some config" is enormous. "zero configuration" === minimal mental model, no scope for misunderstandings, misconfigurations, minimal documentation, almost no scope for user errors and also minimal learning time "some configuration" - even one single switch/option === learning the mental model, understanding, version problems with the old way of configuring, documentation of configuration, potential for errors, old & out of date blog posts on the Internt telling how to do it the old way, beginner pain You will come under constant pressure from people who want to add "just this one teensy option" and will criticize the project for not having it. Resist the criticism - beginners need zero config. The root of all evil in JavaScript development and build systems is configuration.

matthoiland 10y ago

> Some features, such as testing, are currently missing. This is an intentional limitation, and we recognize it might not work for everybody. With Ember CLI you get a great testing setup with Qunit. While I prefer Mocha over Qunit, I'm at least glad that testing is a first class citizen in the CLI.

iamstef 10y ago
and its easily swappable: https://github.com/switchfly/ember-cli-mocha https://github.com/switchfly/ember-cli-mocha (and fully integrates with the existing test harness, regardless of the test framework you choose.)

orf 10y ago

> Having just attended EmberCamp a week ago, I was excited about Ember CLI. Ember users have a great “getting started” experience thanks to a curated set of tools united under a single command-line interface. This is one of the best things about Ember. `ember new`, `ember serve`, ember generate component my-component`, `ember build`, `ember deploy`, `ember install`. It's opinionated but it lets you get productive right off the bat. I tried React but after a couple of days I just couldn't get it working, waaay to many options. So I switched to Ember and haven't looked back.

sotojuan 10y ago
Don't forget: https://www.ember-fastboot.com/ https://www.ember-fastboot.com/ Also two commands to get server rendering working.
- matthoiland 10y ago
  Also don't forget: https://github.com/felixrieseberg/ember-electron https://github.com/felixrieseberg/ember-electron One command to wrap your Ember app in Electron.
- orf 10y ago
  I personally use Django as a backend for my Ember stuff, which means I miss out on the whole fastboot experience. It does look really nice though.
  - ebryn 10y ago
    Django / other backends aren't mutually exclusive with Fastboot. You can use them together.
ctvo 10y ago
Kind of interesting to think about the two projects and how they diverge based on the core developers. Ember is made by folks who work on / for small and medium companies[1]. They don't have the build infrastructure Facebook does and are able to create an anointed solution in Ember-CLI because they'll use it daily. React is stuck in a place where the environment it's developed in is unique from what any other user will see. It's difficult to solve a problem when you're not in the space. EDIT: This leads to things beyond CLIs too. React is still billed as just a view library instead of a solution for building an entire app. There's no official path from view layer -> complete app (no guidance for data flow, how to communicate with the server, server side rendering, routing on the client). I think the React team needs to take a little more responsibility for the eco-system it created. You can't call it just a view library when most use cases use it to develop entire applications. You have to provide more guidance, you can't fallback to Facebook not using it that way as the default response. In my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users trying to fill in the blanks left by the React team and producing one solution after another (and quickly abandoning ship as something iteratively better was released). 1 - Tom, Yehuda at tilde.io

thereact 10y ago

This is great since it provides an OFFICIAL opinionated set of tools for building React apps which is typically the largest barrier of entry for new developers looking to experiment with this technology. However, it is missing a lot of core features that typically come standard with Webpack/React boilerplates. Directly from their Github: Some features are currently not supported: Server rendering. Testing. Some experimental syntax extensions (e.g. decorators). CSS Modules. LESS or Sass. Hot reloading of components. So a great first set of features for a simple React starter project, but for those of you looking to expand the development toolkit from this currently limited configuration, check out the following link to search React boiler projects on github based on a number of criteria like the ability to search by features included such as CSS Modules, Hot Module Replacement, etc. http://andrewhfarmer.com/starter-project/ http://andrewhfarmer.com/starter-project/ For those looking to learn more about the ecosystem, the following resource lists might be useful. More React resources: https://github.com/enaqx/awesome-react https://github.com/enaqx/awesome-react React/Redux resource links: https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links

afarrell 10y ago
Lack of testing is a pretty big oversight given how helpful testing is for someone getting started. Hopefully it is easy to just add mocha on top of this with out any mucking around?
- danabramov 10y ago
  It shouldn’t be too hard. This is not an oversight, we literally developed this project in a single week. We plan to add testing, just need to decide on the runner and good defaults: https://github.com/facebookincubator/create-react-app/issues/80 https://github.com/facebookincubator/create-react-app/issues....
  - afarrell 10y ago
    blushes oversight was a bad choice of a word. I'm excited to see this and excited to see testing tools a part of it.

smcgraw 10y ago

Amazing.

hex13 10y ago

it seems like a solution to the Vjeux's challenge: http://blog.vjeux.com/2015/javascript/challenge-best-javascript-setup-for-quick-prototyping.html http://blog.vjeux.com/2015/javascript/challenge-best-javascr... (If we don't count sharable requirement).

vjeux 10y ago
Integration with now.sh ( https://zeit.co/now/ https://zeit.co/now/ ) and uploading to gh-pages is something that was cut for the release but we are thinking about doing :)
- deleted 10y ago
  [deleted]

venuzr 10y ago

As someone new to React, I wonder a) How is this different from getting a custom starter kit/generator from Yeoman. Searching in yeoman, I see several for "React" with the top one having over 9.5k stars http://yeoman.io/generators/ http://yeoman.io/generators/ b) Is Facebook planning to maintain and keep this generator current? Why don't they just contribute/recommend an existing generator

danabramov 10y ago
This is not a generator. It is a dependency, which means that we can (and intend to!) update the underlying tools without any work on your part. Additionally, unlike a generator, it doesn’t expose you to any configs so you can focus on your code. However you can “eject” if you really want to.

JoeCortopassi 10y ago

This is great for someone who wants to get started to learn React, but is missing a ton that is needed for a real world production app. * No isomorphic rendering * No hot module replacement * No generators * No dockerization * No Sass support * No test environment setup * No code splitting It would be cool to have a production ready tool from Facebook, but I'll stick with gluestick for now https://github.com/TrueCar/gluestick/blob/develop/README.md#why-your-project-or-boilerplate-isnt-enough https://github.com/TrueCar/gluestick/blob/develop/README.md#...

mumphster 10y ago
None of that is needed for a real world production frontend app, with the exception of maybe tests.
- JoeCortopassi 10y ago
  Granted, some things like hot module replacement and generators are not necessary, most of the others are (isomorphic rendering, code splitting, sass, dockerization). I'm not saying you need those things for your personal react app going into production, but when dealing with bigger teams for a critical app they really become important tools
  - seangrogg 10y ago
    In all fairness, most "critical apps" won't be using a standardized boilerplate anyways. It makes little sense to optimize for the least-likely consumer.
  - hex13 10y ago
    1. Sass is not as needed as it used to be (native CSS variables, PostCSS, CSS Modules, Radium, inline styles etc.). But of course many users prefer Sass. But Sass in its CSS syntax (SCSS) is (if I'm correct) just super set of CSS. You can always start project using vanilla CSS and when project will grow, you can add Sass. There are two approaches to develop new projects: big design up front and YAGNI principle (you ain't gonna need it). I prefer YAGNI and I'm glad that Facebook generator is so minimal. But I don't know what they are planning to do with this project. I think this project would be a lot worse if they forced to use Sass(or Radium or any opinionated CSS solution). 2. code splitting? If I understand correctly it's Webpack feature needed mainly for production, not development. So why to add this on the very beginning of your project?

griffinmichl 10y ago

After spending hours yesterday teaching a colleague about webpack, babel, configuration, etc, this is exactly what the React community needs. Finally some fucking sanity in the ecosystem.

mcs_ 10y ago

Thanks !!!

stoikerty 10y ago

I'm fairly close to finishing the conversion of my `dev-toolkit` into an npm-module. It is almost no-config, has scss, server-side-rendering, hot-reload and more. I'm a one man band but will get there. It's all on https://github.com/stoikerty/universal-dev-toolkit https://github.com/stoikerty/universal-dev-toolkit The npm-version sits in a feature branch, just look for the corresponding PR if you're keen.

stoikerty 10y ago
I have a release ready. Just pinned it at 5.0.3 It is similar to `create-react-app` but also has CSS-Modules (with SCSS) and a few other features like Browsersync and root-relative imports. Hope anyone reading this finds it useful :) https://github.com/stoikerty/dev-toolkit https://github.com/stoikerty/dev-toolkit

kjhughes 10y ago

Does this help with React Native too?

vjeux 10y ago
React Native already has `react-native init <project-name>` command that works in a similar fashion.

lucaspottersky 10y ago

Expectation: - "Hey, look, this can SOLVE ALL THE PROBLEMS" Reality: - "Hey, look, this actually BRINGS IN A WHOLE LOT OF OTHER PROBLEMS too!" :sad:

Splendor 10y ago
Would you mind explaining which new problems this creates?
- abritinthebay 10y ago
  WebPack for one. Using webpack brings in way more problems than it solves.
  - danabramov 10y ago
    Sure, if you use it directly. The biggest complaint about webpack is it’s hard to configure. We configure it for you. You don’t need to think about it. What other problems does webpack bring in your opinion? File an issue and let us know: https://github.com/facebookincubator/create-react-app/issues/ https://github.com/facebookincubator/create-react-app/issues...
  - Splendor 10y ago
    Again you've suggested the introduction of problems without mentioning a single one. I'm not saying you're wrong (because I don't know what you're saying yet), but I don't think you're adding much to the discussion here.
danabramov 10y ago
We’d love to hear about the problems. https://github.com/facebookincubator/create-react-app/issues/ https://github.com/facebookincubator/create-react-app/issues...

seangrogg 10y ago

I think one of the best things I've done to date is actually distance myself from the React community. While I love some of the tooling that has come out of it (Redux, React-Router) I think the community (as an amorphous entity) over-emphasizes the need/desire for transpiling, linting, testing, etc. Since then, I've "reverted" to building things in ES5, working in multiple files without bundling, etc. and I have to say the enjoyment I get out of using React has cranked up considerably. I am happy to see they are converging on some standards - that will definitely make building new apps much easier from a common starting point. I just hope they can walk the fine line between "opinionated" and "bloated".

sotojuan 10y ago
I was just talking about this with coworkers... I love React but the community (aside from the actual creators and leaders like Dan) is too much for me and seem to love bloat and unnecessary features. The cynical side of me thinks a lot just do it for GitHub stars and blog views, but maybe not. Of course, we just spent two days trying to decipher a React/Redux project whose lead dev decided to use every "latest" feature even though it's a good ol' CRUD app.
- danabramov 10y ago
  We think ES6 is not the problem here. It’s just a language, and arguably a better one than ES5. The problem is the low level tooling around it. This is what we’re trying to fix with this project. Hopefully you’ll give it a go, and maybe it will give you just as much enjoyment as using <script> tags. If not, please let us know how we can improve. It’s not linting/transpilation/bundling that’s bad, it’s that it’s hard to do them without shooting yourself in the foot.
  - sotojuan 10y ago
    I definitely use ES6 for sure, though nothing too crazy (no decorators, bind :: thingy, etc). Do you remember how you were telling people on Twitter that they don't need every single crazy feature and every single thing in the Redux store (or even Redux at all) to do React? The kind of people I am complaining about are the ones that say the opposite.

Exuma 10y ago

Looks cool

deepsun 10y ago

Is there something like this for React Native? I'm interested in recommended directory structure.

ed 10y ago
This is kind of built in to React Native already, but they use their own packager (ReactPackager) instead of webpack. Would be neat for ReactJS and React Native tools to converge at some point!

tlrobinson 10y ago

I think the best part of this is the "eject" feature. It's great to be able to spin something up quickly but migrate to a custom solution if you outgrow it. However, it would be nice to be able to tweak some of the configurations (Babel, ESLint, Webpack) without completely "ejecting".

danabramov 10y ago
If we let you tweak them, any minor update on our part would be a breaking change. We wouldn’t be able to introduce new features or update the underlying tools without a lot of risk. This is why we don’t let you change the configs. If you have a specific pain point, please file an issue. I think we can make defaults better. It takes more work but is more rewarding in the end because it benefits everyone.
- cheapsteak 10y ago
  This is super useful for helping beginners overcome initial barriers and quickly become productive, but do you see this as something that most will eventually grow out of?
  - danabramov 10y ago
    When you grow out of it, you run "eject" and customize everything you want. We think in the beginning many will "eject" but we will gradually make the defaults better to cover more and more use cases.
    - tlrobinson 10y ago
      That makes sense, but I think there will always be people who want to tweak ESLint rules or enable new Babel features, but would still like to take advantage of improvements to this project. Perhaps exposing a subset of those tools' configuration options would be sufficient. Alternatively, you could imagine a pretty simple system that allows you to pull newer versions of the "ejected" code and handle merge conflicts using your version control software. I'd also suggest reducing the amount of non-configuration code that's generated by "eject". I think basically everything in "scripts" could be put into a package ("openChrome.applescript" seems like it should be a feature of opn anyway). That would also reduce the number of devDependencies that need to be added to your project's package.json (rimraf, chalk, opn, etc)

mohsinr 10y ago

Loving it! I always wanted to get started with ReactJs but looks like time has come! I tried the module and I am loving the "Welcome to React" page on my localhost! Thank you!!! PS. Already in /src/App.js , and wow live reloading without gulp or browersync , it is so simple to get started! Thank you!

robertfw 10y ago
I thought the live reloading was just for CSS?
- danabramov 10y ago
  Yep. For components we refresh the page now. (Automatically still.)

joemaller1 10y ago

This is great and I will be moving my React projects in this direction. At very least this project represents a de-facto standard and guidance about how to work with React. However I do wish the React team would pick between ES6 classes and `React.createClass`. I think I remember the main React tutorial was rewritten in ES6 at one point, but then switched back. I've read arguments both ways, but I suspect they ES6 is still too much of a barrier to entry. People who aren't up to speed with ES6 will still be shaving a lot of yaks before actually jumping into React.

lacker 10y ago
If you're using create-react-app then you're encouraged to use ES6 classes - that's how the default App.js is set up.
- danabramov 10y ago
  >However I do wish the React team would pick between ES6 classes and `React.createClass` We’re going with ES6 classes. Expect createClass() to go into another package some time this year. (Obviously we’ll provide an automated “codemod” utility to convert your existing code.)
  - anthonybullard 10y ago
    Please say it isn't so! Class is terrible syntactic sugar to please old Java programmers. I'd be really interested in why this decision would be made. Im just getting going in React and am looking to make a move away from Angular, because Angular 2 is so hyper focused on classes and decorators. I like React because it's closer on the purity scale to something like Cycle.js. But nevermind me, React is a great tool, and this is a very nice and needed project!
    - acemarke 10y ago
      React's lifecycle methods and other similar features require some kind of "object instance" to exist. Since React was created prior to ES6, the React team created their own "inheritance"-ish approach, which is something that every JS library out there was doing as well. One of the main arguments for classes being included in the ES6 standard is that it's a common approach that libraries can converge on and use together, rather than every library inventing their own version of inheritance. Since ES6+ is now the actual Javascript language standard, it makes sense for React to move away from their homegrown class definition approach, and build on top of the approach that is now standardized in the language. The React community has already eagerly adopted ES6, and while React.createClass() isn't going to be deleted any time soon, it's time to start encouraging people to move away from using it. Either way, though, React's API _does_ depend on having something "class"-like available.

mfrye0 10y ago

This is awesome. Learning the whole modern build ecosystem was such a headache. It's great it see best practices rolled up for new users to experience.

silasb 10y ago

Very very awesome. This is very much needed. I work with a lot of older Java people and showing them the ins/outs of webpack/eslint/React is killing productivity. Thanks FB.

fdim 10y ago

Finally something that may convince me to switch from https://github.com/thardy/generator-ngbp https://github.com/thardy/generator-ngbp - all I want is to focus on writing components not figuring out how to link gazillion dependencies

robertfw 10y ago

I've solved my webpack config woes by using HJS-Webpack[0] which describes itself as "Helpers/presets for setting up webpack with hotloading react and ES6(2015) using Babel." It provides you with a base configuration object, which has been setup with any loaders that it has detected in your node_modules. You can then extend and customize as needed. [0] https://github.com/HenrikJoreteg/hjs-webpack https://github.com/HenrikJoreteg/hjs-webpack

deleted 10y ago

[deleted]

hoodoof 10y ago

This is a great idea and sorely needed. Too many frameworks rigidly avoid integration with the ecosystem because they do not want to be seen to bless any given third party technology. In the case of reactjs however it is extremely important because the ecosystem is absolutely necessary and absolutely damn complicated. This is precisely what needs to be done to help people get started. Well done.

andrewstuart 10y ago

This is the most exciting thing to come out of the ReactJS project since it started. The very best investment a technology platform can make is onboarding new developers. ReactJS is recognising that and it's great news that they are making the hardest bit easier. I whined a while back on exactly this topic. "Babel 6 - useless by default - a lesson in how NOT to design software. " http://fourlightyears.blogspot.com/2016/03/babel-6-useless-by-default-lesson-in.html http://fourlightyears.blogspot.com/2016/03/babel-6-useless-b... The last line of the above griping blog post says: "The right amount of configuration is none." So it is awesome to see someone who DOES know how to design software. Dan Abramov's blog post says: "Zero Configuration. It is worth repeating: there are no configuration files or complicated folder structures. " Babel gets it precisely wrong, this new ReactJS tools aims to correct the Babel complexity error.

danabramov 10y ago
Babel doesn’t get it wrong, it just wants to be a lower level tool. You can (and should) build on top IMO.

andrewstuart 10y ago

Covered on TechCrunch https://techcrunch.com/2016/07/22/facebooks-new-open-source-project-makes-it-easier-to-get-started-with-react/ https://techcrunch.com/2016/07/22/facebooks-new-open-source-...

crudbug 10y ago

Having a consistent API with ember-cli will make this more useful. $ react-cli <>

erokar 10y ago
Only for those used to ember-cli. For the huge majority this is irrelevant.
- crudbug 10y ago
  It provides a consistent mental model across frameworks for building front-end applications via CLI.
  - danabramov 10y ago
    This would make people expect us to implement everything it does. We currently don't plan to.
scarlac 10y ago
How would it become more useful / what is more useful about it, and for who?

codenamekt 10y ago

This is great. One of the biggest hurdles is getting started which is why there are so many react boilerplates. It would be awesome to see projects like this grow so that it would auto configure based on libraries you would like to use. Want to use Redux? Just run the `create-react-app -m redux hello-world ` and you would get everything with the addition of redux and it's configuration.

mderazon 10y ago

In the spirit of zero configuration, it would be nice if it included Standard JS https://github.com/feross/standard https://github.com/feross/standard

mrspeaker 10y ago
Please no! One person's "standard" is another person's "Please no!".

smrtinsert 10y ago

This is not a react problem, this is a nodejs problem.

uptownhr 10y ago

wanted to share http://github.com/uptownhr/kube http://github.com/uptownhr/kube. I also wanted to tackle this problem but also handling SSR as well.

uptownhr 10y ago
but handles SSR as well.

thegayngler 10y ago

This was one of the downsides to us using React at work. I did a presentation on Webpack and React and my manager who is the VPE said having to figure out and choose tooling was a concern for him. I responded we should know what the tooling is doing and introduce pieces into our stack rather than go all the way in. This allows us more freedom on how and when to upgrade or change different tools in our front end stack.

deleted 10y ago

[deleted]

Bahamut 10y ago

This is great! Toolchain pain really sucks, and makes being able to get started on a project harder for many, when all you want to do is get a setup running and start creating app code. Having an opinionated CLI start up a scaffold is great - one can also peel apart this whenever one has to prepare for modifying the build chain for specific purposes (for example using Rollup to optimize bundled code, adding new build steps, etc.). The only thing I disagree with here is not allowing it to be pluggable - IMO it should be flexible and allow users to tweak the setup as desired. Of course, it should focus on getting the core experience right, but in the long term I absolutely think it would be better to have a pluggable CLI.

andrewstuart 10y ago
Toolchain pain is closely related to configurability i.e. "having a pluggable API". Your choices for this type of tool are zero configuration with no pain, or configurability with pain. You can't have it both ways. In the JavaScript world, configuration and pain are synonyms.
- Bahamut 10y ago
  > In the JavaScript world, configuration and pain are synonyms. This is outright false. There is some relation, but not all configuration results in pain.
  - andrewstuart 10y ago
    It's a good enough slogan.... if more developers took it to heart then JavaScript development would not be the torturous process it is today. Any time anyone thinks about adding a configuration option they should think again and if humanly possible, take the configuration option out. Developers love making things configurable - it's a way of avoiding tough decisions about what software should and should not be able to do. The best developers are constantly looking for opportunities to remove configurability without compromising the goals of their software.
    - 10y ago

thegayngler 10y ago

So I was looking through the modules in react-scripts module and I noticed postCSS, HMR is activated (I tested this myself). I also installed react-router with ease and it appears to work just fine. So far so good from where I'm sitting. I was able to start coding right away while I was half assed looking through the modules to see what is actually in there and just play while I talked with my roommates. It took me all of 10 minutes.

brooklyndude 10y ago

Is it me, but is not Angular just taking over? Kind of Google vs Facebook thing. Just think Google won this one.

Bahamut 10y ago
Eh, it's not a winner takes all war - it's the quest for continual experimentation and improvement on the tools available to us for improving how we build apps. The winners are all of us.

ralusek 10y ago

For CLI generation utilities, I haven't found anything that comes close to this guy: http://fountainjs.io/ http://fountainjs.io/

bruth 10y ago

This is a great start. I too got frustrated with the overwhelming complexity of the "boilerplate" or "starter kits" that have all the bells and whistles. Having something very simple that you can exit if necessary is nice. The approach I took was just to document each tool or plugin that I may want to add to my project since it is generally very quick to do so: https://github.com/bruth/modern-javascript-starter https://github.com/bruth/modern-javascript-starter

pests 10y ago

Do not forget React is not equivalent to an SPA. Almost all SPAs give the entire body over to React but its also possible to choose a smaller DOM node and add React progressively to any existing website view that would benefit from the React paradigm. In this setup (at least) server-side rendering is no longer needed and thus simplifies setting up the build process. So its not all or nothing, you can pick and choose where to use React based on your needs and requirements.

dustinfarris 10y ago

Incredible turnaround! I remember seeing Dan Abramov's tweet [1] a while back saying React could learn from Ember's CLI. Two weeks later, here it is! Impressive! [1]: https://twitter.com/dan_abramov/status/752863664290553856 https://twitter.com/dan_abramov/status/752863664290553856

Bernastok 10y ago

The idea that Ember is made by/for small and medium sized companies is a bit dated. Several Ember and Ember-CLI core contributors have and continue to work at larger companies like LinkedIn and Yahoo. In particular, LinkedIn has been using Ember (with Ember-CLI) for over a year now and has found a lot of benefits from its adoption. Having a build system and conventions that a community maintains lets us focus on building applications instead of tooling (though we still have our share of internal tools). We also can give back to the community for things which matter more for applications "at scale". LI, for instance, funded a good portion of the FastBoot work and has been a key driver in the Ember Engines effort recently. All that to say, Ember (and Ember-CLI) can serve the needs of the whole spectrum of company/team sizes. While it still has some issues to sort out for larger applications, to say it isn't being influenced by large companies isn't really accurate any more

Lucretiant 10y ago

This is a very accurate description of the problem. We’re optimistic though. I’m sure that the community will help make Create React App even better

koistya 10y ago

There is an alternative solution that supports CSS Modules, PostCSS and HRM with React Hot Loader. Give it a try! Create a new folder for your project, then run: npm install -g react-app-tools react-app new react-app start https://hashnode.com/post/react-redux-without-webpack-ciqylw5ux02a2oh53w5k15cw1 https://hashnode.com/post/react-redux-without-webpack-ciqylw...