Flow is quite good, but over half of our React codebase is components connected to Redux or Redux Form and unfortunately there are no Flow types for the versions that we use, so type inference is very weak at some points.
Besides, Flow has a very ambitious target of delivering types for APIs which were not written with types in mind at all. I thought I'd be able to recreate some of the Elm's type safety with Flow, but that's just not possible and I doubt it'll ever be. But then again, these two projects have very different objectives.
>> When giving feedback, some people say that they are brutally honest
> As someone who prefers giving and receiving terse feedback... I would suggest that there's nothing wrong with brutal honesty for type of people who appreciate receiving it.
It seems to me that you cited the fragment of donw's comment about "brutally honest", but ineffective feedback ("The module you wrote is crap because your code sucks and is hard to maintain.") and then started arguing that some people like receiving terse feedback.
But won't you agree that the example of "brutally honest" feedback wasn't in any way terse and that "brutally honest" doesn't necessarily mean terse?
I find the second part of the "kind" feedback much more terse: "Breaking those big methods and classes into smaller separate objects and functions would help a lot".
I left a comment under your post on reddit. For us, JSPM is fast enough and we don't have to run a second server just to serve assets.
And, excuse me for saying that, but I found your post lacking in substance. Writing "It's super slow, we've tried everything" doesn't show us about what you've tried and with a detailed explanation maybe the thousands of eyeballs who saw that post would be able to help you find the problem you had. ;)
I think JSPM should stress the part about bundling. It's the second person that I see who says "JSPM is slow" and the reason behind this slowness is that they didn't bundle the files or bundled them incorrectly.
We do the same in our project: we bundle all the 3rd party libs when they change, so only our own code gets retranspiled on each page load. During deployment, we bundle all the JS in a single bundle (which is good for us, as we don't have too much JS in that project).
This will tell jspm to bundle src/app.js with all its dependencies, excluding everything in the src/ directory. This will result in JSPM bundling only your dependencies.
> The advantages [ClojureScript] has over ES6 fail to make up for the loss of a huge ecosystem…
What kind of "loss of a huge ecosystem" did you have in mind?
> …and this only seems to get worse because of the rate big JS community innovates (whether you'd classify this as 'churn' is another matter).
Last time I looked at CLJS and JS, it was the JS community that was catching up with CLJS (figwheel vs hot reloading, re-frame vs redux). People like David Nolen, Bruce Hauman and Mike Fikes are doing a lot of stellar work!
The man maintainers, at least from my own dealings with them, often don't like contributors. "Examples are nice, and I like your changes, but what if Paul Vixie doesn't?" It's easier to fork man completely and take it away from them, Xorg style.
You're free to try to incorporate these into the man pages. The creators of this (brilliant idea, btw, just what I have desired so many times in the past) are under no obligation to do so.
I still think that by preferring composition over inheritance things are just simpler and you don't have to trouble yourself with super or with before/after calls.
Maybe I just haven't been bitten by the dependencies labyrinth yet.
What about private functions? For now I just add `_` in front of their names, but the code would look so much cleaner if I had some kind of a `private` keyword.
This technique absolutely works for methods. And again, this shows the elegance of having simple features that compose, rather than building a monolithic OO system.
If you want something that isn't in the language, you build it yourself. If what you build becomes popular, in the fullness of time it gets built into the language as a full feature or as syntactic sugar. That's exactly how we got the class keyword, modules, everything.
But if you choose the wrong thing, one day your choice is obsolete. That is a risk, and it's prudent consider the consequences carefully.
If that troubles you, by all means write your code without any encapsulation, and wait for the language to acquire the feature in a few years. In the mean time, your code base will grow without that kind of encapsulation. Only you can determine whether this is a bad thing or not. YMMV, and all that.
This is a very common problem to ponder, we end up arguing about whether you should be an early adopter, a main streeter, or a laggard.
But really, the post isn't a screed in favour of using private properties, it's a suggestion that making classes out of first-class values in the language gives us the flexibility to build whatever we think we need.
Private properties is a particularly simple example. Traits and mixins are also useful, but would take even more space to articulate. But the general point is still that making new things ("classes") out of the existing materials ("functions and prototypes") is a win in general.
I don't particularly like this solution, because now I can't just write `this.rename()` in other Person functions. That's why I'd rather have a baked-in way to define private properties & functions instead of having to use (in my opinion) this weird syntax and later explain the whys and hows to other developers.
I tend to agree. Even as an author of one of the Fluxes (Fluxii?) mentioned, I still think this is the best approach. All of implementations I've seen simply formalize patterns the author was repeating on multiple projects.
(There's also know obligation to use them, the joy of OSS!)
Besides, Flow has a very ambitious target of delivering types for APIs which were not written with types in mind at all. I thought I'd be able to recreate some of the Elm's type safety with Flow, but that's just not possible and I doubt it'll ever be. But then again, these two projects have very different objectives.