auth0-spa-js VS fastify-dx

Your message feels disingenuous and not in good-faith.

Auth0 clearly advises against the localStorage option which is most similar to Stytch's:

> _Important:_ This feature will allow the caching of data _such as ID and access tokens_ to be stored in local storage. Exercising this option changes the security characteristics of your application and _should not be used lightly._ Extra care should be taken to mitigate against XSS attacks and minimize the risk of tokens being stolen from local storage.

This is from the readme of the github you linked:

https://github.com/auth0/auth0-spa-js/tree/0de9c6bf61d37fc21...

And since their other client-only solutions have major UX challenges (as you highlight), I expect most Auth0 users have landed on the secure option.

This is very different from Stytch - which as far as I can tell - doesn't disclose or acknowledge the risk, and instead willingly puts developers at increased risk. Throughout this thread, you've been dismissive of the risk despite security organizations clearly indicating that HttpOnly is best-practice.

You've found a legitimate comparison in Firebase, but for me, you've taken several steps too far trying to compare to Auth0.

Auth0 provides the auth0-spa-js package which offers two ways to authenticate users:

Therefore, I have transformed the library [@auth0/auth0-spa-js](https://github.com/auth0/auth0-spa-js), which is another official Auth0 client library, to have an authentication hook and methods that can be accessible outside the components.

auth0-spa-js must run on a secure origin. See https://github.com/auth0/auth0-spa-js/blob/master/FAQ.md#why-do-i-get-auth0-spa-js-must-run-on-a-secure-origin for more information. 32 | it("renders a login button", () => { 33 | > 34 | const { getByText } = render( | ^ 35 | 36 | 37 |

Fastify DX is in the pipeline. It brings Vite-powered front end solutions in Svelte, React and other frameworks to Fastify and is already in alpha. This will let you create full stack apps using Fastify together with your preferred frontend.

The table layout and example formatting of "The Universal Route Module API Specification" is quite good: https://github.com/fastify/fastify-dx/blob/main/URMA.md

SolidJS ranked #1 in the 2021 "State of JS Front-End Frameworks", so we wanted to see what the fuzz is about and give it a proper chance with a side project. We started with a simple Single Page Application (SPA) and a few components but wanted to add data with GraphQL. For GraphQL we needed some sort of authentication, to identify users. This quickly turned more complex day by day. The biggest pitfalls and challenges were understanding Reactivity in SolidJS and the use of context providers. Last but not least, we wanted to add some server-side rendering capabilities, which lead to a three week rabbit hole of reading SolidJS code, Fastify Vite and lots of trial and error. Fortunately, Jonas Galvez was already working on Fastify DX a new full stack framework based on Fastify and Vite, where he added support for SolidJS as well. A nice side effect was that we not only have server-side rendering, but also async rendering, streaming web components/html streaming1 available, which is pretty awesome. As most of this is new and a lot of those technologies are barely documented past "Hello World" or "Todo List", we decided to extract the most important/difficult parts of our project into this "Real World Application with SolidJS and Fastify DX".

Show HN: Fastify DX, a full stack framework based on Fastify and Vite\ (0 comments)