Follow

is the only way to decouple blocking procedural js from blocking the DOM really by using webworkers

@mavica_again async is supposed to be able to do this but since the runtime is all mysterious and entirely done via the browser there's no way to ensure the kind of granularity that rust tokio can for example

@mavica_again the cause of all problems here is google and apple and microsoft are fighting to win the browser wars still

@hipsterelectron i wish i could tell it not to be blocking like "hey generate this image and then update the DOM whenever it's done" but apparently the only way to do that is threading

frankly unless you're doing http fetching i cannot think of an application for async otherwise, because pretty much everything else turns async into blocking anyway

@mavica_again it's a useful distinction when the language doesn't have a massive opaque runtime that tries and fails to hide all this from you. explicitly choosing when and where to run some code is cool but javascript has only worn the skin of its enemies as a face recently there have been very few thoughtful language features widely used by experts like rust async and stuff like destructuring assignment doesn't retain any of the underlying value model that makes it so useful in coffeescript

@mavica_again i'm a huge coffeescript fan and have been contributing to the compiler recently so please allow for personal bias

@mavica_again oh actually you're right about that last part. languages should expose a general coroutine interface—python of all places happened to do this right and it got literally nothing else right—before async and it's why there's strife about any of this at all

@mavica_again and async models created for http requests suck and produce slowdowns with e.g. local file i/o. io_uring is not exactly an answer bc it still doesn't address the latency expectations of remote network being used to optimize for every other performant use case

@hipsterelectron i love how much you clearly know about this because i'm just a dingus prodding around mdn with programming patterns firmly stuck in like 1993 or so

if you look at the source for ditherinator i think you'll have a feel for how little i'm aware of all the stuff you're saying lol

@hipsterelectron i bet if i learnt typescript or coffeescript or webassembly or whatever i could compile ditherinator into something that works 1000% faster but that involves a workflow more complicated that "save app.js" and "refresh browser that's pointed to a local html file and not a webserver"

@mavica_again i made jison 12x faster in 30 minutes of work after making it 2x faster with two weeks of work (which i ended up discarding) and that was by modifying the js source, not rewriting it (which i could and did do but the jison test suite sux so i decided not to do since i couldn't maintain it) github.com/jashkenas/coffeescr you have to be doing some very specific things to memory (which js has faster APIs for now) or using specific like math libraries for js to not be comparable in perf. js engines are some of the most advanced JITs humanity has created

@mavica_again my packagingcon 2023 talk was literally me going "i fucking did all the bullshit everyone else at this conf is making shit up about and you're all wrong local i/o perf is not something any programming language helps you with literally the power of friendship is faster than a thousand compilers" and i'm right and they were wrong and they were hawking a product and i wasn't

@mavica_again typescript doesn't help perf it just makes you add type annotations which may or may not be useful (i followed the coffeescript maintainer's proposal to use jsdoc types) github.com/jashkenas/coffeescr but it's not perf. there is no rewrite that will solve performance imho

@mavica_again i'm ride or die for rust bc i like good languages for touching memory but it's not gonna make the code faster

@mavica_again i also specifically work on build tools and IDEs and write tons of elisp bc the kind of dev workflow you describe is table stakes for being able to understand your own and others' code. i like coffeescript because to me it's simpler and closer to my intent

@hipsterelectron idk i'm just out here trying to get slider no freezy while the code makes the image

@mavica_again basically fancy tech doesn't actually help with the stuff that matters ime and i don't think typescript or coffeescript is gonna help you sorry i was in an awful mood last night. there may be some stuff to do with wasm for pixel manipulation but nobody else is trying to make the wasm build process better and also js is fast enough for most stuff. so you lose insight for no reason

@mavica_again i got really mad about this for python and again for rust cfp.packaging-con.org/2023/tal ppl are using the async marketing line bc it's being pushed by corporate monopolists who want to sell you a bridge. [said in tones of immense disdain for my foes but also respect for other similarly minded practitioners] but i am an educator

@mavica_again oh wow ditherinator is pretty cool. i was thinking of a similarish interface for github.com/cosmicexplorer/dmca which will never happen bc ffmpeg wronged me and also bc wasm is cursed by google to only be useful for monopoly and not for threatening google's bottom line which requires owning the entire web platform (i can elaborate) and the interface was gonna look similar if i actually made it

@mavica_again also inspired by the interface of everest pipkin's image scrubber tool for my next attempt to use wasm and/or webgpu to poison facial recognition circumstances.run/@hipsterelec

@hipsterelectron far less recreational applications than the doofy little stuff i write lol

Sign in to participate in the conversation
Computer Fairies

Computer Fairies is a Mastodon instance that aims to be as queer, friendly and furry as possible. We welcome all kinds of computer fairies!