ravicious

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. ;)

https://www.reddit.com/r/javascript/comments/42ozl3/why_we_s...

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).

> 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!

Maybe instead of creating something entirely new we could improve the existing thing, that is prepend man pages with some examples?

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.

Okay, now this certainly feels better than my example and is much more bulletproof than prefixing function names with `_`, thanks.

Sure thing, but could you show an example? Let's say we want the `rename` function be private, this is what I came up with: https://gist.github.com/ravicious/5412eebf8a1934ec7886

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.

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.

You don't really need a framework, one can get pretty far without it. Look up Facebook's Flux examples[1] to see how they're doing it.

[1] https://github.com/facebook/flux/tree/master/examples