I have it on good authority that the writers of the NYT have also read other news papers before. This blatant IP theft goes deeper than we could have ever imagined.
And lots of opportunities for them to be ignored or fired. Devs can complain all they want but at the end of the day we have to do what our bosses order us to do.
The vast majority of them probably never played the game in the first place.
I’ve never been much for crpgs (I do play DND though) and haven’t gotten very far into the game because it’s hot as balls right now in the PNW, but from the bit I have played it is very fun.
If you use rust and structure your program correctly you can avoid debugging directly by building unit tests in language the verify behavior. Debugging tools are great and I look forward to better dx stories there (you can use chrome + DWARF to debug your native code) but strictly speaking it isn’t necessary most of the time.
The language best suited for wasm is easily rust. And you can still interface with the Dom using frameworks like yew sycamore or leptos.
Debugging is still a little tricky but you can debug wasm in chrome and DWARF allows you to have source maps that map to your rust code. This is s problem the community is working to improve. Until then you have the full power of console log which is how a large portion of developers already debug their applications.
JS has little to do with accessibility. Most web accessibility comes from the Dom and aria attributes as well as semantic tags. You can do all of that with wasm too.
Are you asking about how it will work with wgpu based applications? This will work the same as it does on desktop applications. The program calls out to libraries that support talking to screen readers. I know rust the language with the best support for and ecosystem around wasm libraries like this already exist and ui frameworks like egui already have some support built in.
Ok but no one is talking about hand writing wasm. You write wasm with a language, such as rust, which already has great web frameworks such as yew (which replaces react) as well as leptos (which replaces solid.js). Leptos is already faster than react vue and svelte
I’ll give a +1 for this course. Prime is a great teacher. I’ve been a dev for a decade at this point and it really helped fill in the gaps for me that I’ve been missing all these years.
Unless you are going to be allowing custom html to be added the tooling is smart enough to figure out what possible classes your code can use. You’d have to do something dumb to not have the tools able to tell what components you are serving.
Ok so use modern frameworks and tools that implement the tailwind plugin. Because if you are shipping the entire tailwind css that’s a developer problem not tailwinds. News flash: using a technology wrong doesn’t make the tech wrong.
From their repo (https://github.com/rui314/mold#how-to-use)
Create .cargo/config.toml in your project directory with the following:
[target.x86_64-unknown-linux-gnu] linker = “clang” rustflags = [“-C”, “link-arg=-fuse-ld=/path/to/mold”] where /path/to/mold is an absolute path to the mold executable. In the example above, we use clang as a linker driver since it always accepts the -fuse-ld option. If your GCC is recent enough to recognize the option, you may be able to remove the linker = “clang” line.
[target.x86_64-unknown-linux-gnu] rustflags = [“-C”, “link-arg=-fuse-ld=/path/to/mold”] If you want to use mold for all projects, add the above snippet to ~/.cargo/config.toml
I really enjoyed tribes ascend for a little bit. But nothing will ever compare to tribes 1 and 2.
Shazbot!