Why ixfx?

There are many ‘front-end’ frameworks, but these are typically meant for regular GUIs or document-based apps. They usually have idiosyncratic ways of structuring code, custom syntax, and elaborate build processes.

There are also several ‘creative coding’ sandboxes. These are better suited than front-end frameworks for experimentation in interactivity, but again tend to be their own little ecosystem removed from the web platform. They favour canvas-based visuals, and seem largely ignorant of the wider web platform or modern coding practices.

In both cases one spends a lot of time learning the particular framework and its way of doing things rather than the web platform itself. Learning Javascript as a language also gets lost in this. Having to ask “how do I do x in React?” or “how do I do x in P5.js?” is a sign the framework has eaten you.

Some design principles of ixfx are:

• No build process required
• No sandbox lock-in: follow web platform conventions so that patterns learned can be applied elsewhere
• Good type definitions and documentation for improved editor experience (in VS Code at least)
• Plain, immutable data over complicated objects
• Favour functional approaches over OOP, and try to stick to web programming conventions