Echo JS 0.11.0

> Why did the industry move on from PHP, and what was the problem with it?

Well, the problem is that PHP is a horrible language. Here is an article about it: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

I like how that article is not just a rant, but instead, it has a detailed list of some of the many issues that the language has.

Yes, perhaps that is what the author meant with the word "they" - "they" could be the people who have the wrong idea, instead of being the closures themselves.

If the name of the article was instead "What is a closure in JavaScript and why most people have the wrong idea" I'm pretty sure it would not have all those down votes.

Not JavaScript related at all...

Well no, in this case the mother called her son "LiveScript", so they told her "No sweetie, is JavaScript, trust us"

Jokes aside, yes, on Brendan Eich's site and tweeter account he has it as "JavaScript", with an upper case "S"

And on echojs rules is this:

* Respect the case : JavaScript, not javascript or javaScript or Javascript

So yeah, I shall do it like that.

Is not JavaScript related, is more like "Mac users" related.

lol!

The part about `man wc` and the ctrl-c on vim were the funniest!

Is not really JavaScript related.

I kind of agree, but perhaps should be seen the opposite way.

So, instead of thinking about libui (or something similar) for only simple UI apps and electron for something more advanced, try to think about it more like using libui as default and only electron if something more complex is needed.

The way I see it, is that the difference between libui and electron, is that it is somehow the same as nativscript and phonegap, and offering a native experience can be considered a plus.

The advises in this article are good, but the author is wrong in the sense that he actually is not really going against the rule of "premature optimizations".

Donald Knuth said: "We should forget about SMALL EFFICIENCIES, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
If the speed gains are as huge as a magnitude of 10x or more, then they don't really count as "small efficiencies".

I think Eric S Raymond explains it better here: http://www.catb.org/esr/writings/taoup/html/ch01s06.html#rule_of_optimization

"From tortured code to incomprehensible data layouts, the results of obsessing about speed or memory or disk usage at the expense of transparency and simplicity are everywhere."

So, the rule is more about preventing writing hackish, non-KISS code that is faster than the simple, obvious code (code that is KISS), or at least until you realize there is a bottleneck you have to fix. Keep in mind that on languages like C, you can optimize writing code that is completely non-obvious, using knowledge of how the compiler works, etc.

So the author of this article is NOT giving a bad advice about writing hackish JavaScript code, but instead is about writing the code following good practices! Which is a very good advice!

cool!