Comment by dylan604
3 months ago
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.
3 months ago
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.
The last ten years of my career is basically all about manipulating data client side in JS. It works really well. In most cases I don't even need a server.
Obviously it isn't appropriate for all scenarios though.
In this case it is not bat shit. It is rather smart to offload this useless feature in the client.
The requirements are probably that normal users should not see “bad content”. If users can break the censorship it is maybe not the chat operators fault. They made an effort to “protect” the user.
> If users can break the censorship
Any user breaking the censorship likely knows already what the censor was blocking.
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.
The need to manage data access on the server does not go away when you stop using javascript. Is there something specifically about Swing that somehow provides proper access control, or is it simply the case that it is slightly more work to circumvent the front end when it doesn’t ship with built in dev tools?
Did I say anything about access control? There's a big difference between "this has to happen server side for security reasons" and "this has to happen server side because our UI/client language is so hapless that it can't handle any amount of additional processing".
1 reply →
The built-in dev tools is the key thing. If there was no way for the client to manipulate things, it wouldn't be too far off from other local apps. Reversing is always going to be a threat vector, but the low bar to entry of using the dev tools makes it a non-starter for me.
If using Ghirdra was as simple as using the dev tools, the software industry would collapse.
10 replies →
> 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?).
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...
"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.