Echo JS 0.11.0

There is life after death. It's called React. https://medium.com/javascript-scene/javascript-scene-tech-survey-d2449a529ed

Or use something that works in browsers and has been ported to several other languages: http://usecuid.org/

Hi Rygo, looks like we're building similar things. See https://github.com/ericelliott/isomorphic-express-boilerplate

I already created a ticket to check out your project and see if there are great ideas we can steal. Please feel free to do the same. =)

"Complete" is a stretch. It should say "render a view in Node and the Browser in less than 5 minutes" because all this app does is render a view. ;)

TypeScript: Hopeful that better static type support will arrive in JS Proper. Not terribly impressed with it as a compile to language. I prefer something with less syntax noise, not more. CoffeScript is a step in the right direction for me.

Your comments have some merit, but what you don't seem to be considering is that the article wasn't written for FP experts. It was written for people who are probably a lot more familiar with OOP, which is why I used more OOP jargon than FP jargon.

Your take on whether or not idempotence is important surprised me. The very first sentence from wikipedia: "Idempotence (/ˌaɪdɨmˈpoʊtəns/ eye-dəm-poh-təns) is the property of certain operations in mathematics and computer science, that can be applied multiple times without changing the result beyond the initial application." This is a commonly understood definition in CS, and by that definition, all pure functions are idempotent -- important for many of the same reasons that idempotence is important in HTTP architectures (see http://restcookbook.com/HTTP%20Methods/idempotency/).

As I mentioned in the article, this property of pure functions strikes me as particularly relevant to web platform developers because it means that you can safely distribute computation without changing the results. Distributed computing is one of the reasons that I believe FP is going to be increasingly important in the future.

I'm not conflating idempotence with function purity. Not all idempotent functions are pure (they can have an initial side-effect, for instance, deleting or creating a resource), but all pure functions are idempotent.

I think your language analogy rings true because you're confused about the audience I'm talking to. If all the students speak French, but very little or no Spanish at all, it's probably helpful to start out speaking a little French just to give students some initial context and grounding.

If I were writing for an audience of FP experts, I'd be using words like "thunk" and "homomorphism" instead of "idempotence" and "encapsulation".

There's such a stigma around selling that it's really my least favorite part of my job, but sometimes you have to rally the troops to create change. There are people who just complain and don't do anything about the problem, and then there are the people who are willing to do what it takes to make things better -- even if it means writing a little promotional copy.

If it failed to sell, that would mean that it didn't inspire people to learn, but it sold very well. My tweet announcing the article is my most retweeted, most favorited tweet of all time, and I've been on Twitter since 2008 and tweeted about 14,000 times.

Obviously, the JS community is thirsty for better educational materials. I'm glad I can be part of the effort to make them available.

Thanks for keeping us in the loop, EchoJS!

They do feel awkward, don't they? First of all, when you're using functional inheritance (the one that requires *either* .call, or to have you pass the object in as an argument), you're specifically modifying an object that *already exists*, and since `new` doesn't let you change the value of `this`, and implies that you're creating a new object, that seems silly and counter to the semantics of what you're actually trying to accomplish. Think of functional inheritance is mixing in private state and privileged methods *after* an object has already been instantiated.

Second - I *always* do that work inside a factory... so I never actually expose that .call or object-pass-in requirement to end users of the API. I assume all the awkwardness, and if you don't want to deal with the awkwardness yourself, you can check out libraries like Stampit, where it's handled for you by `.enclose()`. https://github.com/dilvie/stampit

I believe I've taken a look at mongol before. I certainly like some of the features. That said, I have pretty strong feelings about requiring people to use `new`. It forces all your callers to be tightly coupled to your chosen method of object instantiation, making it harder for you to switch to true factory patterns if you want to add that flexibility later. By requiring callers to use `new`, you're forcing them to program to your *implementation* of object instantiation, breaking one of the golden rules of OO design: "program to an interface, not an implementation".

It's also a violation of the open/closed principle. See http://ericleads.com/2013/01/javascript-constructor-functions-vs-factory-functions/ and http://ericleads.com/2012/09/stop-using-constructor-functions-in-javascript/

- Eric

Thanks. =)