Sonar helps you commit clean code every time. With over 300 unique rules to find JavaScript bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work. Learn more →
Joystick Alternatives
Similar projects and alternatives to joystick
-
-
-
Klotho
AWS Cloud-aware infrastructure-from-code toolbox [NEW]. Build cloud backends with Infrastructure-from-Code (IfC), a revolutionary technique for generating and updating cloud infrastructure. Try IfC with AWS and Klotho now (Now open-source)
-
-
-
-
-
-
Appwrite
Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!
-
-
-
Alpine.js
A rugged, minimal framework for composing JavaScript behavior in your markup.
-
next-runtime
The Next.js Runtime allows Next.js to run on Netlify with zero configuration (by netlify)
-
-
-
-
-
-
-
-
inertia
Inertia.js lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers.
-
InfluxDB
Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.
joystick reviews and mentions
-
Ask HN: What would be your stack if you are building an MVP today?
Joystick [1] using MongoDB as the primary database. Run a few instances on VPS and then a load balancer in front. This is how I run my site [2] following a massive amount of headaches and random downtime fighting w/ a k8s cluster. Zero downtime since I moved it over in October.
-
Alpine.js
How about plain HTML, CSS, and JavaScript? [1]
[1] https://github.com/cheatcode/joystick#writing-a-component
-
GitHub Is Sued, and We May Learn Something About Creative Commons Licensing
This may be of interest to others here. After reviewing the existing OSS licenses, I decided to write my own (SAUCR: Source Available Under Commercial Restriction—pronounced "saucer"). I'm still working on formalizing the details of it so others can use it, but if you're curious there's an example here [1].
tl;dr it gives specific permissions as to what derivative works are and are not permitted while making the source available for others. The key being: you can be as permissive or as limited as you want in how your code is used.
[1] https://github.com/cheatcode/joystick/blob/development/LICEN...
-
Ask HN: Why did Front end development explode in complexity?
> Is that complexity necessary or artificially inflated?
100% inflated and ego-based. How do I know? After years of struggling to understand the increasingly complex front-end space, I decided to build my own full-stack framework [1] to check my own opinions weren't left-field.
Here's the harsh truth: it doesn't need to be as complex as it's made out to be. Not even close. I can speculate as to why (ego, job security, etc) but ultimately the punchline is that all of the APIs and a lot of the code under the hood are pointless Rube Goldberg machines.
People don't want to hear that because they're invested emotionally in a lot of these tools, but from direct experience doing multi-year research and building of a framework, it's all a scam.
-
Using a Framework will harm the maintenance of your software
Unless the framework you're using treats maintainability as a feature [1], not an afterthought.
This is really just a long argument against bad framework design (which is fair), not frameworks.
[1] https://github.com/cheatcode/joystick#what-distinguishes-joy...
-
Ask HN: What happened to vanilla HTML/CSS/JS development?
You'd dig Joystick: https://github.com/cheatcode/joystick.
I designed it to be a natural transition from learning the fundamentals of HTML, CSS, and JavaScript into full-blown, component-driven UI development. Dirt simple API, no syntax tricks, no specialized knowledge. Just plain ol' HTML, CSS, and JavaScript organized into a system that's more productive than standalone files.
It works on its own in the browser or as a part of a full-stack framework.
-
JavaScript Hydration Is a Workaround, Not a Solution
The overhead is arbitrary if done properly. I did this in Joystick [1] and was shocked at how overcomplicated folks make it.
You're literally just saying "render to static HTML on the server, and on the client, have a way to render a root component to screen and attach event handlers." Without any serious thoughts about optimization (practically none yet), a no-cache refresh/mount takes 227ms to DOMContentLoaded and 696ms to a full load.
Here's the SSR I do:
https://github.com/cheatcode/joystick/blob/development/node/...
Here's the mount ("hydration"):
https://github.com/cheatcode/joystick/blob/development/ui/sr...
The only "magic" is that I embed the hydration logic into the built JS for the current page and it fires automatically on load (no need to add manual hydration code).
-
Unpopular opinoin GraphQL kinda sucks
Having spent several years working with GraphQL (using it in multiple projects and teaching it to others), I've found that in the majority of cases just doing a plain JSON-RPC API is preferable and far easier to reason about for all skill levels.
When I built Joystick [1], this is why I implemented the API system [2] as a JSON-RPC model, but stole the idea of validating inputs (optionally) and then on the client, optionally specifying tailored output (also optional—like how you can request specific fields back in GraphQL but instead of a custom query language, just pass an array of paths like ['customers.creditCard.expirationMonth', 'customers.creditCard.expirationYear'] for the specific data you want returned.
What I learned implementing that is that the typing/querying for specific fields ideas is brilliant, but much better when it's flexible (i.e., I want it sometimes but not all the time).
-
Build Your Own Web Framework
For JS developers trying to achieve what's outlined in the linked article: https://github.com/cheatcode/joystick
Very thin abstractions over HTML, CSS, JavaScript and Node.js that don't separate you from what you're trying to ship to the browser: HTML, CSS, and JavaScript. No "magic" or "hacks," just a bit of plumbing to make you more productive.
For people concerned about the growing complexity of all this stuff, I'd appreciate you taking my approach for a spin: https://github.com/cheatcode/joystick. It's intentionally boring and simplistic.
Good ol' fashioned HTML, CSS, and full-stack JavaScript (Node.js on the back-end).
-
A note from our sponsor - Sonar
www.sonarsource.com | 28 Jan 2023
Stats
cheatcode/joystick is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.