However, there is a better way ... lein new figwheel my-app, clojurescript+reframe gives you all the benefits of redux with an order of magnitude less boilerplate (also hot reloading and immutability by default without no extra setup or ceremony)
Plus due to the google closure compiler code can be minified with an aggression unknown to the typical js minifiers.
Add to that tree-shaking (removing unused code) and the long term size of your app is looking good.
I find clojurescript and specifically figwheel reduces language annoyanes and tooling problems. No more do i have to jump through hoops to get a project setup, or pick the latest and greatest build tool (grunt->gulp->webpack->jspm)
There are several things to consider with download time:
- is this a website? why on earth do you need react or anything for a website?
- is this a single page web application? then to develop with a medium sized team and an increasing feature set its nice to pick a language and library/framework that enable that.
- do you really care about mobile users performance and bandwidth? then you need a native app
This is all unrelated to the article, which is merely an uninformed rant about someone who doesn't understand the point of immutability and its use within functional programming as opposed to shoe-horning it into imperative code.
You can add JIT too :) More JS, more time needed to reach decent runtime speed post JIT. React's first render is very slow.
If you're talking about a webpage then yes that would be awful.
It seems there's some minimum (think Greenspun) JavaScript necessary to have a working SPA that handles DOM manipulation, network communication, state management, module management, events, et cetera, somewhere between 50k and 100k. I would love to be proven wrong about this. Maybe as native ES6 (or WebAssembly) becomes the norm this will be less the case.
Choosing libraries shouldn't require careful examination of their output file size, especially if you only want half the functionality.
console.log("Hello world!")
I realize this is a silly example for such a powerful tool but I just wanted to quickly get a feel for what the compiler is capable of before I committed a whole lot of time to learning the language. All I got out of the exercise was that the compiler creates a much larger minimum package size than I'd hoped. I'd appreciate any suggestions on a better way of proving its value for the cautiously curious. The language itself seems great, as does the community.
Perhaps it's just a different paradigm from npm/webpack, e.g. utilizing a rich built-in library rather than, yeah, carefully grocery-shopping for only the components you need? I'm not saying one is necessarily better than the other but it does intuitively seem that choosy shopping will tend to yield a smaller package size, at least for small-to-medium applications.
I suggest watching this:
I've been working with React for years now, over several large projects. I still feel like I'm not used to it, and I still hate it. That's not normal.
We need to either figure out how to do this shit with mutable data structures, or we need a new language that's immutable by default.
ImmutableJS blows chunks. Yeah it "saves" code until you start doing the data transformation dance trying to figure out when and where to convert between plain JS objects and Immutable ones. Then you end up with some real ugly shit that'll trip up every new hire you walk through it (we use a higher order component that converts a component's Immutable props to regular objects, which incidentally is another import that like 800 unrelated files depend on...)
God help you if you don't use well commented code or Hungarian notation to differentiate between Immutable objects and regular ones. We all know how long good commenting practices last without thorough code reviews, and we all know how long those last in fast-moving environments, which is where React is most useful.
I guess a typed language would solve that. No, Flow and Typescript don't count.
fanfare, fireworks, etc
CLOJURESCRIPT!!
sorry I just get really excited when I can mention it ... I'll go now
We haven't been using immutability.js because of the back and forth overhead between regular JS and immutable objects. Instead we use mutation checking of the Redux store during development you can make sure nobody is stomping on it by accident.
That's one problem. The other is discipline. It's just way too easy to opt out of the type system. It shouldn't be a problem, but in the world of deadlines where every single front-end dev is intimately familiar with writing plain old Javascript, it is. All it takes is one manager that's a bit pushy, or one urgent production bug, and your codebase is on it's way to turning into a pile of shit.
I do love type systems, but IMO they have to be part of the language, it just doesn't work as an optional addon.