The first and obvious benefit is being able to quickly create new projects without having to think about build infrastructure, which is honestly the most painful part of building a modern React project. create-react-app makes all the hard choices for you and gives you a reasonable set of defaults to work with. It's convention over configuration, kind of like Rails. It's a huge game changer.
The less obvious benefit is that it forces developers to fall into the pit of success by making it easy to do the right thing. Flow is supported out of the box, so adding type checking to your app is trivial. Jest is set up for you out of the box, so you have no excuse to not add tests. This new version includes support for code splitting, so there's no reason to ship bloated JS bundles to your users. Building a PWA is easy, so you start thinking about offline-first right at the start of your project.
I can't thank the team behind this little tool enough for making it so easy and so much fun to build React applications!
At some point you will need to make changes — be it to switch to typescript, to add some other cross-compilation tools or modify the build pipeline — an you'll have to fight with the build system.
If create-react-app did not exist, maybe the daily pain of working with the build system would be enough that it would actually be improved.
Because currently, maven is even nicer to work with than the various js build systems.
But it's been well over a decade. Maven is maven, npm is npm, make is make. Yarn is doing a good job now of being the new and improved build system for JS projects, and create-react-app seems to be using it under the hood.
Eventually I may care about what compilation flags lein passes to maven in order for it to compile my clojure project into jvm bytecode, but that day hasn't happened yet and I've been glad not to have to set those up with every clojure project I start. The same now applies to react apps.
That’s the issue I have with npm, webpack, create-react-app.
They just pile more and more layers of abstraction on top, instead of improving or replacing what is below.
I don't remember when this started - Rails maybe? That was not my thing back then, but I really like this now.
IIRC Elixir has a great tool as well.
Quick question, does it include an option for client side routing?
I really want to start using React, but every time I get overwhelmed by the sheer amount of options (paralysis analysis) and go back to AngularJS (which is starting to show it's age). Personally I'm not sold on Angular2/4.
Can confirm, I absolutely love `redux-little-router`. It feels so natural to dispatch Redux actions to change routes rather than dealing with the song and dance of conditionally rendering <Redirect /> components or trying to figure out when in the lifecycle to call `router.push(url)`.
I especially like pairing it with `redux-saga`- with a little bit of effort, you can end up writing mini-applications for each route which start and stop as the user navigates.
This feature really puts React on the next level, in my book. The CRA team is doing a wonderful job making React accessible to new users.
Direct link: https://github.com/Microsoft/TypeScript-React-Starter
Here's the package that adds the TS functionality to create-react-app FYI: https://github.com/wmonk/create-react-app-typescript
No, because TypeScript is a transpiler and Flow is a linter. You don't have to convert your codebase with Flow -- you can just run it on existing JS.
You can use TS on a JS codebase as well (with the --allowJs option), or you can leave JS files to a separate build step if you don't want type inference for them. I have used both approaches in the past.
This is absolutely untrue. Have you used Flow? It runs as a completely separate process -- you're literally running Flow as a command which typechecks/lints your code. It does not do any transpilation or modify your code in any way. The only caveat is the Flow type annotations which are A. optional and B. removed at compile time without doing any typechecking. Try it some time -- you can run Flow on existing JS code without modifying either your code or your build process in any way. It'll probably even find some bugs without you needing to add additional type information. This is fundamentally different from Typescript which goes hand-in-hand with a fully-featured transpiler.
To be clear, I use TypeScript and like it a lot -- but there seems to be a persistent perception that Flow and TS are two sides of the same coin. They are not and there are certainly some use cases where Flow fits better.
I think we're saying the same thing. By "linter" I mean a program that only checks for stylistic and defined/undefined errors. To me, anything beyond that is a typechecker. Whereas TS bundles a typechecker with a transpiler, Flow keeps the 2 separate (you still need both if your program is written using Flow syntax).
You are using "linter" more broadly, which may be fair as well.
Additionally, both TS and Flow can be used on JS files with zero modification.
They are supporting flow but not TS.
Maybe writing "push" was a bit of an over statement from my side but for how well typescript plays with react and JSX and how much more popular it is compared to flow it should be either supported by them or flow shouldn't be. Currently they are discriminating in favor of flow. Which I mean they have 100% the right to do, its their product but as an end user I simply want to express my desire in that feature being first class.
They should support a niche third party competitor tool on their freely available and FOSS tooling?
wrong. typescript is vastly more popular than flow.
hey if they got that thinking, its fine. its their product but from my user perspective I just want to let them know that I could really use some first class TS support.
Irrelevant, as both are still niche.
- TypeScript: 4,745,783 downloads in the last month
- Flow: 889,612 downloads in the last month
Naming that setup after a Greek monster seems apropos.
Here is an explanation:
Not saying these things are deal breakers at all, create-react-app is really great. Just making sure I've got my pros and cons list correct! Thanks for any help
The 'React Hot Loader'  module, which maintains local React component state is not included yet.
Usually, you'd want to do this if you want do implement one of the "limitations" cited or if you had specific things to configure that had been abstracted away.
For example, the release notes mention webpack 2 changed their configuration. If you hadn't ejected yet there's nothing to do because they took care of it on the back end, if you had ejected you have to update your webpack config.
In my experience, setting it all up and getting dependencies is one of the pain points with react, so it's nice to get some sane defaults and get to writing your app. But it is nice to take the time to do everything manually at least once to see what's under the hood.
That said, offline-friendly app caching with Service Workers is extremely useful, and changed the way I see and make web apps.
Now when I use a web app that isn't offline-friendly, I get annoyed. Always demanding a live internet connection obviously creates latency and unreliability for apps.
I changed a former client's app to be offline-friendly with Service Workers, and the benefit was obvious: their app now loaded immediately for repeat users, and they could access much of their data even when they were offline (on a flight, on a crappy Wi-Fi, etc etc).
I made a side-project to help my band members share and edit chord/lyrics sheets (also using Web Audio to give karaoke-style chord playback!) and again I made sure to set up full Service Worker caching. I also used PouchDB for the user data, which was beautiful: I didn't need to run any database server (we just used Cloudant's free instances), all our songs were synced into local browser storage (in real-time when online), and most importantly, the whole app worked perfectly while in the basement rehearsal space that completely blocks mobile signals.
(I'm not working on it nowadays. It's up on https://sketch.band and the code is at https://github.com/mbrock/sketchband under AGPL3. If you wanna try it, the undocumented syntax for the song is: each line should look like "C Dm7 / Once upon a time you dressed so fine".)
Basically offline-first technologies really help make the web into a good platform for apps.
In dashboard application, I store data in browser and notify users about last sync time: http://wstaw.org/m/2017/05/19/dashboard.livechatinc.com-iPho...
Tons of web apps that work in offline mode, which we had since a decade or so -- from games to utility apps.
>It seems like the utility is really niche
For an e-commerce website, this might be the user's shopping cart and favorites. For a note taking app, this might be the last note the user edited. For a Twitter client, this might be the user's drafts and the last 100 tweets on their timeline. This way, the app can say "you're offline, but you can still look at some of this data and do things with it, and we'll sync you up when you get back online".
Native apps already do this. E.g, try posting a picture to Instagram while you're offline.
Also, ServiceWorkers are not just useful on mobile! Applications targeting desktop browsers benefit from them just as much, especially if you're thinking offline-first.
This stuff costs so much time, use an IDE or some auto-import plugin for eslint.
If the thing that slows down my programming is writing import statements by hand, then I have worse QA issues than that.
Modularity is good and all, but explicitly declaring each single dependent component (external libraries and other internal components) when writing new components and adding new ones as you need more dependencies is quite painful and tedious.
Up to a point though -- "break[ing] down functions into tiny components" doesn't seem to be on the good side of modularity, but more like the lpad npm fiasco.
So, my reply to that comes down to:
If you have so many imports that it costs you "so much time" to handle them manually, then you probably have QA issues -- like people adding tons of dependencies to your project.
But it was also meant in the way that if you code so fast, that manually adding some imports is what slows you down ("takes so much time") then probably you are not thinking about what you code enough.
Typically, even without automated imports, the time to handle imports would/should be a negligible amount compared to the time to write the actual functionality -- that's the difficult part, and that what takes one time to think, design and code right.
Or having to manually write "import React from "react"" on top of every single new component.
Or having to write "import _ from lodash" whenever you need to access _ for some function.
It get's triggered on each save in TextMate, which I use.