Create React Apps with No Configuration(facebook.github.io)
facebook.github.io
Create React Apps with No Configuration
https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html
249 comments
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?
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....
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....
I really would love to see all the "features" listed above (and more) as a part of this tool.
eg; `create-react-app --hot --less`
Including commonly-used defaults first, and adding full community bundling later, would be much appreciated. There are probably <10 such packages which would account for a wide range of the first week or so of any React project.
Good luck with this project and thanks a ton for dreaming it up & getting it out the door!
eg; `create-react-app --hot --less`
Including commonly-used defaults first, and adding full community bundling later, would be much appreciated. There are probably <10 such packages which would account for a wide range of the first week or so of any React project.
Good luck with this project and thanks a ton for dreaming it up & getting it out the door!
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.
Thanks for plugging my list :) VERY happy to see that people are finding it a useful set of resources, and I'm continuing to add links to it as I go. I'm trying to find more intermediate/advanced content to fill it out, as I figure I've got more than enough basic tutorials listed for now.
> 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.
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.
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
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
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.
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.
Having worked at LinkedIn in the past, and seeing the state (stagnation) of their products both current and past, that's certainly not a ringing endorsement.
For anyone else curious about Ember Engines, I found the RFC provided a good explantion of the what and why:
https://github.com/tomdale/rfcs/blob/master/active/0000-engi...
https://github.com/tomdale/rfcs/blob/master/active/0000-engi...
> 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).
I agree wholeheartedly with this. And it's also why I love Ember, you get templates, routing, data access all working together with minimal configuration. I love Django and part of the reason why is that it's opinionated, and Ember is the same.
I agree wholeheartedly with this. And it's also why I love Ember, you get templates, routing, data access all working together with minimal configuration. I love Django and part of the reason why is that it's opinionated, and Ember is the same.
I found Ember was much harder to get started with than React.
More concepts, it's own CLI and build system, outdated docs. (I used it 2 years ago)
More concepts, it's own CLI and build system, outdated docs. (I used it 2 years ago)
2 years ago is decades in the front-end world. If we make decisions today based on the state of things years ago, we'd be screwed.
And yet nothing much changed in the needs of webapps or in the Javascript language in the past two years.
And if we CAN'T "make decisions today based on the state of things years ago", then we're really screwed.
And if we CAN'T "make decisions today based on the state of things years ago", then we're really screwed.
> And yet nothing much changed in the needs of webapps or in the Javascript language in the past two years.
But Ember has likely come a long way in that time - I think this is mcardleliam's point.
But Ember has likely come a long way in that time - I think this is mcardleliam's point.
For me the creation of ember cli was like admiting their framework didn't work as good as they intended.
I'm sorry, Ember has come a huge way in 2 years. We've got 2.0, which was a big leap forward, a whole bunch of concepts were refined/removed or changed.
Also you're flat out wrong: Ember-cli isn't really anything to do with the framework. You don't need it to write Ember apps, it's just the communities command line tool for managing Ember projects. That's all.
Also you're flat out wrong: Ember-cli isn't really anything to do with the framework. You don't need it to write Ember apps, it's just the communities command line tool for managing Ember projects. That's all.
This is only theoretically right.
Practically, there are Ember modules/extensions/features that require Ember-CLI to work or are a huge pain to work with, if you don't use the CLI...
for example animation libraries or glimmer.
Practically, there are Ember modules/extensions/features that require Ember-CLI to work or are a huge pain to work with, if you don't use the CLI...
for example animation libraries or glimmer.
> 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.
This is the reason I've embraced React. No, Facebook doesn't dictate how React fits into the rest of your app, and yes, it requires more effort up front to fit the pieces together. But judging by the popularity of React vs. kitchen-sink frameworks like Ember/React/etc., many developers seem willing to invest this effort.
Another comment here mentions Django; clearly some developers prefer the batteries included approach, but others don't. Is one preference right and the other wrong? Is any developer that doesn't adhere to your preference not taking "responsibility"?
This is the reason I've embraced React. No, Facebook doesn't dictate how React fits into the rest of your app, and yes, it requires more effort up front to fit the pieces together. But judging by the popularity of React vs. kitchen-sink frameworks like Ember/React/etc., many developers seem willing to invest this effort.
Another comment here mentions Django; clearly some developers prefer the batteries included approach, but others don't. Is one preference right and the other wrong? Is any developer that doesn't adhere to your preference not taking "responsibility"?
It's a matter of encouraging health in a community. A lack of proper resources(which can be everything from documentation, tutorials, guides, libraries, to tools like Ember-CLI) can lead to mistakes in design and part of your community going off on a tangent, which leads to dead branches of development trees.
For example: While React still works for a lot of people who did things in ways advocated early on, the rise of Redux and functional reactive programming has caused the community to move in a direction many library authors weren't aware of when they began.
Is it anyone's fault? No, not really- but taking advantage of stewardship in a community can lead to better tools and resources that help newbies, take some of the work out of your hands, and keep quality for everyone as high as possible.
For example: While React still works for a lot of people who did things in ways advocated early on, the rise of Redux and functional reactive programming has caused the community to move in a direction many library authors weren't aware of when they began.
Is it anyone's fault? No, not really- but taking advantage of stewardship in a community can lead to better tools and resources that help newbies, take some of the work out of your hands, and keep quality for everyone as high as possible.
Absolutely agree. Innovation also is much easier when not boxed into one approach. It's like people are blaming react for the revolution it created on the client side.
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.
Sorry I edited in a WHOLE bunch more that you probably wouldn't agree with after your reply. Apologies!
Lol.
No, I still fully agree.
We think React is a tool to create great UIs, and UIs definitely include concerns like data fetching, etc. So some of this might make it into React in some form in the future.
No, I still fully agree.
We think React is a tool to create great UIs, and UIs definitely include concerns like data fetching, etc. So some of this might make it into React in some form in the future.
In the meantime, you can also try out the official Flux library from Facebook (https://github.com/facebook/flux), or Redux (https://github.com/reactjs/redux), which offer great solutions for data manipulation and storage
I think he knows about those two options.
(The guy you're responding to is the creator of Redux) :-)
(The guy you're responding to is the creator of Redux) :-)
And now working for Facebook, one of the most active members of the react team at that.
Facebook created React.
Parent did not say Facebook itself is one of the most active members of the React team. They know Facebook created React.
They say that Dan, at Facebook, is one the most active members of the React team.
They say that Dan, at Facebook, is one the most active members of the React team.
Who wants to tell him Dan wrote Redux?
Another great thing about ember-cli is that it has very quickly build around it a great community [1]. There are a lot of high quality, well tested addons that are easy to install and use, and it's easy to create your own as well.
[1]: https://emberobserver.com/
[1]: https://emberobserver.com/
The best part about ember-cli is that everyone in the Ember community uses it. No one builds Ember apps without it. The opposite is true of any community/third party React CLI and it's a very powerful difference.
I'd say Webpack plays that role in the React community, just without a blessed and shared way to configure it.
> 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).
Every time I've decided to take an afternoon to poke at React this is where I've given up. I totally understand the model and appreciate how useful it can be but I've never been clear about how to actually hook it up to a backend that isn't just the generated demo scenario and what the requirements for my backend would be.
Every time I've decided to take an afternoon to poke at React this is where I've given up. I totally understand the model and appreciate how useful it can be but I've never been clear about how to actually hook it up to a backend that isn't just the generated demo scenario and what the requirements for my backend would be.
I think this is common. For me the front page and JSX threw me off. React was so un-opinionated that it can loose its appeal when it presents itself. Once I took an opinionated tutorial it became much clearer to me.
Since then I've used React in conjunction with Django, PHP/Laravel, converted large jQuery codebases to React and created frontend-only sites. I've not yet gone full-on with a NodeJS back-end and isomophic and that's fine for now.
Pass your data into a root component via props. Or use XHR requests to load data from your backend into your root component and manipulate them in your state. Let the data changes in the root component trickle down via props. Keep it simple with React loaded via a <script> tag and work from there.
Since then I've used React in conjunction with Django, PHP/Laravel, converted large jQuery codebases to React and created frontend-only sites. I've not yet gone full-on with a NodeJS back-end and isomophic and that's fine for now.
Pass your data into a root component via props. Or use XHR requests to load data from your backend into your root component and manipulate them in your state. Let the data changes in the root component trickle down via props. Keep it simple with React loaded via a <script> tag and work from there.
No, that becomes a nightmare to maintain. Use Redux and connect any component that needs data to the store and get the data needed directly.
Not much more to say about this than that I do not agree, that I think flux-alikes are overused, and that it's just as easy to go too far the other direction, where nothing has any state even for trivial UI state concerns.
Agreed.
It seems like an afternoon is an awfully short time to allot to try a new framework / approach. I have definitely found lots in the Frontend world extremely frustrating at first given there are so many ways to do something, but it eventually clicks and makes sense.
I like React the way it is. It does one thing and does it well.
I suppose that's the price people will pay for needing the latest shiny (React) instead of the now old and boring Ember or AngularJs. And also thinking that the solution that works for Facebook is the one that is the best fit for a small startup, because someday they will reach Facebook's size.
To clarify, I like old and boring because it generates less JavaScript fatigue.
To clarify, I like old and boring because it generates less JavaScript fatigue.
You don't think a legacy AngularJS project is full of "fatigue"? I shudder at the thought. Angular 1 is so awful, even the creator himself, Misko said it really wasn't intended to be used in this way.
I know the cool thing amongst us older folk are to say "Oh there goes them darn ole kids chasing their new toys again" but this is a case where very clearly one is much more suited for the job than the other. There's nothing wrong with a winner emerging. All of the "problems" people gripe about here about React can be avoided. I have posted this before, but I'll post it here again -- You wouldn't go to learn how to program Java by first learning how to configure maven, download dependencies, set up your project in an IDE, and then build and deploy your WAR through Jenkins into a J2EE container for "Hello World"
React has all the goodies provided by the community, but React IS just a library. If you want to learn React -- copy and paste the latest CDN, use the in-browser transformer, and freaking learn react. The tutorials are great, and so is the article "Thinking in react"
In any case, I haven't looked at this CLI, but if it's anything like the ember-cli I am sure it will help with the artificial gripes.
I know the cool thing amongst us older folk are to say "Oh there goes them darn ole kids chasing their new toys again" but this is a case where very clearly one is much more suited for the job than the other. There's nothing wrong with a winner emerging. All of the "problems" people gripe about here about React can be avoided. I have posted this before, but I'll post it here again -- You wouldn't go to learn how to program Java by first learning how to configure maven, download dependencies, set up your project in an IDE, and then build and deploy your WAR through Jenkins into a J2EE container for "Hello World"
React has all the goodies provided by the community, but React IS just a library. If you want to learn React -- copy and paste the latest CDN, use the in-browser transformer, and freaking learn react. The tutorials are great, and so is the article "Thinking in react"
In any case, I haven't looked at this CLI, but if it's anything like the ember-cli I am sure it will help with the artificial gripes.
I don't think a legacy AngularJS project is necessarily full of any more fatigue than a React project will be in a few years time.
That's not really fair, though. It will be a React + x + y + z project, because as you said, React is just a library, and it needs other pieces to fill the gaps provided by some of these other frameworks.
I could be wrong, but it will take a couple years to tell. By then, React will be old news also.
That's not really fair, though. It will be a React + x + y + z project, because as you said, React is just a library, and it needs other pieces to fill the gaps provided by some of these other frameworks.
I could be wrong, but it will take a couple years to tell. By then, React will be old news also.
Google has similar issues: if you're working on open source software, some tools have to be written twice, for internal and external developers.
The problem is that when frameworks develop these CLIs they tend to think only about the CLI users and it becomes larger and larger a requirement. Personally I'm a web developer, I don't want to be a React developer or an Ember developer, etc. so the more difficult you make it to use your stuff with normal web technologies the less I want to have anything to do with it.
> The problem is that when frameworks develop these CLIs they tend to think only about the CLI users and it becomes larger and larger a requirement
Well there are two ways to modify an Ember project: create a bunch of files in various places by hand, or run `ember whatever` and have it done for you. The CLI is the preferred way of doing it for a lot of (good) reasons but if you want a new component running `ember g my-component` and having it make the component JS file, the template and the tests for you in one fell swoop is awesome.
> so the more difficult you make it to use your stuff with normal web technologies the less I want to have anything to do with it.
I don't understand your point? What's a 'normal web technology'?
Well there are two ways to modify an Ember project: create a bunch of files in various places by hand, or run `ember whatever` and have it done for you. The CLI is the preferred way of doing it for a lot of (good) reasons but if you want a new component running `ember g my-component` and having it make the component JS file, the template and the tests for you in one fell swoop is awesome.
> so the more difficult you make it to use your stuff with normal web technologies the less I want to have anything to do with it.
I don't understand your point? What's a 'normal web technology'?
> I don't understand your point? What's a 'normal web technology'?
https://html.spec.whatwg.org/multipage/
https://html.spec.whatwg.org/multipage/
So you want to write HTML for a living? Ok, that's cool. But things have moved on a bit since then.
I mean, you're commenting on a thread about JS libraries that enable you to write awesome single page apps and saying you... don't want to write JS?
If I get you correctly then I used to be like you. "Eww, javascript". Then I was forced to use Ember for a project where I work and it is amazing, nothing that the app does could even remotely be done with HTML or even a bunch of jQuery spaghetti.
I mean, you're commenting on a thread about JS libraries that enable you to write awesome single page apps and saying you... don't want to write JS?
If I get you correctly then I used to be like you. "Eww, javascript". Then I was forced to use Ember for a project where I work and it is amazing, nothing that the app does could even remotely be done with HTML or even a bunch of jQuery spaghetti.
JavaScript is part of the HTML standard so I'm ok with that. What I'm not OK with is the expectation that I'm going to run 20 tools between editing a file and refreshing my browser.
They are saying that they aren't going to make the CLI a requirement and I hope that's the case, but my concern is that "use the CLI" is going to become the quick answer.
They are saying that they aren't going to make the CLI a requirement and I hope that's the case, but my concern is that "use the CLI" is going to become the quick answer.
But that's the beauty of Ember: you run one tool. `ember`. Sure it uses Babel under the hood and a CSS preprocessor, but they are not separate tools really.
But what exactly is wrong with a CLI? I'm sorry but I really don't get your point. I mean, you kind of have to run one or more anyway if you want to do modern JS development because the JS you write isn't the JS that gets served to the browser (and for good reason). A CLI is a requirement and has been for a while now.
But what exactly is wrong with a CLI? I'm sorry but I really don't get your point. I mean, you kind of have to run one or more anyway if you want to do modern JS development because the JS you write isn't the JS that gets served to the browser (and for good reason). A CLI is a requirement and has been for a while now.
> A CLI is a requirement and has been for a while now.
It's really not, you can get by fine with a text editor and a web browser only. You can use regular web components (works unmodified in Chrome, there's a polyfill for other browsers) and get modularity and all of the things you need. You can add Polymer which, again, doesn't require anything but an editor and a browser.
It's really not, you can get by fine with a text editor and a web browser only. You can use regular web components (works unmodified in Chrome, there's a polyfill for other browsers) and get modularity and all of the things you need. You can add Polymer which, again, doesn't require anything but an editor and a browser.
Do you combine and minify your code? If so, how—presumably a command-line tool? It's totally fine to say that you'd prefer to keep your dependencies fairly minimal, but pinning that on whether you use a CLI or not seems a false dichotomy from here. The question is how much tooling and what it does for you, versus what it gives you. There is no doubt a real tradeoff there; there are costs to something like Ember CLI and there's no reason everyone should think those costs are worth embracing in every instance. But to be sure, there are upsides: being able to write ES2015, being able to pull in tests automatically, being able to run your entire test suite against the entire app without needing to write any glue to do that yourself... those things do have value, even if they're not particularly appealing to you. And all of those quite comfortably use the official specs to get that work done.
That said, someone could probably code a locally hosted react app that wrapped the CLI, and also indicated/logged what commands were run, output, errors, etc.
I love CLI, I live in vim and tmux as much as I can, but I think point and click interfaces are better for discovery, whereas a command line interface is better for reproducibility and therefore instructional learning.
I love CLI, I live in vim and tmux as much as I can, but I think point and click interfaces are better for discovery, whereas a command line interface is better for reproducibility and therefore instructional learning.
One of React's big selling points is easy integration into existing apps so we don't plan to neglect non-CLI users.
Don't forget:
https://www.ember-fastboot.com/
Also two commands to get server rendering working.
https://www.ember-fastboot.com/
Also two commands to get server rendering working.
Also don't forget:
https://github.com/felixrieseberg/ember-electron
One command to wrap your Ember app in Electron.
I love the opinions I get with Ember and love it for getting small projects off the ground quickly and prototyped.
One thing I don't see a lot of is opinions in React on deploying. I wrote a blog post on deploying this new boiler using netlify, pretty straight forward. https://www.netlify.com/blog/2016/07/22/deploy-react-in-30-s...
One thing I don't see a lot of is opinions in React on deploying. I wrote a blog post on deploying this new boiler using netlify, pretty straight forward. https://www.netlify.com/blog/2016/07/22/deploy-react-in-30-s...
Having used Ember and React, this was my experience too. Ember lets you get up and running really fast. However, once you start doing anything outside of something it doesn't have an opinion about, you're stuck working around the framework. Good luck with that.
At the end of last summer we started to make the migration from Ember to React, and we removed the last Ember code from our code base in April of this year. It has been a slow process, but it has paid off immensely in productivity. I'd rather write code to solve all my problems than have a solution that solves 90% of my problems out of the box but then makes solving the remaining 10% a hacky, unpredictable process.
At the end of last summer we started to make the migration from Ember to React, and we removed the last Ember code from our code base in April of this year. It has been a slow process, but it has paid off immensely in productivity. I'd rather write code to solve all my problems than have a solution that solves 90% of my problems out of the box but then makes solving the remaining 10% a hacky, unpredictable process.
> I'd rather write code to solve all my problems than have a solution that solves 90% of my problems out of the box but then makes solving the remaining 10% a hacky, unpredictable process.
So are you saying that, absent a better framework than Ember, you would have recommended migrating to no framework at all?
So are you saying that, absent a better framework than Ember, you would have recommended migrating to no framework at all?
No, when I say "I'd rather write code to solve all my problems" I'm talking about React. In React, things happen because you call a function, not because you named something the name that makes them get called, with only a handful of exceptions. You want to change the state, you call `setState`, you want to render the component you call `renderComponent`. It all looks surprisingly like writing code with a very helpful library.
I've done a lot of React but have since been burned out by it. It takes so much configuration just to set up something basic like server side rendering. After a year of hacking around with React and wallowing through the pain, I decided to just use Django and django templates. React is nice for a whole company that has one app with a tough initial setup but great performance in the long run, but its hard for individual hackers like me who just want to get tiny webapps up and running.
I'm going to write some examples but I've started putting down my alternative setup without flux. I think it's a much simpler/nicer setup.
Would appreciate feedback:
https://github.com/lancecarlson/react-mvc
Would appreciate feedback:
https://github.com/lancecarlson/react-mvc
I've been exploring an alternative solution.
Currently playing around with the idea of a React app for building React apps.
Basically, it's an admin for specifying routes, models, components, database schemas, views, stores, reducers, etc. They are defined declaratively and serialized. Then can be feed to either a build step or a bootstrap that can load create the app dynamically.
Each type of thing that can be edited has its own dedicated UX.
Not much built yet but I'd be curious if anyone else has similar ideas / solutions.
Currently playing around with the idea of a React app for building React apps.
Basically, it's an admin for specifying routes, models, components, database schemas, views, stores, reducers, etc. They are defined declaratively and serialized. Then can be feed to either a build step or a bootstrap that can load create the app dynamically.
Each type of thing that can be edited has its own dedicated UX.
Not much built yet but I'd be curious if anyone else has similar ideas / solutions.
[deleted]
read your comment right after I posted mine suggesting something like this wrapping the CLI.
There's a similar (in concept) idea in React Boilerplate
http://www.reactboilerplate.com/
There's several projects like this. Its an opinionated React startup kit utilizing Redux, React Router and Redux-Sagas. With generators, a server etc.
Because React doesn't provide the whole framework there's a bunch of these to get you started so the space is more complex to navigate then something like Ember.
http://www.reactboilerplate.com/
There's several projects like this. Its an opinionated React startup kit utilizing Redux, React Router and Redux-Sagas. With generators, a server etc.
Because React doesn't provide the whole framework there's a bunch of these to get you started so the space is more complex to navigate then something like Ember.
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".
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".
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.
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.
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.
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.
I think the problem is that React is developed as more of a Node/JavaScript project than as a web project. You see this in stuff like depending on `process`, a thing that exists in Node but not on the Web. So the Web is a compilation target; not the platform that React is developed for.
From there it's easy to think about everything in terms of JavaScript, and not making the Web the intended target for usage.
From there it's easy to think about everything in terms of JavaScript, and not making the Web the intended target for usage.
Yeah, along these lines, I also hate how most of the examples/tutorials online assume your server is Node.js. I'd love to find some official documentation on the best ways to use it with Asp.net and Rails, for example.
That's usually because those tutorials are also setting up sever side rendering. Node.js is only needed for that and for running the various (optional) build tools.
When doing a SPA I often set up Node.js to serve the index and provide server-side rendering and then never touch it again. Any actual API/WebSockets/RPC interfaces the app needs can be serviced by any plain old Ruby, Python, PHP, etc app backend. Since I usually use PHP from old habits, I use a Symfony API-only application.
I posted about this in a top level comment, but don't forget React can control any element in your DOM and not just the entire body like most SPA's are setup. You can continue using whatever languages/frameworks templating and view systems and augment views as needed that would be better handled by React.
When doing a SPA I often set up Node.js to serve the index and provide server-side rendering and then never touch it again. Any actual API/WebSockets/RPC interfaces the app needs can be serviced by any plain old Ruby, Python, PHP, etc app backend. Since I usually use PHP from old habits, I use a Symfony API-only application.
I posted about this in a top level comment, but don't forget React can control any element in your DOM and not just the entire body like most SPA's are setup. You can continue using whatever languages/frameworks templating and view systems and augment views as needed that would be better handled by React.
Oh no, I love (most of) ES6 and enjoy it when something shows green on caniuse. But I dropped Babel/Webpack from my build and (personally) determined that not needing to deal with configuration, deprecation, etc. messages in my terminal was worth the +0.005s to initial render and using <script> tags in my index.html file.
That being said, I'll likely give this a spin tonight for somerandomcrappyidea.js and provide you guys some feedback. Unfortunately, my work at Google has me more focused on Angular so I don't have as much time as I'd like to work on React applications. =<
As an aside, thanks for the work you've done on Redux and the talk that you gave at Hack Reactor!
That being said, I'll likely give this a spin tonight for somerandomcrappyidea.js and provide you guys some feedback. Unfortunately, my work at Google has me more focused on Angular so I don't have as much time as I'd like to work on React applications. =<
As an aside, thanks for the work you've done on Redux and the talk that you gave at Hack Reactor!
Are you still using JSX? Even a very minimal babel/webpack setup like this one has really sped up my productivity, but I'm interested in the alternatives...
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.
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.
Yeah, this is basically what kills it for me. When I was unemployed and just building random apps for fun it was great that there was a lot of ongoing progress and evolution in the React community. But when I came back a few months later to show off an app the npm install process let me know everything was deprecated - a bit vexing to consider how much work would be required to keep my shitty side projects up-to-date - not even considering actually building new features into them.
I did the same thing and found it quite nice too. I tinkered a lot with React and while the reactive features are nice, its such a pain to do anything in React because of the millions of steps you have to go through just to do something basic. I've tried it, tried Redux, done server side rendering, etc. For now I'm just gonna use Django and the built in Django template system while waiting for the React community to mature. Right now everything in the React ecosystem just too hacky. There's too many different API's for different stuff you have to learn to get something good going on.
Don't even get me started on Redux Form :-)
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.
Kudos to React team for bringing a superior pattern and making it actually practical to use.
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.
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".
Ditto for Redux. They're both low-level building blocks that could benefit from some official "opinions".
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.
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-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.
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-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.
Babel doesn’t get it wrong, it just wants to be a lower level tool. You can (and should) build on top IMO.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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#conver...) allows someone to move from the default configuration to their own when they feel comfortable.
Furthermore, the Eject feature (https://github.com/facebookincubator/create-react-app#conver...) allows someone to move from the default configuration to their own when they feel comfortable.
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.
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.
We’ll add testing, just need to make some decisions: https://github.com/facebookincubator/create-react-app/issues...
Under the hood this is Webpack + Babel + ESLint with sane initial configuration.
Love it.
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.
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.
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.
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.
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.
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.
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".
However, it would be nice to be able to tweak some of the configurations (Babel, ESLint, Webpack) without completely "ejecting".
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.
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.
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?
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.
We think in the beginning many will "eject" but we will gradually make the defaults better to cover more and more use cases.
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)
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)
My team has wasted so much time configuring webpack. This is a big win for React IMO.
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.
IMO it's the worst choice Facebook could have made for this toolkit, as it breeds some awful habits.
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).
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...
But they very fact you had to spend time abstracting away WebPack speaks volumes IMO...
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.
>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.
As I think I said on Twitter - it's not really that I think something solves the same problems better; it's that one tool shouldn't be solving all those problems (and in fact many of those problems aren't in the JS space at all).
Sort of... think UNIX philosophy vs... I dunno, Windows I guess? With the way it currently does it you are always going to have a horrible public API because the approach is fundamentally flawed.
And that's before I even get into how it solves those problems.
Now is it a bad thing it exists? No, obviously not. I'm glad it does, but we can learn what not to do from it as well.
Sort of... think UNIX philosophy vs... I dunno, Windows I guess? With the way it currently does it you are always going to have a horrible public API because the approach is fundamentally flawed.
And that's before I even get into how it solves those problems.
Now is it a bad thing it exists? No, obviously not. I'm glad it does, but we can learn what not to do from it as well.
Who are you? Why do you think you can speak with such authority?
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?
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?
Could you give me some detail on these "awful habits" you mention? As a webpack user, I'm genuinely curious.
Pretty much all the same reasons people railed against Grunt.
It's config heavy for very little benefit.
It's config heavy for very little benefit.
The only practical reason I can think of for people railing against grunt is that it used the file system for in-between steps and was thus frustratingly slow (a problem that webpack doesn't have).
Code vs config is a huge bikeshed
Code vs config is a huge bikeshed
> Code vs config is a huge bikeshed
Not really. Historically it's been an indication of the quality of a system.
Not really. Historically it's been an indication of the quality of a system.
Sorry, this is not true.
I actually use browserify for personal projects. It's ultra simple to get started. My boss insists on using webpack.
If you don't care about the stupid arbitrary bundling system for other assets (like CSS and images) that WebPack has (and you shouldn't: it's an awful code practice) then yes... Browserify is literally better in every way (other than tree shaking)
>If you don't care about the stupid arbitrary bundling system for other assets (like CSS and images) that WebPack has (and you shouldn't: it's an awful code practice)
The “stupid arbitrary” system has a number of benefits. It revs your assets for production automatically with content hashes. It saves you from filename typos because all assets (CSS, images) are part of the same build pipeline. It throws on parse errors in CSS as part of your normal dev flow, not at some later stage. It allows for fast hot reloading of styles in development.
The only downside I’m aware of is that it doesn’t work with some other tools without special plugins or configuration. Well, you have to pick your tradeoffs, right? I’d love to talk about technical tradeoffs of both systems but your comment reads more like a knee-jerk reaction than a technical assessment.
The “stupid arbitrary” system has a number of benefits. It revs your assets for production automatically with content hashes. It saves you from filename typos because all assets (CSS, images) are part of the same build pipeline. It throws on parse errors in CSS as part of your normal dev flow, not at some later stage. It allows for fast hot reloading of styles in development.
The only downside I’m aware of is that it doesn’t work with some other tools without special plugins or configuration. Well, you have to pick your tradeoffs, right? I’d love to talk about technical tradeoffs of both systems but your comment reads more like a knee-jerk reaction than a technical assessment.
> The “stupid arbitrary” system has a number of benefits.
Yes, it does. Those features aren't exclusive to webpack though (they're really, really, really old features of webdev) and can be replaced by much less silly systems.
I mean literally everything you just listed is better handled by more mature, developed, tools.
Yes, it does. Those features aren't exclusive to webpack though (they're really, really, really old features of webdev) and can be replaced by much less silly systems.
I mean literally everything you just listed is better handled by more mature, developed, tools.
+1 for team browserify. It's sad that it appears to be way less popular. Webpack is too much of a magical black box for my tastes.
Really? I find Webpack to be an order of magnitude easier to explain and understand when compared to Grunt.
Yes, but that's not saying much is it?
I'm sucker for self descriptive "boring" names like "create-react-app"
Also, sweet project!!
Also, sweet project!!
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.
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.
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
The npm-version sits in a feature branch, just look for the corresponding PR if you're keen.
The npm-version sits in a feature branch, just look for the corresponding PR if you're keen.
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
Hope anyone reading this finds it useful :)
https://github.com/stoikerty/dev-toolkit
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.
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!
PS. Already in /src/App.js , and wow live reloading without gulp or browersync , it is so simple to get started! Thank you!
I thought the live reloading was just for CSS?
Yep. For components we refresh the page now. (Automatically still.)
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/
b) Is Facebook planning to maintain and keep this generator current? Why don't they just contribute/recommend an existing generator
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/
b) Is Facebook planning to maintain and keep this generator current? Why don't they just contribute/recommend an existing generator
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.
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.
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.
[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.
It doesn't even support hot reloading. No config means they can make assumptions about how things work which makes it really to share solutions for things like "optimize this for prod" or other use cases that are typically a lot of work for your custom setup.
However, I predict that there will be a softer escape hatch than "eject". At least a single option to take the webpack and config and whatever you want with it, at your own peril. This would be completely unnecessary unless you really Know What You're Doing.
However, I predict that there will be a softer escape hatch than "eject". At least a single option to take the webpack and config and whatever you want with it, at your own peril. This would be completely unnecessary unless you really Know What You're Doing.
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.
> “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.
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).
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).
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.
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.
I just published a similar tool:
> npm install -g react-app-tools
> react-app new
> react-app start
{
"private": true,
"dependencies": {
"react-app": "^1.0.0",
},
"devDependencies": {
"react-app-tools": "^1.0.0",
},
"scripts": {
"build": "react-app build",
"start": "react-app start",
}
}The important thing is that new users need a zero configuration way in to the technology.
Once you have done some coding, found your feet and stepped up a few levels of comfort and understanding, then sure thing, start venturing out into the world of configuration via "eject".
I think it's a good thing that it is pure zero configuration. If you want to configure then you have graduated.
Once you have done some coding, found your feet and stepped up a few levels of comfort and understanding, then sure thing, start venturing out into the world of configuration via "eject".
I think it's a good thing that it is pure zero configuration. If you want to configure then you have graduated.
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
[1]: https://twitter.com/dan_abramov/status/752863664290553856
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.
Finally something that may convince me to switch from https://github.com/thardy/generator-ngbp - all I want is to focus on writing components not figuring out how to link gazillion dependencies
The day we now see "compiled successfully" in the Command Line as the necessary "easy" starting point for frontend web devs.
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.
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.
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.
>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.)
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.)
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!
But nevermind me, React is a great tool, and this is a very nice and needed project!
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.
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.
Exactly.
We don't like classes, but we don't like "pseudo classes" (createClass) even more. Better the devil that's standardized.
We already offer a way to create stateless components with just functions. We will keep exploring that space and eventually might have a class-less solution we like that satisfies all our use cases.
We don't like classes, but we don't like "pseudo classes" (createClass) even more. Better the devil that's standardized.
We already offer a way to create stateless components with just functions. We will keep exploring that space and eventually might have a class-less solution we like that satisfies all our use cases.
One thing though, is that the standard classes are just not up to the job without a lot of stuff tacked on. Eg: the function binding problem pushes people to use class properties, which aren't yet a standard, and then they hit walls with tools that don't support them (eg: I dunno if it's still the case, but for a while class properties caused issues with Flow).
createClass might not have been the answer, but on top of stateless component functions, things like the good old ES3 module syntax honestly would be more flexible/powerful (giving you a closure to do things like private members, etc)
Instead we have people using babel with all sorts of plugins, tacking on 3rd party decorators and utilities, and a bunch of other cruft just to mimic features JavaScript have had from the beginning. And then (talking out of my rear here), it possibly put pressure on the TC39 to waste time discussing features we seriously don't need.
createClass might not have been the answer, but on top of stateless component functions, things like the good old ES3 module syntax honestly would be more flexible/powerful (giving you a closure to do things like private members, etc)
Instead we have people using babel with all sorts of plugins, tacking on 3rd party decorators and utilities, and a bunch of other cruft just to mimic features JavaScript have had from the beginning. And then (talking out of my rear here), it possibly put pressure on the TC39 to waste time discussing features we seriously don't need.
There was not such thing like ES3 module syntax. This is just programming pattern many people used: https://addyosmani.com/resources/essentialjsdesignpatterns/b...
It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically.
These are very powerful features of language, but they're dynamic, which is unfortunate because to know what exactly is happening in this code you have to run it. for IDEs/editors it's hard to look at your code and guess "well, it's module pattern, I see! You mean this and that". Tooling operates usually on static analysis of syntax. They use JS parsers to parse code to AST(Abstract Syntax Tree).
And here's the thing: ES6 classes are visible in AST, there is something called ClassDeclaration. This means that every programmer can install some ES6 parser from NPM and analyse ES6 classes. This means that there will be better linting, better autocompletion etc.
On the other hand - JavaScript parsers don't understand module pattern or other homegrown idioms. It's harder to analyse them statically. Especially if they rely on dynamic aspects on language. ES6 parser doesn't run your code. That's why ES6 classes, because they're static, are better for parsers, and consequently, enable better tooling, IDE support, autocomplete etc.
Situation maybe were a little bit different if we had tooling for some sort of dynamic analysis (if tools were running code in sandbox and gathered data in runtime, not from syntax etc.).
But because currently most of tooling is syntax based I think ES6 classes (and e.g. ES6 modules) are just better for analysis.
Well... to contradict what I said early I must say that actually it's often possible to analyse such things like module pattern, createClass etc. But:
1. not always with 100% certainty of the result
2. there are too many idioms. If every framework, every team and every programmer has own way of writing JS, own module syntax, own class syntax etc. it's very hard to support all the frameworks and provide tooling for all people...
It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically.
These are very powerful features of language, but they're dynamic, which is unfortunate because to know what exactly is happening in this code you have to run it. for IDEs/editors it's hard to look at your code and guess "well, it's module pattern, I see! You mean this and that". Tooling operates usually on static analysis of syntax. They use JS parsers to parse code to AST(Abstract Syntax Tree).
And here's the thing: ES6 classes are visible in AST, there is something called ClassDeclaration. This means that every programmer can install some ES6 parser from NPM and analyse ES6 classes. This means that there will be better linting, better autocompletion etc.
On the other hand - JavaScript parsers don't understand module pattern or other homegrown idioms. It's harder to analyse them statically. Especially if they rely on dynamic aspects on language. ES6 parser doesn't run your code. That's why ES6 classes, because they're static, are better for parsers, and consequently, enable better tooling, IDE support, autocomplete etc.
Situation maybe were a little bit different if we had tooling for some sort of dynamic analysis (if tools were running code in sandbox and gathered data in runtime, not from syntax etc.).
But because currently most of tooling is syntax based I think ES6 classes (and e.g. ES6 modules) are just better for analysis.
Well... to contradict what I said early I must say that actually it's often possible to analyse such things like module pattern, createClass etc. But:
1. not always with 100% certainty of the result
2. there are too many idioms. If every framework, every team and every programmer has own way of writing JS, own module syntax, own class syntax etc. it's very hard to support all the frameworks and provide tooling for all people...
Classes don't do anything about the dynamic nature of JavaScript. They spit out basically the same constructor that everybody was using for pseudo-classes in ES5. You can still do crazy things like manipulate the prototype outside the class, tack extra stuff onto instances after they've been instantiated and so on...
In other words, classes in JavaScript are a poor substitute for static types, and should not be used that way. That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.
In other words, classes in JavaScript are a poor substitute for static types, and should not be used that way. That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.
Yeah. You're right that even classes allow for great amount of dynamics. I've seen classes with decorator annotation and decorator can change classes as much as it wants. I've also seen patterns like:
class Foo {... }
// then, after class definition
Foo.A = X;
Foo.B = Y;
etc.
So... it seems that every try to make JS more static is doomed to fail... Because people will still use it in dynamic way...
Not sure how to solve this problem. Maybe we really need tooling that would run code in sandbox instead of analysing it via AST (but how to sandbox e.g. NodeJS code that interacts with file system or MongoDB? Mocking everything? Or make complete dev environments/virtual machines with NodeJS code running in it?)
(Maybe I overengineer solution ideas in my head, but I think proper tooling support is important for modern web development. It hurts me when I have to learn new large JS codebase and IDE is not helping)
> That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.
I don't like the idea of defining types for everything but maybe it's the solution (I'm not sure because I have too little experience with TypeScript to judge).
class Foo {... }
// then, after class definition
Foo.A = X;
Foo.B = Y;
etc.
So... it seems that every try to make JS more static is doomed to fail... Because people will still use it in dynamic way...
Not sure how to solve this problem. Maybe we really need tooling that would run code in sandbox instead of analysing it via AST (but how to sandbox e.g. NodeJS code that interacts with file system or MongoDB? Mocking everything? Or make complete dev environments/virtual machines with NodeJS code running in it?)
(Maybe I overengineer solution ideas in my head, but I think proper tooling support is important for modern web development. It hurts me when I have to learn new large JS codebase and IDE is not helping)
> That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.
I don't like the idea of defining types for everything but maybe it's the solution (I'm not sure because I have too little experience with TypeScript to judge).
It's not syntax, I know. It's just how it's referred to in the doc and was faster to type. Read between the lines.
I'm all for better solutions for functional components. I hope we go down that road instead of locking in the decision to rely on `class` with things like class decorators and so on.
Several React libraries are already doing that. In spite of all our warnings, people are trying to extend classes for React views, and use `class` in the rest of their code, as well, moving it into the state layer, and modeling their business domains with them instead of using pure functions and Redux.
`class` affords `extends` like balls afford throwing and chairs afford sitting. When you ignore the power of suggestion that comes with the tool affordances, you point users in the direction of trouble.
Sadly, scaling developer education is a lot harder than it seems from inside our ivory towers, surrounded by smart colleagues well-versed in programming wisdom and design patterns.
Several React libraries are already doing that. In spite of all our warnings, people are trying to extend classes for React views, and use `class` in the rest of their code, as well, moving it into the state layer, and modeling their business domains with them instead of using pure functions and Redux.
`class` affords `extends` like balls afford throwing and chairs afford sitting. When you ignore the power of suggestion that comes with the tool affordances, you point users in the direction of trouble.
Sadly, scaling developer education is a lot harder than it seems from inside our ivory towers, surrounded by smart colleagues well-versed in programming wisdom and design patterns.
It does not need a class, it just need to be able to keep track of some kind of references. There's a million functional ways to do this without needing class.
React really should have gone from createClass to <insert better design pattern that doesn't rely on the class keyword here>. It already supports the module pattern. They easily could have expanded on that.
React really should have gone from createClass to <insert better design pattern that doesn't rely on the class keyword here>. It already supports the module pattern. They easily could have expanded on that.
Syntactic sugar? But `createClass` is a lot worse syntactic sugar than ES6 classes.
React.createClass (and angular.directive or similar guerilla solutions) are harder to analyse statically. And without static analysis you won't have proper tooling (IDE autocompletion, "go to definition" feature, dependency graphs, linting etc.).
So. Welcome language standards or goodbye static analysis. I'm seriously happy that both React and Angular go into ES6 classes and resign from guerilla coding...
React.createClass (and angular.directive or similar guerilla solutions) are harder to analyse statically. And without static analysis you won't have proper tooling (IDE autocompletion, "go to definition" feature, dependency graphs, linting etc.).
So. Welcome language standards or goodbye static analysis. I'm seriously happy that both React and Angular go into ES6 classes and resign from guerilla coding...
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.
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.
it seems like a solution to the Vjeux's challenge: http://blog.vjeux.com/2015/javascript/challenge-best-javascr...
(If we don't count sharable requirement).
(If we don't count sharable requirement).
Integration with now.sh ( https://zeit.co/now/ ) and uploading to gh-pages is something that was cut for the release but we are thinking about doing :)
[deleted]
> 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.
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.
and its easily swappable: https://github.com/switchfly/ember-cli-mocha (and fully integrates with the existing test harness, regardless of the test framework you choose.)
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.
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.
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.
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.
> In the JavaScript world, configuration and pain are synonyms.
This is outright false. There is some relation, but not all configuration results in pain.
This is outright false. There is some relation, but not all configuration results in pain.
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.
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.
If it's wrong, it's not good enough.
I don't disagree that configuration is awful, especially if it isn't well thought out, but some configuration is unavoidable & even preferable in some situations (for example when dealing with differences between production, qa, and dev environments). Dismissing configuration wholesale though is laziness. All things should be considered carefully, and blanket statements serve little good.
I don't disagree that configuration is awful, especially if it isn't well thought out, but some configuration is unavoidable & even preferable in some situations (for example when dealing with differences between production, qa, and dev environments). Dismissing configuration wholesale though is laziness. All things should be considered carefully, and blanket statements serve little good.
I created something similar a month ago
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.
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.
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"
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"
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.
Could there be some sort of npm feature that incorporates a remote list of dependencies & versions?
Yep, it’s called a “package”.
;-)
So could whatever create-react-app is delivering be substantially approximated with an npm-based solution?
create-react-app is an npm-based solution.
> Couldn't they just offer a "facebook-certified" starter pack/bootstrap?
No, because Facebook engineers don't use or need that. Facebook only open sources or releases stuff they use—except for this. This is actually the first and probably only open source project from Facebook that they don't use in production.
No, because Facebook engineers don't use or need that. Facebook only open sources or releases stuff they use—except for this. This is actually the first and probably only open source project from Facebook that they don't use in production.
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
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
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.
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.
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.
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.
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
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
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.
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.
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.
Is it me, but is not Angular just taking over? Kind of Google vs Facebook thing. Just think Google won this one.
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.
Covered on TechCrunch https://techcrunch.com/2016/07/22/facebooks-new-open-source-...
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. :)
We won’t add runtime dependencies besides React for now. We are focused on solving build tooling first.
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
What an odd and arbitrary list. SASS support over LESS over PostCSS over CSS in JS? Component boilerplate generation is required for production? Hot module replacement is required for production? Everyone using React is looking for an isomorphic solution? Docker support?!
I think the point of the project is to acknowledge that React requiring transpilation to use is 100% accurate and there needed to be a transpilation / workflow solution to make it easier to adopt. It wasn't let me solve every single problem for you, including setting up your production deployment environment using Docker.
I think the point of the project is to acknowledge that React requiring transpilation to use is 100% accurate and there needed to be a transpilation / workflow solution to make it easier to adopt. It wasn't let me solve every single problem for you, including setting up your production deployment environment using Docker.
> SASS support over LESS over PostCSS over CSS in JS?
Well yes, because any CSS in JS solution (in PostCSS) is just plain bad for a myriad of reasons.
That would leave you with SASS vs LESS and SASS is massively more popular and supported.
Well yes, because any CSS in JS solution (in PostCSS) is just plain bad for a myriad of reasons.
That would leave you with SASS vs LESS and SASS is massively more popular and supported.
I think parent was suggesting inline styles
Dockerization, are you crazy? This is just a simple boilerplate. If you want something absurdly complicated (and frustrating to work with imo), use something like Este https://github.com/este/este
It's goal is to be for a front-end SPA. None of that is needed for it's stated goals.
Also - HMR, generators, dockerization, sass, & test environments are not needed for many/most projects initially. When they ARE needed you'll be beyond the point you need this kit anyhow.
Also - HMR, generators, dockerization, sass, & test environments are not needed for many/most projects initially. When they ARE needed you'll be beyond the point you need this kit anyhow.
And it doesn't even write your app for you, how dare they!
My point wasn't to belittle the work, they did a great job, it was just pointing out how far you can go with something like this. This just doesn't have as many of the things people need as other similar projects do.
It seems like they were shooting for the MVP here, not trying to make it the kitchen sink. Not everyone wants dockerization, Sass, isomorphic rendering, etc.
None of that is needed for a real world production frontend app, with the exception of maybe tests.
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
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
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.
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?
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?
You just perfectly described the problem with Front End Engineering that this tries to tackle.
I guess what I was trying to bring up, is that this has already been solved by a bunch of people already, but with a lot more features. We use Gluestick, but others use stuff like https://github.com/mxstbr/react-boilerplate
For CLI generation utilities, I haven't found anything that comes close to this guy:
http://fountainjs.io/
http://fountainjs.io/
Expectation:
- "Hey, look, this can SOLVE ALL THE PROBLEMS"
Reality: - "Hey, look, this actually BRINGS IN A WHOLE LOT OF OTHER PROBLEMS too!"
:sad:
Reality: - "Hey, look, this actually BRINGS IN A WHOLE LOT OF OTHER PROBLEMS too!"
:sad:
We’d love to hear about the problems.
https://github.com/facebookincubator/create-react-app/issues...
Would you mind explaining which new problems this creates?
WebPack for one. Using webpack brings in way more problems than it solves.
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.
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...
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...
[deleted]
This is really neat. especially the fact that I can 'eject' at any time when I need more power. Love it!
wanted to share http://github.com/uptownhr/kube. I also wanted to tackle this problem but also handling SSR as well.
but handles SSR as well.
Having a consistent API with ember-cli will make this more useful.
$ react-cli <>
$ react-cli <>
Only for those used to ember-cli. For the huge majority this is irrelevant.
It provides a consistent mental model across frameworks for building front-end applications via CLI.
This would make people expect us to implement everything it does. We currently don't plan to.
How would it become more useful / what is more useful about it, and for who?
[deleted]
Just wanted to know, am I the only person who is unhappy with react ?
This is not a react problem, this is a nodejs problem.
What the heck is that terminal font?
Operator Mono
Other than a nasty eyesore? Good question..
http://i.imgur.com/2suYgKq.png
http://i.imgur.com/FnLVfw6.png
http://i.imgur.com/2suYgKq.png
http://i.imgur.com/FnLVfw6.png
Thanks so much for asking, I was wondering the same thing.
[deleted]
Amazing.
Looks cool
Thanks !!!
[deleted]
In the spirit of zero configuration, it would be nice if it included Standard JS
https://github.com/feross/standard
Please no! One person's "standard" is another person's "Please no!".
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:
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/
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
React/Redux resource links: https://github.com/markerikson/react-redux-links