Not yet, I'd like to organize something for the 1.0 release. Honestly, I view Joystick as a rival to, not a competitor of the other frameworks. What's unique about it is it's philosophy and approach.
The other frameworks take a flawed approach of trying to do as much as possible on the client and ignore the server (unless they can't which leads to wishy-washy approaches like tossing basic stuff to a third-party service or hacks which add complexity). On the code side, there's an obsession with injecting unnecessary abstractions and terminology which only serve to confuse people and ultimately, create a class of developer who doesn't understand how the web works (terms like "serverless" are clever marketing, but mislead developers into thinking they "got it" when they most certainly do not). I view this as a colossal mistake that threatens the long-term stability of the industry.
In contrast, Joystick is all about simplicity and developer experience and takes a page from the Rails/Django world. You start up a server (via Express), that server has some routes, when a URL matches a route, that route fetches some data, passes it to a component, and renders some HTML back to the browser. That's it. A component is written using plain HTML, CSS, and JavaScript with an API that a beginner can understand immediately after learning the fundamentals of those languages. To make it more valuable, I take a "batteries-included" approach, adding in all of the basic functionality you need to build an app: wiring of databases to the app, user accounts, uploads, i18n, etc. with more on the way (e.g., I'm adding in support for queues atm).
Joystick is for you if you want an unexciting stack to build on that just works and continues to work in perpetuity (after 1.0, the core APIs will be frozen with the only changes being under-the-hood performance/security and additional, optional functionality). This means: the app you build in Joystick today will require the exact same knowledge to maintain 10 years from now. No deprecated APIs or rug pulls in terms of opinions about how to build stuff. My running joke is that "Joystick is the Honda Civic of JavaScript frameworks."
Edit: some tutorials if you want to get the gist of how Joystick thinks about stuff...
The other frameworks take a flawed approach of trying to do as much as possible on the client and ignore the server (unless they can't which leads to wishy-washy approaches like tossing basic stuff to a third-party service or hacks which add complexity). On the code side, there's an obsession with injecting unnecessary abstractions and terminology which only serve to confuse people and ultimately, create a class of developer who doesn't understand how the web works (terms like "serverless" are clever marketing, but mislead developers into thinking they "got it" when they most certainly do not). I view this as a colossal mistake that threatens the long-term stability of the industry.
In contrast, Joystick is all about simplicity and developer experience and takes a page from the Rails/Django world. You start up a server (via Express), that server has some routes, when a URL matches a route, that route fetches some data, passes it to a component, and renders some HTML back to the browser. That's it. A component is written using plain HTML, CSS, and JavaScript with an API that a beginner can understand immediately after learning the fundamentals of those languages. To make it more valuable, I take a "batteries-included" approach, adding in all of the basic functionality you need to build an app: wiring of databases to the app, user accounts, uploads, i18n, etc. with more on the way (e.g., I'm adding in support for queues atm).
Joystick is for you if you want an unexciting stack to build on that just works and continues to work in perpetuity (after 1.0, the core APIs will be frozen with the only changes being under-the-hood performance/security and additional, optional functionality). This means: the app you build in Joystick today will require the exact same knowledge to maintain 10 years from now. No deprecated APIs or rug pulls in terms of opinions about how to build stuff. My running joke is that "Joystick is the Honda Civic of JavaScript frameworks."
Edit: some tutorials if you want to get the gist of how Joystick thinks about stuff...
Building and Rendering Your First Joystick Component - https://cheatcode.co/tutorials/building-and-rendering-your-f...
How to Implement an API Using Getters and Setters in Joystick - https://cheatcode.co/tutorials/how-to-implement-an-api-using...
How to Fetch and Render Data in Joystick Components - https://cheatcode.co/tutorials/how-to-fetch-and-render-data-...