In Node, you would commonly reach for the builtin core "node:crypto" module to run cryptographic functionality like this. I wondered why that wasn't used here, but bcryptjs was. After digging into it a little, node doesn't ship with core support for bcrypt, because it's not supported by OpenSSL.
The node crypto module is essentially an API that offloads crypto work to OpenSSL. If we dig into OpenSSL, they won't support bcrypt. Bcrypt won't be supported by OpenSSL because of reasons to do with standardisation. https://github.com/openssl/openssl/issues/5323
Since bcrypt is not a "standardised" algorithm, it makes me wonder why Okta used it, at all?
I remember in uni studying cryptography for application development and even then, back in 2013, it was used and recommended, but not standardised. it says a lot that 12 years on it still hasn't been.
In my final semester of uni, we did an "AI" module, which involved using prolog. I didn't really grok it until the night before the final exam. Felt like I had a bit of a beautiful mind moment with all the possibilities opening up to me when it clicked.
This was my only 100% final exam module with no continuous assessment/midterm papers or exams/projects to pick up slack if I failed, so I was nervous going into it. Kinda felt like my whole degree weighed on it. That night before, I just *got it* and it made all the difference in the world. I got how powerful it is, and why to use it.
Do you, or anyone else in the team or community, have a good resource you would recommend to people complaining about "too much boilerplate" in redux code? It is likely the most common complaint I see, that I understand to come from a place of people not understanding it this a tool best used for scaling and/or already big projects. Whenever I have worked with Redux in a large project, that "boilerplate" is minimal and the benefits obvious.
hooks and the context api are great for small projects. Check out the hooks comparison section in the linked article to understand how it might fit your app. It references other good resources, too.
This attitude is why silicon valley is well on its way to becoming the villain in the narrative of our progress. It is a place dedicated to redefining the world we live in. Valley companies can, and regularly do, redefine how companies work and make money. Sometimes they need to be the ones to bite the bullet and lose some of their yearly profits by spending it on making this transition buttery smooth.
Without them trying to make this effort, and the common man fearing the gaze of the innovation beast, governments will have to act - and not necessarily by transition those affected into positions where they can still be secure, but by stifiling the innovation by actively targeting the catalysts of these changes with laws and regulations and hoops upon hoops to jump through.
The good news is, for the average user, unikernels are pretty much guaranteed to be mainstream and streamlined at some stage in the future, thanks to Docker acquiring Unikernel Systems, and the awesome work that the like of deferpanic are doing. :D
I did some work with 'old' famo.us, and boy was it slow going. Then again, at the time I was relatively new to javascipt, so understanding scope, callbacks and such was hard at the time.
Now its popping up again. Time to take it for another run. The problem in the past was a small/inactive/detached community imo, if there was an active community behind it, it would be amazing.
Also, the famo.us devs seem to expect a lot of community stuff to be happening in or around their offices, which is unfair to us overseas guys who can't go to a famo.us demo day in their office.
That is so cool. There's a great demo of orbitals and the like that can be picked up from this. I would have loved if a physics teacher showed me something like this when I was in school.
The node crypto module is essentially an API that offloads crypto work to OpenSSL. If we dig into OpenSSL, they won't support bcrypt. Bcrypt won't be supported by OpenSSL because of reasons to do with standardisation. https://github.com/openssl/openssl/issues/5323
Since bcrypt is not a "standardised" algorithm, it makes me wonder why Okta used it, at all?
I remember in uni studying cryptography for application development and even then, back in 2013, it was used and recommended, but not standardised. it says a lot that 12 years on it still hasn't been.