41–50 of 242 posts
I guess there may be a way to do that using a parallel DOM structure that exists to give the screenreader something to hook into, but at that point it's probably easier to go back to using HTML.
But this is an open telemetry data aggregation and analysis tool (at least that’s what my half hearted perusal of the post led me to believe).
Probably not too heavyweight for such a tool, although my default response would be a Tannenbaum-like admonishment. Or maybe the Jurassic Park response.
I will say I have seen worse wastes of resources.
Let them have their fun. Either they learn from this implementation for v4, or it works out and there is no need for v4, in which case, as they say, the proof will have been in the pudding. Win-win.
They probably won’t like their egress bills tho.
Will just comment that I think there is huge value on having all pieces (front end/back end/apps) on the same language if at all possible, especially for small teams. I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in ou…
WASM makes sense for certain niche use cases but it's really absurd just to make a regular web app. This is an app made with go-app and it loads 3.6MB of WASM code for a simple media player. https://lofimusic.app/collegemusic It's not much different for Blazor. Even for a simple app you're looking at an initial load of at least +1MB.
Code complexity is more of an issue in apps like this one. I'd guess that a WASM binary of a Go app is going to cause the JS engine to be busy a lot more than a typical JS app, which will increase CPU usage a lot, and eat into the user's battery life. That is a guess on my part though. Maybe WASM optimizes that?
From the webpage: "Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture changes and the creation of a “smart backend” for incremental data loading over WebSockets, using Go's rarely-used encoding/gob format." From https://pkg.go.dev/encoding/gob "This package is not designed to be hardened against adversarial inputs, and is outside the scope of https://go.dev/security/policy . In parti…
if you can't trust your own backend, step one is reevaluating your life choices
But IMO they should have went with Rust -- smaller WASM binaries and even better memory footprint. And they said these were concerns. So IMO they didn't go far enough.
But it's also completely understandable. They already had a Golang codebase. So it was either go all in in the JS/TS ecosystem or all in in the Golang ecosystem. They made the right choice but again, they could have went even further and kill all birds with one stone. A heavy and quite time-consuming stone, granted.
Is it even possible to make this combination screenreader accessible? I guess there may be a way to do that using a parallel DOM structure that exists to give the screenreader something to hook into, but at that point it's probably easier to go back to using HTML.
Yes, a DOM structure, parallel or otherwise, is needed. Dioxus does this with rust and WebAssembly and it seems it should be able to do just about everything a js app does and it’s competitive in the rendering benchmarks.
Will just comment that I think there is huge value on having all pieces (front end/back end/apps) on the same language if at all possible, especially for small teams. I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in ou…
Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.
Just the same Languages have their strengths. Using a backend language to write your frontend is more or less a waste of developer resources. Chances are if you just chose react and typescript you could pull things off the shelf and have almost an unlimited amount of resources and developers you could pull from compared to an esoteric LiveView or webassembly type framework, get the project done faster, ship and iterate as opposed to reinventing the wheel and satisfying the commonly felt NIH syndrome.
Typescript for both frontend and backend is a bit better, but the backend story for me is still weaker than using Python or elixir, etc simply serving an API, because if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit.
the only exception to the above is if you aren't building a company and instead working on a small personal or group project.
Will just comment that I think there is huge value on having all pieces (front end/back end/apps) on the same language if at all possible, especially for small teams. I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in ou…
And react introduces a host of dependencies which may be ill maintained. The only reason to bring this up in an online forum is because I'm tired of recruiters constantly asking for react and nodejs.
Earlier quoted context omitted.
Do you think maybe this is less of a big deal in the brave new world of chatGPT. I know I have zero worries about having to code in a new language or framework with the ability to get answers so quickly to my dumb questions, but maybe that is because I’m still choosing languages and frameworks that are fairly popular and have so much online documentation that the LLMs know about them, and if something is really esote…
Due to the restrictions (short term at least) when it comes to training data and availability of documentation, I believe coding in a new language or framework becomes an even bigger mountain than usual due to chatGPT providing misleading information. This is made worse if there are breaking changes in a new release that you are using. Even when the thing is popular, like Svelte, it was giving me outdated information…