91–100 of 250 posts
However, it would be nice to be able to tweak some of the configurations (Babel, ESLint, Webpack) without completely "ejecting".
Earlier quoted context omitted.
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!
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.
> 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 rig…
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 wi…
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.
This is great since it provides an OFFICIAL opinionated set of tools for building React apps which is typically the largest barrier of entry for new developers looking to experiment with this technology. However, it is missing a lot of core features that typically come standard with Webpack/React boilerplates. Directly from their Github: Some features are currently not supported: Server rendering. Testing. Some exper…
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?
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 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".
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 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.
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.
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.
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?
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.
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.
Earlier quoted context omitted.
Would you mind explaining which new problems this creates?
WebPack for one. Using webpack brings in way more problems than it solves.
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...