Echo JS 0.11.0

Spammy spam

Spammy spam

After thinking about it a bit more... You *could* apply a couple other effects.

I mean, initially you're restricted to applying CSS over the background canvas. Other than a blur(), you could do sepia() or invert() or a few others, but the effect isn't particularly interesting.

But you could also build an SVG filter and apply that on the canvas through url(#filterid). This does expand the options farther. Then again the problem is that SVG filters can be rather expensive and you're probably going to be blowing your reader's fans into turbine mode.

At first I thought it should be obvious by looking at the repo, but no, it's not. "Cinematic effects" - it says. Not much of an explanation. Maybe looking at the linked demo code... Not really, no, there's little code there to understand. Then I looked at the demo site itself... and uh, again no. I click the buttons and... mmm... maybe it's something subtle.

And then, if you actually inspect with the dev tools what the code is supposed to be doing it turns out it's indeed a very subtle effect... It's like a "tv backlight" [0].

The readme suggest various applications, but the actual purpose of the library seems somewhat limited. What it does is simply connect a <video> to a <canvas>. "Connect" in the sense that it dumps frames from the video into the canvas. And it applies a sort of motion blur filter to it. The only thing you seem to have control over is how much of that motion blur is applied (setSensitivity).

To understand it better, I'd suggest going to [1], opening your dev tools, then finding the <video> and <canvas> elements and their container. Disable the container's relative position, and the canvas blur filter. That will make the canvas more visible. Then play one of the videos (the forest one is good) and from the console do effect.setSensitivity(1) and then effect.setSensitivity(0.5) and then effect.setSensitivity(0.1).

As far as I can tell, this is all it does, and I can't really think of much else to do with it other than the "tv backlight" effect or something very similar to it.



[0] https://duckduckgo.com/?q=tv+backlight&iax=images&ia=images
[1] https://simonwep.github.io/cinematic/

> IIRC Array.prototype.forEach was ES5 (not 6), while Object.entries was added with ES6/ES2017.

Correct for forEach, it was ES5 (2009). As for Object.entries... uh, yes but not... It was added on ES2017 which is ES8. So... ok, you probably got a typo there :)

Anyway, it might also be interesting to note that on the other hand Object.keys() is quite older. It entered the standard at ES6, but was available in browsers -except obviously IE-  at least 3-4 years before that.

> person@web.2 is valid

> person@2.d. is valid

> paul@paul@paul@ding.dong is valid

Eh, maybe those expressions aren't quite that good.

Spam

You mention "I don't actually know how to replace classes outside of React." To me, that means you don't really have much experience using classes.

Then "Classes in JavaScript are implemented differently from the others." But classes are implemented in many different ways in various other languages. There is no single "standard" on how classes are or should be implemented. That JS classes are "different" means nothing. Classes in, say, Ruby are quite different than classes in, say, C++. That you should point this out as a problem tells me you don't really have a deep knowledge on classes in general or that you have used them rarely and only in some specific contexts.


"Correctly understanding how this works" is indeed easy. Saying it's not, well...



You allude to class instances "not playing well" with destructuring. I don't know which supposed problems you have (because you offer no explanation on what the problem is), but it anyway feels like a minor, irrelevant thing.


"It's easy to say, "classes are not necessary, just write functions" however, the second you step outside the React ecosystem, it's different." - you say. And this, clearly, says you don't have much experience outside of the React ecosystem. It's not different. "Just write functions" is exactly as easy whether you're using React or not. Nothing at all forces you to use classes when you don't use React. React is not this magical world completely separated from JavaScript... at least not technically; as a cult, well, that's a different subject for a different time.


You say that "classes encourage using inheritance" and that inheritance is an "outdated concept". This is really not so. Inheritance is, again, a tool. If you know how to use it successfully, it is a good tool for you. If you don't and you misuse it, it will be a bad tool for you.



This are your words. It's not me saying you don't understand or that you don't have much experience with them. It's you saying it :)

I don't really have a pro-classes argument, nor an anti-classes one. They are a tool.

What I find absurd is discarding classes because you don't understand them and then trying to again approximate what classes already provided, but in a clearly worse way.

I'm sorry but this is an incredibly stupid title for an equally absurd article.

The title is so stupid it doesn't even merit consideration. The content of the article is "weeee, I don't like classes but I'm going to try to implement a bunch of different stuff to approximate a worse version of classes because that's very clever". Obviously, it's nothing new at all, stuff that has been used for years before JS had "proper" classes.

P. S. "David Crockford"? Really? Citing someone and not even bothering to read their name correctly?