←back to thread

755 points MedadNewman | 3 comments | | HN request time: 0.001s | source
Show context
lxe ◴[] No.42891381[source]
You can also intercept the xhr response which would still stop generation, but the UI won't update, revelaing the thoughts that lead to the content filter:

    const filter = t => t?.split('\n').filter(l => !l.includes('content_filter')).join('\n');

    ['response', 'responseText'].forEach(prop => {
      const orig = Object.getOwnPropertyDescriptor(XMLHttpRequest.prototype, prop);
      Object.defineProperty(XMLHttpRequest.prototype, prop, {
        get: function() { return filter(orig.get.call(this)); }
      });
    });
Paste the above in the browser console ^
replies(2): >>42891427 #>>42891516 #
noman-land ◴[] No.42891427[source]
This is why javascript is so fun.
replies(1): >>42891685 #
dylan604 ◴[] No.42891685[source]
It's precisely why I'm a such an advocate of server side everything. JS is fun to update the DOM (which is what it was designed for), but manipulating data client side in JS is absolutely bat shit crazy.
replies(3): >>42892008 #>>42892324 #>>42893011 #
atomicnumber3 ◴[] No.42892008[source]
I wish js (and, really, "html/css/js/browser as a desktop application engine) wasn't so bad. I was born into a clan writing desktop apps in Swing, and while I know why the browser won, Swing (and all the other non-browser desktop app frameworks/toolkits) are just such a fundamentally better paradigm for handling data. It lets you pick what happens client-side and server-side based more on what intrinsically makes sense (let clients handle "view"-layer processing, let servers own distributed application state coordination).

In JS-land, you're right. You should basically do as little as is humanly possible in the view layer, which imo leads to a proliferation of extra network calls and weirdly-shaped backend responses.

replies(2): >>42892065 #>>42896679 #
1. wiseowise ◴[] No.42896679[source]
> I was born into a clan writing desktop apps in Swing, and while I know why the browser won, Swing (and all the other non-browser desktop app frameworks/toolkits) are just such a fundamentally better paradigm for handling data.

No, by a large margin no. Java is a hostile language to prototype programs at which JS excels. Awful styling, walls of code just to get sane defaults (https://docs.oracle.com/javase/tutorial/uiswing/dnd/together..., seriously?).

replies(2): >>42897556 #>>42912315 #
2. homebrewer ◴[] No.42897556[source]
Swing is decades old at this point, its shortcomings have nothing to do with Java. JavaFX does not require this much boilerplate.

https://docs.oracle.com/javase/8/javafx/get-started-tutorial...

3. atomicnumber3 ◴[] No.42912315[source]
"And all the other desktop app frameworks." I refer to Qt and and the other desktop frameworks too. Having an actual language and runtime where the UI toolkit is just that, a toolkit. Don't focus on Swing, that's just what I'm familiar with.