71–80 of 83 posts
I know that data science is a broad and somewhat vague term but this - We will cover: Core features of modern JavaScript Programming with callbacks and promises Creating objects and classes Writing HTML and CSS Creating interactive pages with React Building data services Testing Data visualization Combining everything to create a three-tier web application - this isn't data science.
I know that data science is a broad and somewhat vague term but this - We will cover: Core features of modern JavaScript Programming with callbacks and promises Creating objects and classes Writing HTML and CSS Creating interactive pages with React Building data services Testing Data visualization Combining everything to create a three-tier web application - this isn't data science.
Compare this with: „Data wrangling with JavaScript“ [1]
[1] https://www.amazon.de/Data-Wrangling-JavaScript-Ashley-Davis...
Earlier quoted context omitted.
Excellent point! I can see that getting confusing quickly. Edit: I was confused about how this could work, so I dug through [1] for a bit. It appears that for each object of that class created, an arrow function will be created on that object and its this will indeed be bound to the same scope that the constructor function is bound to. This is really cleaver and I applaud whoever thought it up! It is interesting to n…
> This is really cleaver and I applaud whoever thought it up! Not really. It's contortionist and wasteful and one of the many reasons why mainstream web apps are one big celebration of bloat on a boat. The neophyte programmers who have turned into expert Modern JS programmers are always recommending arrow functions like this because they've never actually looked at the event listener interface. What happens is they t…
---
As I understand the interface, practical use of the EventListener interface boils down to the implementer performing a form of event delegation, where you'd wind up delegating from a single `handleEvent()` method on a class to handle different event types and/or events with different target elements -- as opposed to a single click handler in a simple button click example. I'd love to understand and quantify the benefit of this. If it's a significant improvement, it'd be doubly unfortunate, as many callback-based interfaces in JavaScript APIs and libraries at a higher level don't support such a model.
Assuming there's a strong benefit, I also wonder if there's an opportunity for build-time tooling to rewrite code from ad-hoc callbacks to more efficient delegation along these lines. Tangentially, I also don't know about `Function.prototype.bind` vs wrapping arrow functions in terms of performance; that's also something I'm curious about, as they're often a 1:1 analog.
I'm tempted to test a few of these things out myself, but if you have references, that would be helpful.
Earlier quoted context omitted.
> That is not true. BigInt has been available for a bit already. performance-wise, BigInts are terrible. Tried to use them, made things about a hundred times slower. What JS needs are 64 bit integer types, and some form of typing system that allows differentiating between various number types.
Genuine question: I imagine most data science things involve arrays of numbers, not just single numbers. JS has UInt8Array, i.e. it does kinda have integers if you want them in an array anyway. Can that speed things up?
Earlier quoted context omitted.
> This is really cleaver and I applaud whoever thought it up! Not really. It's contortionist and wasteful and one of the many reasons why mainstream web apps are one big celebration of bloat on a boat. The neophyte programmers who have turned into expert Modern JS programmers are always recommending arrow functions like this because they've never actually looked at the event listener interface. What happens is they t…
I want to respond to this constructively, because you highlighted a useful interface I'd never taken note of previously; maybe we can focus this discussion on a technical level. Meanwhile, if you haven't had a positive response to technical feedback directed to JS engineers about this, I would encourage rereading the comment you wrote. I genuinely hope this is useful feedback, as I very much value insight from other…
You're mixing up cause and effect; there's a reason why the perspective laid out in that comment has come to carry the amount of derision evident in its tone. It's wrong to assume things started out like this (and it's wrong to assume that a different tone will achieve better results; experience shows that the difference in results, if any, is worse otherwise).
> Assuming there's a strong benefit, I also wonder if there's an opportunity for build-time tooling to rewrite code[...]
That's another example of "layering on more" approach, and the small matter of changing the actual runtime mechanism in isolation isn't going to solve much. The big, relevant matter at hand is a complete difference in mindset that programmers have when they're approaching a problem with the ultimate intent of solving it with code.
For example, let's say you have a list of items, and M different kinds of events you want to respond to. That's not just a matter of a difference of e.g. 1 listener (implementing `handleEvent`) vs 2 or more (individual arrow functions). If that list is N items long, now we're talking about M × N different objects (worse, closures—each with their own lexical scope, keeping the bindings alive and potentially thwarting the GC's work)[0]. But the programmer who knows not to use arrow functions here doesn't just stop at implementing `handleEvent`, he or she also recognizes that if all of those listeners share common behavior, then the whole thing can be handled by a single event listener—on an ancestor element that just looks at the event target.
Once again, though, this is much bigger than event listeners. This is about a mindset that pervades everything at every level. The mindset of programmers working in "modern", "standard"[1][2] JS is a mindset that fundamentally impacts how they approach everything, from how to decompose a system into its natural parts, to what routines need to be written and what factors to be aware of while implementing them.
Note that unlike the comments elsewhere, this isn't mistakenly misplaced aggression towards JS per se, nor is it an endorsement of other communities/ecosystems like Python, which tends to have programmers that are just as bad, if not worse. A big part of the problems afflicting the world of modern JS for that matter is programmers who have ended up there by way of Python or similar.
0. Runtimes will have some mitigations for this, but eventually that runway ends; the myth of the sufficiently smart compiler although an enduring one, is unattainable
2. Let's consider, for that matter, the obnoxious temerity that it takes to decide to anoint one's opinionated, less-than-well-informed set of personal preferences—many of which ironically reek of fighting against the language itself—as "standard"
Earlier quoted context omitted.
> This is really cleaver and I applaud whoever thought it up! Not really. It's contortionist and wasteful and one of the many reasons why mainstream web apps are one big celebration of bloat on a boat. The neophyte programmers who have turned into expert Modern JS programmers are always recommending arrow functions like this because they've never actually looked at the event listener interface. What happens is they t…
I'm learning all sorts of things today! handleEvent certainly seems like the language certified way to do this. It does seem like that means you need a case statement in handleEvent if you want to listen for multiple events, which I guess is not the end of the world. It does solve the "redefine the function for every object" problem though, provided any third party apis understand the EventListener interface.
It's a platform API (the browser DOM). It's a completely separate matter from JS the language. It has, though, been the "correct" way to work with events since at least as far back as 1998 or so. It's the official platform APIs that had to change to accommodate the function-as-a-listener pattern (requiring an entire revision to the interface definition language itself so that it would have the power to express it), since so many browsers implemented that non-standard extension, and so many programmers insisted on using it. And that pattern is also directly responsible for why arrow functions and Function.prototype.bind were added to the language itself. If only it had been addressed differently, writing programs for the web browser might look a lot different than the way it does today.
Earlier quoted context omitted.
Excellent point! I can see that getting confusing quickly. Edit: I was confused about how this could work, so I dug through [1] for a bit. It appears that for each object of that class created, an arrow function will be created on that object and its this will indeed be bound to the same scope that the constructor function is bound to. This is really cleaver and I applaud whoever thought it up! It is interesting to n…
> This is really cleaver and I applaud whoever thought it up! Not really. It's contortionist and wasteful and one of the many reasons why mainstream web apps are one big celebration of bloat on a boat. The neophyte programmers who have turned into expert Modern JS programmers are always recommending arrow functions like this because they've never actually looked at the event listener interface. What happens is they t…
Eh, show me an object that both owns a button and is an event listener attached to that button, and I’ll bet you just showed me an object that violates the SRP. OO event listeners make sense to encapsulate state narrowly associated with handling the events being listened for.
But, having been doing OOP since I was a teenager in the late 1980s (and even that after programming for more than half a decade), I don’t prefer to do as much JS as possible in a functional style because I don’t get interfaces or other OO concepts, but because I understand the limits of their utility and managed not to be one of the one-paradigm-to-rule-them-all programmers that came out of the excessively OO-focussed pedagogy of much of the 90s and 00s.
I don’t want to repeat the old and tired JavaScript hate, but this just isn’t a great idea. I’d suggest that there are 3 important primitives for data science: flexible numeric types, fast math/algorithm libraries, and data manipulation being easy. JavaScript doesn’t really have any of these. Numbers are 64bit floats only - no integers, no big numbers. There aren’t equivalents to Numpy/Pandas/Scikit Learn, and the la…
NodeJS evented architecture is great for multitasking training (and prediction) jobs. I use Node Streams to extract and process data flows out of several data sources on my Macbook Air M1 using the new Neural Engine 16-core chip to train CNN models with excellent results.
Data prediction then runs on a ReactJS app, which gives my users a way to model, transform and visualize data on a browser. Everything is in Typescript, which reduces cognitive overload for our programmers and produces good end-to-end duck-type coherence and easy, integrated testing.
Now, most data science libs for Javascript are either on their infancy, are proof-of-concept or just abandoned, but TFJS is solid and if you know what, why and to which extent you're using JS for data science, then it's absolutely fine.
I know that data science is a broad and somewhat vague term but this - We will cover: Core features of modern JavaScript Programming with callbacks and promises Creating objects and classes Writing HTML and CSS Creating interactive pages with React Building data services Testing Data visualization Combining everything to create a three-tier web application - this isn't data science.
Like, all the stuff "for my data science", such as making a visualization website etc.
Earlier quoted context omitted.
> This is really cleaver and I applaud whoever thought it up! Not really. It's contortionist and wasteful and one of the many reasons why mainstream web apps are one big celebration of bloat on a boat. The neophyte programmers who have turned into expert Modern JS programmers are always recommending arrow functions like this because they've never actually looked at the event listener interface. What happens is they t…
> Make your line for registering an event listener look like this: `this.button.addEventListener("click", this)`, and change the name of your `addSum` method to `handleEvent`. (Read it aloud. The object that we're dealing with (`this`) is something that we need to be able to respond to clicks, so we have it listen for them. Gee, what a concept.) In other words, the real fix is to make sure that the thing we're passin…
Sounds like a veiled criticism towards an implied target (of me), which would be interesting, considering the retort is an appeal to "SRP" (referred to only with shorthand, even), and indeed, the first mention of OO(P) is your comment. The shape of your foe isn't what you think it is.
> OO event listeners make sense to encapsulate state narrowly associated with handling the events being listened for
For this defense to be valid, you have to ignore the preconditions that got us here. The entire context here is making sure that `this` refers to the correct thing at the time that the event listener is executed. Either you want that, or you don't—pick one.
(And as with, like, 90% of mainstream applications of the label "functional programming", look at what people are actually talking about when they use those words, and it's immediately apparent that theirs is a style of programming where the label is unjustifiable, considering it's fundamentally at odds with what functional programming actually is. Again, pick one: you either intend to do FP and do so through the use of functions, or you want your state baggage. Modern appeals to FP by JS programmers in the mainstream and the practices that get smuggled in under that brand are just as bankrupt as arguments for modern JS practitioners' best practices regarding anything else—ones that are entirely self-defeating or fail to hold up under scrutiny otherwise.)