I wonder where the happy medium is. Setting up React/Redux/React-redux/react-router/react-redux-router/react-redux-router-thunk/webpack-hot-module-oh-my-god-what-am-i-doing takes forever.
Honestly, the fact that people put up with this in Js ecosystem amazes me to no end. I've been working with ClojureScript on the front-end for the past year, and it's just night and day.
There's a single build tool (http://leiningen.org/), and it manages dependencies, tests, builds, etc. Things just work.
Setting up a new project is as simple as:
lein new reagent-frontend myapp
I can go and start developing it by running
lein figwheel
After it starts I can open the browser at localhost:3449 and any changes I make in the source will be immediately reflected. Once I want to package for release I just do:
lein clean
lein release
That's it, I now have minified and pruned Js file that's ready for production.
It's really much more than that. There's an ecosystem around ClojureScript that's completely separate from Js, and I find the CLJS ecosystem to be far better in many respects.
You don't need all of that from scratch. You can just build React components, and when it comes time to add a store or a router the only thing you need to change are the glue components that bind things together. I think it works out nicely -- the dev process is as composable as the app itself.
Yea I've noticed that. The react community likes to focus on examples involving a sign up form with 3 fields where you "really don't need all of that". Except that is not what most of us SPA devs are building. We need most of that.
My argument is that it's a net benefit. Composable architectures are not boilerplate. Remember that there was a time when almost all React apps where written with Flux -- this model is what allowed Redux gain traction.
You don't need to use all of that just because it's there and having it there is more reliable than having to cobble together your own, at least in a corporate setting.
I actually find it surprising that this is a Google project, if you just gave me the code/docs and didn't tell me what project it is I would have guessed this came from Microsoft (feels much more WPF/Silverlight like than GWT/Closure, hell it even uses Rx which came out of MS)
Just a note, that 20kb also includes the dependencies, such as the reflect metadata polyfill, zone.js polyfill, and an ES6 shim such as core.js. Once static template compilation lands (think of it like the JSX compiler), it will get even smaller.
Angular 2 is shaping up to be a framework like no other out there in its capabilities.
20kb? Really? On last week I built NG2 application(rc.4) with one component and size was over 500kb, with all dependencies which needed to run it. Maybe @angular/core weight 20kb, but in order to run real world application need add many dependencies. rxjs, zoom.js, shims, and so on..
We have 75-100 components along with all the angular pieces, polyfills, and ngrx/rxjs. It's 250kb with a minimal build process. I haven't even started digging into any optimization/build tools. I think you're doing something wrong.
I heard they are going to reduce final app size by doing smart analyzing of used features and getting not used stuff out of the final build. But I might be wrong.
Even if you don't need it for a one app you might get a need for the another app and it's fine that all that stuff is coming as an entire framework from the one team, which means that all listed features will work smoothly being put in a single app. So no need to find and integrate scattered over the interned 3-rd party libraries. I agree that Angular is more for the large (you can say enterprise) projects.
Edit: I used NG1 a lot and liked it. But after trying NG2 I felt it to be really too complex for small to medium projects. Vue.js is what I hoped NG2 to become.
I was just wondering what the author had in mind. But now that you ask, yes I think it does. Without a suggestion the opinion is pretty much worthless.
You really think we shouldn't criticize things if better alternatives don't currently exist? The fact that someone hasn't come up with a better approach doesn't imply that the status quo is the best possible solution.
ie for any mildly complex app, [re]implement a framework rather than using an existing framework that is battle-tested to a far higher degree than is possible if you roll it yourself?