My only issue with Hooks has been that they are not inputs into the component. It's a step in the right direction of making React more functional I would just preferred less magic, personally.
function Component(props, { useState, useContext }) { ... }
Of course that would break backwards compatibility with the old 2nd argument being context, so I get why they did it.
That's not the only problem with your approach. It is extremely common to use the output of one hook in the input of another, and that's only possible if the hooks exist in the function body.
I don't really understand how this approach breaks what you are describing.
All I'm saying is that instead of hooks API being imported from React at global scope it could be provided as inputs into the components directly. They would still exist in the function body as you put it.
Oh, I thought you meant that the hooks would be called there, which was one of the many alternative proposals made after hooks were announced.
In any case, it still wouldn't work because hooks are composable. You can create your own custom hooks outside of components which can be used as if it was one of the primitive hooks. That's not possible if the primitive hooks can't be accessed outside the component scope, unless they're passed in as parameters every time the custom hook is called (and that would be a right pain in the backside).
I was curious about this also, but couldn't find an answer. The most relevant thing I learned was that WebAssembly is exposed as a global object since Node.js 8.0.0, without a runtime flag.
I have not, this has been requested quite a bit though. My focus is currently on making sure the toolchain is stable and performant itself. It's likely that the performance of the compiled code is on par with other wasm vs JS comparisons though.
I wrote/maintain Walt. This question comes up a bunch.
The two projects are really similar no doubt. I can't speak for AssemblyScript, but my own motivation was simple. I wanted to learn WebAssembly and I wanted an accessible platform to do so with. At the time this wasn't really possible, tools like emscripten took forever to set up and were clunky to use. Plus I knew C already, I wanted to learn WebAssembly instead.
So where Walt is an attempt to write WebAssembly with a familiar syntax, AssemblyScript is an attempt to compile TypeScript to WebAssembly. To do so AssemblyScript comes with many more niceties/features out of the box IIRC, like optional(?) GC for example. Walt makes no such attempts and takes a more DIY approach.
Walt also has language extensions, via customizable syntax and compiler pipeline, where AssemblyScript is a TypeScript compiler more or less. My hope is that this allows for a babel-like situation for WebAssembly in the future via the tooling setup for Walt. I don't think this is a goal of AssemblyScript.
IMO this is a good decision. I much prefer a platform with a small API than I can personally extend over a large platform that has specific customization options or lots of extra features that all just "kind of" solve whatever problem I have.
Reading this makes me more interested in the project than I was before.
One quick recommendation, it was kind of hard to find the documentation for the Webpack free compiler (https://www.npmjs.com/package/walt-compiler). This is purely anecdotal, but I suspect that at least some of the people who are turned on by having a low-level library that doesn't include Typescript niceties will be turned off by seeing the quick-start immediately say to install Webpack. Might be a good idea to have the compiler documentation inside the wiki alongside the quick-start?
> The whole point of WebAssembly was to find some way to get away from JavaScript
The goal is to "Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities...."[0].
Everything old is new again, and the Wheel of Time turns, and ages come and pass, leaving memories that become legend. Legends fade to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the third age by some, an Age yet to come, an age long past, a virtual machine specification was created in an attempt to achieve the goal of write-once, run everywhere code. The specification was not the beginning. There are neither beginnings or endings to the turning of the Wheel of Time. But it was a beginning.
In the beginning Assembly became bytecode and CPUs included interpreters via microcode, then everything was supposed to be executed directly by hardware gates, now Assembly has become another form of bytecode and all major CPUs have reverted back to microcode.
What a weird argument. C is not "better" than Javascript, it is vastly worse for the vast majority of current Javascript uses - where raw performance is a less important consideration than development time.
Javascript is far from perfect, but it has improved by leaps and bounds the last few years. WebAssembly is great, but a variant of Javascript or other high-level languages will continue to dominate web development, not C. People aren't going to "escape" from Javascript to C, except certain niches where performance is vital.
If you like your JavaScript, you can keep your JavaScript. You have no reason to care about WebAssembly. Why would you build a JavaScript imitation on WebAssembly when you can just use JavaScipt?
That's the thing though. We are all "us" here. We can all compile whatever we want to WebAssembly, that's the point of WebAssembly. One way of doing things doesn't take away from another.
It's not a JavaScript imitation. This is a JavaScript-like syntax for writing WebAssembly. Other than that, (excepting the closure helper) it's 1-to-1 WebAssembly.
Not everyone enjoys writing verbose S-Expressions [1], even if it makes for a good canonical format.
If you despise JavaScript so much that you can't bear the thought of something that vaguely looks like JavaScript, then don't worry there are other "skins" for writing WebAssembly [2-4] and it should not be too hard to write your own.
Finally, nobody owns WebAssembly. It's for clever people like yourself just as much as it is for dirty JavaScript programmers like me.
You might like a JavaScript-like language but want to get rid of the garbage collector, or work closer to the bare metal than Javascript currently allows.
You'll have to excuse HN Guy that assumes that every project on GitHub is done to try and take over the world and not because, you know, learning is fun. So keep on doing weird things with your weird and awesome language.
I may be in the minority then: one of the big advantages, for me, of WASM is that I can use not-Javascript in the browser. Some of the issues I have with JS are an artifact of being one of the first things to run in the browser (e.g. atrocious standard library) and some are just baked in poor designs (e.g. implicit type casting, == vs ===).
Oh gosh, let's not forget what happens when you try to use map and parseInt together.
Sure, but you're putting a workaround in – there really shouldn't be any need for that no-op arrow function. But you do actually need it in order to drop all but the first arguments.
This doesn't work because map() stuffs a counter into the second argument of parseInt(), which is expecting a radix for its second argument. So the iterations of the map go like this:
…and so on, which obviously gives garbage results. JavaScript is littered with these kinds of weird edge cases. Even your example with the workaround isn't 100% reliable, it's browser-dependent – when you have leading zeros in your strings, some browsers will interpret them as octal, and some won't.
Language version dependent rather than browser dependent.
It may seem the same (after all, different browsers implement different versions of the language), but it's a bit different, if you say 'browser-dependent' it makes it sound like there is no standard when in fact, the leading zero behaviour hasn't been the case since ecmascript 5. You'll struggle to find a browser in common use that doesn't support at least ecmascript 5. It's as browser-dependent as the array.map function which was added at the same time.
Your example code would never have the leading 0 problem since you're using array.map and array.map didn't exist in the engines that had that leading 0 'feature'.
One of my major pain points with GitLab was its API. The lack of coherent API design ultimately made me lose hope in the product. For example I think it still lacks an ability to create threads on MRs. Until recently it wasn't possible to approve any MRs either, for 10+ versions of the product and 4+ versions of the api, but adding emoji was... The disjointed API made it nearly impossible to create quality tooling on top of GitLab, ultimately forcing us away from the product. It left a poor taste in my mouth, with a sense that there was no rhyme or reason to the direction of the platform, unfortunately.
