Why Joystick exists and the attitude toward how, when, and why it evolves.

Much of what exists in the JavaScript ecosystem can best be described as attempts to solve problems in an overly-clever way. Unfortunately, more often than not, the desire to implement the most clever solution—typically unstated but visible to the trained eye—leads to convoluted tools and excessive dependence on third-parties.

In direct defiance to lessons learned by other languages and frameworks, JavaScript developers attempt to stand on their own, forever reinventing the wheel, only to come up short. This leads to unnecessary compromises and ultimately, messes, that give the language and ecosystem a bad name.

Joystick seeks to fix this. It's goals are humble:

  1. Make it easy for a developer to go from learning the basics of web development—HTML, CSS, and JavaScript—to building full-stack applications.

  2. Reduce the complexity and fragility of shipping an app with JavaScript.

  3. Offer a technical balance between the ability to move fast early via convenience and the long-term desire for a stable, easy-to-maintain app via sound architecture decisions.

To achieve this, Joystick takes a radical approach:

Be hyper-opinionated

In order to keep Joystick stable between releases, how and why things are done is not left up to discussion. Decisions are made by its creator, backed by careful thought and practical experience over time.

Joystick should be a good fit for most (if not all) web projects, but it's approach isn't going to be for everyone (and that's okay).

Learn from experience

Make wise use of the lessons and best practices learned from "grey beard" tech, preferring those approaches as a default (e.g., don't jam routes into the client—just define them on the server where they belong). Don't ignore the new stuff, but be skeptical of its efficacy—a demo is worth a thousand words.

Limit third-party dependencies

DIY should be the default approach, if at all possible. Don't add a package when we can just implement its functionality ourselves. Make it a goal to reduce dependencies to zero over time.

Keep the team small

Most open source work suffers from a problem of mediocrity because it defaults to making decisions by committee. Joystick is the opposite, with all final decisions being made by its creator. Outside opinions are welcome and will be considered, but pull requests will be few and far between.

Any formation of a core team (if at all) will be slow and hyper-deliberate, with team members being selected for their skill level and dedication to Joystick's philosophy and vision.

Keep APIs backwards compatible

The only changes to the framework's APIs between versions should be fixes and new features. Anything you've built in the past should just work with a new version. No rug pulls. No excuses. The ideal is to have only one major version, with all subsequent versions being minor or patch releases.

Avoid the open source rat race

Chasing Github stars and constantly pushing new code without cause is frowned upon. Do work when it makes sense and when the ideas being implemented have been tested and given the appropriate amount of consideration. Make haste slowly.

Ignore everybody

Focus on delivering a great developer experience so developers can deliver a great user experience. Compete with your current version, not the insecure "competition" or the know-it-all naysayers.

Waste zero time arguing about or defending decisions already made. If the current solution works (and well), any time spent arguing about how it was done is wasted energy that could be put back into the framework. Only genuine, constructive feedback is welcome. Everyone else should be shown the door.

The big picture

Ultimately, Joystick isn't a fashion statement—it's a tool. In order to ensure that tool remains useful, the above philosophy is deployed. If you don't like it, it's best to move along and use something else.