71–80 of 158 posts
The fact that we're still pretending PHP is a valid solution for almost anything after all these years is a joke. Not only that, but now we have these "frankenstein" solutions with all the interop problems on top of PHP. Just shows that as a species humans really can't learn.
I really think there's a big opportunity for somebody to create the astral.sh for PHP.
With a proper package manager, PHP can do way more than what it presently can.
It’s the best of both worlds - the new app gets to see all of the traffic, but doesn’t need to implement 100% of the routes. Any added to the new app can just take precedence over the old one, carving out the path-space that gets reverse proxied.
It seems like doing FFI for this is overly complex; I’d rather take the small perf hit of doing another request to a different process.
Sometimes I think we should go back to basics: pixels, data, latency / bandwidth. The web is an optimization problem in the sense that we want to render correct pixels at perceptual speed given latency and bandwidth constraints. It should be more like: what pixels is the user about to see? What data is need to set the the pixels? What data is likely needed next and optimistically pre-fetch - something like that.
In https://github.com/timschmidt/alumina-ui I've been building for WASM using the egui toolkit which just accepts an HTML canvas the size of the browser and starts shouting WebGL at it. I get to forget about HTML and Javascript, CSS, most of the complication of the browser and web, and just write an application in my favorite language which will run fast and deliver GL accelerated graphics to it's users. I am really…
Cool that you’re creating an actual desktop-style gl app with it.
The fact that we're still pretending PHP is a valid solution for almost anything after all these years is a joke. Not only that, but now we have these "frankenstein" solutions with all the interop problems on top of PHP. Just shows that as a species humans really can't learn.
PHP really isn't that different from Ruby or Python these days. But, I can see the perspective where none of those 3 are valid solutions given newer better options like NodeJS and Rust.
They’re basically equivalent now.
Sometimes I think we should go back to basics: pixels, data, latency / bandwidth. The web is an optimization problem in the sense that we want to render correct pixels at perceptual speed given latency and bandwidth constraints. It should be more like: what pixels is the user about to see? What data is need to set the the pixels? What data is likely needed next and optimistically pre-fetch - something like that.
In https://github.com/timschmidt/alumina-ui I've been building for WASM using the egui toolkit which just accepts an HTML canvas the size of the browser and starts shouting WebGL at it. I get to forget about HTML and Javascript, CSS, most of the complication of the browser and web, and just write an application in my favorite language which will run fast and deliver GL accelerated graphics to it's users. I am really…
Sometimes I think we should go back to basics: pixels, data, latency / bandwidth. The web is an optimization problem in the sense that we want to render correct pixels at perceptual speed given latency and bandwidth constraints. It should be more like: what pixels is the user about to see? What data is need to set the the pixels? What data is likely needed next and optimistically pre-fetch - something like that.
Thinking about user seeing pixels is seeing just a part of the picture. As all software projects you don't optimize just for immediate user experience but also development time. Time to first draw rarely coincides with development time.
Earlier quoted context omitted.
In https://github.com/timschmidt/alumina-ui I've been building for WASM using the egui toolkit which just accepts an HTML canvas the size of the browser and starts shouting WebGL at it. I get to forget about HTML and Javascript, CSS, most of the complication of the browser and web, and just write an application in my favorite language which will run fast and deliver GL accelerated graphics to it's users. I am really…
I was wondering how long it would take for the web to get to this point. It seemed inevitable once canvas became a thing. You don’t even technically need gl or wasm to rewrite an entire rendering engine in js that can just blast pixels at the full-size canvas. Cool that you’re creating an actual desktop-style gl app with it.
Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to fix up the native build to make use of that sort of analysis, which I'd like, because I serve the whole application from microcontroller flash where I only have 4 - 16mb to hold application and firmware, including the http server and network stack.
I'm starting to build a bit of antagonism to all-encompassing frameworks (e.g. Spring, Larvel, Phoenix, etc.), because while they are productive to build new things with, I seem to always have the same issue on legacy projects built with them. It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing t…
Earlier quoted context omitted.
In https://github.com/timschmidt/alumina-ui I've been building for WASM using the egui toolkit which just accepts an HTML canvas the size of the browser and starts shouting WebGL at it. I get to forget about HTML and Javascript, CSS, most of the complication of the browser and web, and just write an application in my favorite language which will run fast and deliver GL accelerated graphics to it's users. I am really…
This! Love it!
Please consider joining the Discord: https://discord.com/invite/cCHRjpkPhQ
I'm the only one in there at the moment. Bring friends! lol