Sure, but you can get frameworks that generate that for you. I’ve written whole webpages in WASM without writing any JS.
You don’t get around reading JS documentation, though. Especially the DOM API is just documented as JS, and you basically hope that your framework makes it obvious enough how to write that in your non-JS language of choice.
This is exactly the reason why I can’t believe that was ever a requirement. I would have crazy respect for webassembly if it could stand on it’s own as it would allow people to completely move away from JS, but if JS is still in the stack in any way it will introduce a (even if it is minimal) compatibility and maintenance cost in the long run.
I used to think so, too, but on the one hand, the DOM API is absolutely massive. Going through the standardization, implementation and documentation process another time would take decades.
And on the other hand, a language-agnostic API in WebAssembly would mean specifying it WebAssembly itself. And well, it’s Assembly-like, so what’s currently a single line for calling a JS function would turn into tens of lines of low-level code.
Ultimately, you’d want code from some other high-level language to give you a summary of how you may need to call your language-specific wrapper. In practice, that’s likely even worse than translating it from JS, because the high-level call isn’t standardized.
i believe they plan to remove that requirement? at least i know they are trying to use a native wasm<->dom api instead of wasm<->js<->dom, which is slow
Big if true, do you have a link to follow that development? I’ve been curious about some languages that compile to JS+WASM but I’ve been waiting for something like this to finally cut out the middle man and give me an excuse to learn WASM directly.
There’s actually in theory all the pieces in place to use a different scripting language, because in the early days, there really were multiple. But yeah, the massive DOM API is only really standardized+implemented+documented for JS, so you don’t get around it in the end.
As the others said, though, WebAssembly is starting to become a thing and the JS boilerplate for calling the DOM API can be generated for you.
Most of the weirdness comes from being designed for the web, and specifically for working with forms. The value of a form field will always be a string, which is a simple and straightforward idea, but then the trouble showed up when we tried to make it more convenient to work that way.
Actually, most of the weirdness comes from having been originally designed in a matter of 10 days by a single engineer working to accommodate a tight release schedule.
I mean, do you think that has more explanatory power though? The type coercion rules are actually more elaborate with == than necessary for equality checking, because it was intended as a clever convenience for working with strings. If it was really all about the short timeline, wouldn’t you just skip that and do a more straightforward equality comparison, like the algorithm that === implements?
Besides, it’s not like everything in the language was conceived and implemented in those 10 days. The language has been evolving steadily since then. I’m not even sure if the modern == comparison algorithm worked that way in the first iteration.
Personally, I find it more useful to understand the context that lets me say “that’s a quirky consequence of a sensible principle,” rather than blaming it on the “ten days” legend generically.
I think the “ten days” explanation has the merit of being charitable, because it implies that Brendan Eich wouldn’t have made such short-sighted design choices under more favorable circumstances.
(I do not believe that it’s a “sensible principle” to treat text as such a fundamental form of data that a basic language feature like the equality operator should be entirely shaped around it. Surely the consequences of building an entire language around text manipulation should be apparent by considering how awkward Posix-style shells are for any nontrivial scripts.)
Well… The circumstances were that he was asked to whip up a little scripting language, that felt a little like Java and a little like Scheme, which could be used to add simple manipulations and interactions to web pages. Specifically to web pages. Not webservers, mobile apps, databases, banking systems, physics simulations, robotics… Only web pages. And nobody had even conceived yet of something like Google Sheets-- It was simple HTML forms and DOM manipulation.
IMO in that context, it makes alot of sense. I think it was probably still the wrong decision-- definitely with the benefit of hindsight, and quite possibly even at the time, even in that narrow context. Way more trouble than it’s worth.
But it’s beneficial to know that there was a principled (if misguided) reason behind it, that ties into the nature and history of the language-- It’s not simply “dude was in a hurry and not thinking.” Both are kinda true, but the former perspective helps us understand something useful, whereas the latter doesn’t get us anywhere interesting.
Can you write a website in other languages, like c# or python?
Yeah, anything that outputs HTML and CSS can do so. There’s a module for Apache to write webpages in Python (libapache-mod-python) and I’m p sure someone somewhere made a module to do it in Rust already except they’re infighting over whether tag parsing in it should be marked unsafe.
For that matter you do can write web pages in your shell eg.: bash, that’s what CGI is all about.
I guess why it’s weird because of the loose rules it follows, like what is mentioned about === and ==. There is WebAssembly which kinda acts like Javabyte code or CIL there used to be huge hype that it’s going to replace JavaScript, though it’s not used that much today. I think why there is low adoption is mainly because JavaScript is good enough, it’s widespread and easy to learn.
For real, or when you should make the first and second commit.
Or worse, when you’re too focused and start making a ton of changes, then you realize you haven’t committed anything. Discovering I can stage ranges has made me fall for this way too many times, because I think I’ll easily just go back and extract one atomic change at a time later (spoiler: it won’t be easy ( ; ´ Д `))
as soon as you realize you can’t easily contain your commit message within a 50-character conventional message (or slightly more if you wand to be more specific about the scope)
As a side note, the program is amazingly performant. For small numbers the results are instantaneous and for the large number close to the 2^32 limit the result is still returned in around 10 seconds.
For a long time I’ve been of the opinion that you should only ever optimize for the next sucker colleague who might need to read and edit your code. If you ever optimize for speed, it needs to be done with massive benchmarking / profiling support to ensure that the changes you make are worth it. This is especially true with modern compilers / interpreters that try to use clever techniques to optimize your code either on the fly, or before making the executable.
I do feel like it’s good, though, when libraries optimize. Ideally, they don’t have much else to do than one thing really well anyways.
And with how many libraries modern applications pull in, you do eventually notice whether you’re in the Python ecosystem, where most libraries don’t care, or in the Rust ecosystem, where many libraries definitely overdo it. Because well, they also kind of don’t overdo it, since as a user of the library, you don’t see any of it, except the culmulative performance benefits.
Libraries are also written and maintained by humans.
It’s fine to optimize if you can truly justify it, but that’s going to be even harder in libraries that are going to be used on multiple different architectures, etc.
I’m still mad he didn’t use the size of the number to tell the system which block to read first. I feel like that would be a great use of division or maybe modulus?
I actually like this. This would allow reuse of all the infrastructure we have around XML. No more SQL injection and dealing with query parameters? Sign me up!
Better than parameterized queries. Yes, we have stuff like query(“INSERT INTO table(status, name) VALUES ($1, $2);”).bind(ent.status).bind(ent.name).execute…, but that’s kind of awful isn’t it? With XML queries, we could use any of the XML libraries we have to create and manipulate XML queries without risking ‘XML injection’. e.g we could convert ordinary structs/classes into column values automatically without having to use any ORM.
Typescript can add type safety on top of that, of course. And there’s the option to prepare a query once and execute it multiple times.
Honestly, the idea of manipulating XML queries, if you mean anything more fancy than the equivalent of parameter injection, sounds over-complicated, but I’d love to see a more concrete example of what you mean by that.
Could be easily made 50% space saving by only iffin all odds and return even on else. Maybe one if before to handle overflow to avoid wrong even if over the last if.
I think he was being sarcastic, playing with words. Meaning, that you trade in time, runtime and memory and get nothing in return :D so a pretty bad trade haha.
Of course it’s worse, I mean, that was the point of this blogpost, wasn’t it? :p It’s just a (long) joke.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.