It's always still a good idea for you to write at least one for learning purposes, because it's cool. Also, the Intel engineer is saying that about compilers because the ICC compiler is reportedly better at SIMD than gcc and LLVM, IIRC. Compilers can be cringe sometimes.
Classes are also relatively new to JS, which is presumably why they're not used so much yet.
It's an equation of how tight your loops are vs. how many gray hairs you want. You can absolutely have shit that outperforms the standard BLAS whatever in your specific circumstances, because you know exactly what you're doing with those matrices and how big they are. If your application is 99.99% number-crunching, you will want to do crazy shit for the 2x speedup there. If you manually vectorize your user interaction code, you are insane (unless this somehow bottlenecks the CPU for 5 seconds, which also means you are insane.) If you manually vectorize something that only runs a couple of times a second in a worker thread and takes 2 ms, you are more than insane. TL;DR: profile your code (with anything from advanced profiling tools to subtracting two time points and printing to console) and work on code that bogs things down until it doesn't.
Unless in a restricted environment of some kind, dev costs are more important by far.
I recently found a more flexible way to achieve the same result as classes with just functions. This is a rather extreme example taken from a WIP refactor of an extension I'm working on:
const Chat = ((platform) => {
var socket = new WebSocket(SOCKET_URI);
...
function getChatContainer() {
return document.querySelector(platform.chatContainer);
}
function getExistingMessages() {
...
}
function sendMessages(msgs) {
...
}
function mutationObserve(muts, observer) {
...
}
function bindMutationObserver() {
...
}
function newBindInterval() {
if (document.querySelector(".sneed-chat-container") === null) {
const container = getChatContainer();
if (!(container === null || container.classList.contains("sneed-chat-container"))) {
console.log(`[SNEED::${platform.name}] Binding chat container.`);
bindMutationObserver();
}
}
}
return {
newBindInterval
};
});
var base = Chat(Platform());
setInterval(base.newBindInterval, 1000);
So basically it's the revealing module pattern?
Ah, didn't know there was a name for it; that's exactly what it is. With the amount of power and flexibility this provides, I haven't found a good reason to prefer normal classes over it. There are a lot of things I don't like about JS, but this feature feels really elegant to me as a long-time lover of LISP.
That's basically what I referred to off-hand as "wrap everything in a closure somewhere". Returning an object out of the closure gives you an accessible set of properties and/or methods that interfaced with it.
XMLHttpRequest and it'll have all of the methods/properties that it should have but you can override them and refer to the super properties/methods (the properties inherited from the parent class) as needed.window.XMLHttpRequest = class XMLHttpRequest extends window.XMLHttpRequest {
#requestURL;
open(method, url, ...properties) {
this.#requestURL = url;
super.open(method, url, ...properties);
}
send(body) {
this.addEventListener('load', () => {
// do something here?
});
super.send(body);
}
}XMLHttpRequest doesn't have to be redefined, it'll work exactly as it should work.
No. Use functions.
Oh, lol not sure how I missed that. Having functions, and essentially all non-primitives in JS, be treated as objects is a powerful paradigm to work with. There's something about well structured functional stuff that is immensely satisfying to my autismo brain. One of my all-time favourite projects was a final exam I did for a CS (not required since I majored in pure math) bird course back in the day; I had to write a full Scheme compiler in C using the classical CPS+trampoline based approach.
JavaScript is kind of like LISP pretending to be Java anyway.
Very true. IIRC, Netscape originally contracted Brendan Eich to embed Scheme for scripting while they wanted Sun to do the same with Java (cue war flashbacks to Java applets) and eventually they decided on something new that looks like Java and chose one of the most confusing names in computer science to boost adoption during the Java boom.
JS is, at its core, a functional language. There is a reason that a lot of the DOM APIs do functional shit in the first place.
void*s for callbacks and dynamic behavior. That said, being over a certain level of autistic about pure functionality and no side-effects will lead to a non-functional (but bug-free) program.
PHP runs on the server side. It can generate arbitrary HTML/JS/CSS and send it to the client. The client runs JavaScript, and the client-side JS can modify pages in arbitrary ways. You could, for example, make a PHP script that sends a mostly blank page that uses JS to load in content from other PHP scripts, but this is bad for SEO and bad for schizos who disable JS. No PHP is run on the client, the client can't even see the PHP code, and no JS runs on the server.
Though it can, with Node!
I think disabling JS is pretty much impossible in the browser nowadays, unless you're very determined. And Googlebot is supposedly able to run simple Javascript code for page-rendering, but I don't know how well it does it.
He's asking about PHP, so he's going to be asking from a LAMP stack POV.
It's as simple as going into the super-advanced about: config page and disabling it. NoScript and Tor Browser also allow for an easily-available switch. Googlebot uses a headless Chrome and runs everything in a page, and picks out links from anchor tags. Google has guides on how to make your JS abomination work properly. Also, not every search engine runs JS.
chrismoji ()