I think "minimum supported version" is a specific enough qualifier on its own. Whether or not it works on my favorite earlier version, actually supporting that version and making sure to maintain compatibility is more work for the maintainer.
As someone who has worked in projects with hundreds of seemingly trivial dependencies which still manage to produce a steady stream of security notices, "What qualifications do you have to write this software" seems like an entirely reasonable, far too seldom asked question to me.
Without the infrastructure behind it to make it make sense, cloud platforms just seem like convoluted ways of storing data and launching applications/VMs to me.
The only functional use of a tool like this to me would be to learn how to use AWS so that I can work for people who want me to use AWS. Would that not be to Amazon's benefit?
For me as a player that might have been a simpler solution to an entirely different problem. I don't imagine that playing a first person 3D game with free movement and platforming would be a pleasurable experience with the latency overhead of streaming video over the internet. That's part of the problem being solved here.
That e.g. a form should work predictably according to some unambiguous set of principles is of course a UX concern. If it doesn't, then maybe someone responsible for UX should be more involved in the change review process so that they can actually execute on their responsibility and make sure that user experience concerns are being addressed.
But sure, the current state of brokenness is a result of a combination of overambitious designs and poor programming. When I worked as a web developer I was often tasked with making elements behave in some bespoke way that was contrary to the default browser behavior. This is not only surprising to the user, but makes the implementation error prone.
One example is making a form autosubmit or jump to a different field once a text field has reached a certain length, or dividing a pin/validation code entry fields into multiple text fields, one for each character. This is stupidity at the UX level which causes bugs downstream because the default operation implemented by the browser isn't designed to be idiotic. Then you have to go out of your way to make it stupid enough for the design spec, and some sizeable subset of webpages that do this will predictably end up with bugs related to copying and pasting or autofilling.
That stupid thing where they make 6 separate inputs for a TOTP code is infuriating to me. I’m actually impressed though that I’m able to paste into one of those abominations without incident nearly 70% of the time, and over 50% of the time, they have gone to the trouble of reimplementing a mostly working backspace key there too. None of it should have had to be done of course, but I’m “impressed.”
What's there is already dead simple. The JS side and the WebAssembly module instance share a memory image and tables of imported and exported functions and variables. Everything else is left as an exercise to the programmer. It's hard to imagine a simpler, more conceptually straight-forward approach to it. An interface description language and component model at best makes some use cases more accessible at the expense of simplicity.
Not that I necessarily think it's unwarranted. While I appreciate the simplicity of the current approach to interop because it gives you free reign and is easy to grasp, I think anyone who has spent some time rawdogging JS-WebAssembly integration has considered inventing their own WASM IDL analog. If that can be specified as part of the standard it can also be made quicker.
reply