846 karma · joined January 14, 2022
I mean, web components are JS with HTML in them and you have all the power of JS to manage state and functionality. In case of zjs you have HTML with JS in it and you get an entry point callback to set up your instance (and another to clean it up).
BTW, the API is a little awkward (`exports.onConnect = function () { /.../ }`) and easy to mix up with the standard syntax (`export function onConnect() { /.../ }`) which you can't actually use here.
In either case you have to include a script into your page to make the component work. But also when you have many different components in case of regular webcomponents you use a somewhat readable markup:
<x-counter start-at="100"></x-counter>
<x-counter start-at="200"></x-counter>
<x-whatever></x-whatever>
With zjs you have to use the same tag for everything: <zjs-component remote-src='counter-obj.zjsc' start-at='100'></zjs-component>
<zjs-component remote-src='counter-obj.zjsc' start-at='200'></zjs-component>
<zjs-component remote-src='whatever-obj.zjsc'></zjs-component>
To me this looks not unlike the primordial div soup. And on top of it it's 1 more request as compared to regular webcomponents.The point is if HTML inclusion is not the main feature, but rather the per-instance state then regular WebComponents seem like a better solution if only for being a standard. When a reader sees a WebComponent they immediately know what they're dealing with. zjs appears to solve the same problem but differently, yet uses WebComponint API itself.
From very simple (https://github.com/include-html/include-html.github.io/blob/..., from 3 years ago), to more sophisticated, including script execution (https://github.com/SirPepe/html-import/blob/master/src/html-..., from 4 years ago; or even https://github.com/webcomponents/html-imports/blob/master/sr..., dating back 9 years). I haven't checked all of them but there's a decent chance there's something that covers each feature of OP, maybe even at once.
At the moment it's unknown whether it's a normal function of the system or a result of miscalibration/malfunction (assuming the theory is correct). Existence of these people is only an evidence for the capacity of the system, not a description of the nominal function.
A few things that immediately jumped at me:
- Not all code is on GitHub and not all of it is public. Recently I see more and more code moving elsewhere: GitLab (both managed and self-hosted), Codeberg, Forgejo instances.
- Even the code that is on GH might live outside of personal profile. Many notable FLOSS projects have their own organisations on GH. People who produce a lot of that code have direct commit access and don’t keep forks on their profiles. You’re missing all of the most prolific developers here.
- Location field in a GH profile is full of jokes. Search for “space”, “internet”, “/dev/null”, etc.
- It picks top repos weirdly. I tried to find my profile. It picked one repo that is not in my profile and wasn’t there probably for a long time, and another that is a public archive and hasn’t been updated since 2017. Both are forks with minimal contributions on my part. I have pinned repos in my profile that are much fresher and, arguably, more relevant.
But the project looks sleek. Probably helpful in addition to Linkedin and whatever to uncover more potential candidates. I’m glad it works for you.
I mean, say I have some text file in ASCII. Do I then just pretend it’s raw wav and do FFT on it? I guess it can give me some useful information (like does it look like any particular natural language or is it just random; sometimes used in encrytion analysis of simple substitution cyphers). It feels surprising that revers FFT can get a coherent output after fiddling with the distribution.
[1]: https://hovrly.com/
It is true that black hats are going to focus on the remainder pretty much by definition because there’s no other choice. The rest is a problem and it needs a solution. But the fact that it exists is not a sound argument against choosing a memory-safe language.
Current solutions are not ideal but they still eliminate a huge portion of defects. Today we can avoid all the memory issues and we also can focus on the next biggest category of defects. If we’ll keep halving possible defects it won’t take long before software is near defect-free.