The web needs a higher level of abstraction: Meet JUX

- IF YOU ARE CURRENTLY USING THIS PACKAGE COOL! But it is still a little fragile. 
- We are working on opening our repo to public and working on our documentation pages. 
+ Stay tuned! For now, you will see our roadmap here!

• [X] Router

  • [ ] Cross Page Store.
  • [ ] Distributable Bundle (Static Sites)
  • [ ] Tree Shake/Efficiencies.

• [ ] Data

  • [ ] Drivers: File, S3, Database.
  • [ ] const d = jux.data('id',{});
  • [ ] d.driver(file|s3|database)
  • [ ] d.items([] | juxitem)
  • [ ] d.store(callback)

• [X] Layouts (100% done.)

  • [ ] Authoring Layout Pages - docs

  • [ ] Authoring Application Pages - docs

  • [ ] Authoring Custom Components - docs

  • [ ] Render Dependency Tree

    Idea here is, one element may be a predicate for another. Will need promises. **predicting problems with slow-loading components that depend on containers from other components. May to to separate concerns with container "building" vs. content addition OR use async processes (promises).

• [X] Reactivity (90% done.)

• [ ] Client Components (99% of what would be needed.)

  • [X] Charts
  • [X] Poor Intellisense support? Could be this issue. - fixed.
  • [ ] Api Wrapper
  • [X] Params/Active State for Menu/Nav matching - built in.
  • [ ] CDN Bundle (import CDN/'state', 'jux' from cdn.)
  • [ ] Icon

• [ ] Quickstart Boilerplates (20% done,notion.jux)

  • [ ] Mobile Nav
  • [ ] npx jux present notion|default etc..

• [ ] Server side components (api and database)

• [ ] Quick deploy option

JUX Authoring UI's in pure javascript.

Build beautiful, reactive UI's using only javascript. No markup required. A clean authorship layer capable of being taught to non-developers, strong enough to be used by real developers.

jux challenges the idea that markup based systems are the most efficient way to author web applications.

AI friendly - use less tokens!

- Markup is expensive! 
Have you ever considered the energy requirements to ship chunks of HTML markup like Vue or React components?

• [ ] Build a code calculator (token calculator)

As a user, I want to be efficient with the LLM's. I want my code to be clean. I want to avoid repeating myself. I ultimately, want to write less code. Less code is better code.

Ecosystem friendly (NPM)

Because it is just javascript, .jux files work with any npm package you want to throw at it with standard ESM syntax.

GETTING STARTED

# New project
mkdir my-project
cd my-project
npm init -y
npm install juxscript

# Initialize (creates jux/ directory)
npx jux init

# Builds jux-dist and serves index.jux
npx jux serve

install npm i juxscript

Your IDE must be setup to read .jux files as .js files. In VS Code, this is do in the .vscode/settings.json. Here is an example.

//.vscode/settings.json
{
  "files.associations": {
    "*.jux": "javascript",
    "*.juxt": "javascript"
  },
  "javascript.validate.enable": false,
  "[javascript]": {
    "editor.defaultFormatter": "vscode.typescript-language-features"
  }
}

building and serving the examples project directory. npm run dev

building only (the examples project directory) npm run build:examples

Authoring in Jux

1. Build a Layout Page you can reuse. Check out the presets, they speed this process up. Just modify them with your goals, such as logo, menu options, nav etc.
2. Build your Pages Just get to work, using the jux component library to build most of what you need, filling in any details with javascript logically arranged the way you want. Think, authoring SFC but with only the composition layer.
3. Test it out! Jux comes with a watcher system built in, so you can see your edits to .jux files live.

GOAL: Eliminating the Markup System of building UI's.

HTML markup is the equivalent of still writing in C ro C++ despite the availability of more functional levels of abstraction like python. To remove the requirement for markup, jux must address the utility of markup.

Layouts

Grid System

• [ ] Laying out JUX files in a rational way.

Develop a higher-level layout javascript grammar for building layouts and palettes of style using ZERO markup.

• [ ] A Partial View Strategy

As a dev I may need to load partial pages/components into other pages. This should avoid noisy wrappers and ideally be just javascript imports of jux objects.

Components

We have constructed the most helpful components for building 99% of core business/saas web applications, that present beautifully on the page and are created purely with javascript.

https://www.shadcn-vue.com/docs/components Run time slots.. Example, table.slot(columnName -> object);

Backend

Routing & Views

• [X] Subviews architecture
  • [X] Nested routing support
  • [X] View composition
  • [X] Layout system
• [X] User views
  • [X] profile.jux - User

Server Docs/Documentation.

• [ ] Should jux ship with a server at all? Or merely for demos.

What is the server even doing? Is it merely a matter of understanding that JUX builder/compilation gives you a mirror of how you setup your project. It can be as flat or deep as you would like.

At this point, we are speaking almost 100% towards UI interfaces. Servers should be 'loosely coupled.'. This allows for a standard.

In the future, we could introduce an auto api feature, similar to next.js api heuristic for folders and files.

[ @jesseallenrxtrail -> Discuss. ]

Chore: Commit to building more in package directory.

We can experiment with our example project, using a simple express server, running. What third-party integration do we need?

• [ ] Chore: Cleanup our machinery/server.js to separate concerns and build our actual endpoints we need to build software here.

Alternative Chore: package this for npmjs.org, combine with our existing project, re-author frontend in jux.

• [ ] Alternative Chore: package this for npmjs.org and ship it.
• [ ] Start a brand new project.
• [ ] Build the server aspect in flask (already done).
• [ ] Author the frontend in jux instead of vue.

This may require us to move our 'complilation error module', lib/components/error-handler.ts to the front-end for display without a 'server call' at all?

• [ ] Chore for this? This takes more analysis, discussion.

How and what will we wire for backend and what jux components will we support for working with backends.

• [ X ] SQL Database (query component)
  • [ ] Chore: This is currently supported. Needs revisiting and testing

API's

• [ ] Base payload creater and consumer as a jux component. jux.api??

Jux Configs

Jux configs.. jux.config.js what should this entail? Currently it looks like this:

• [ ] Chore: WHAT IS ACTUALLY BEING USED AND WHERE?

export default {
  projectRoot: __dirname,
  distDir: path.join(__dirname, 'dist'),
  build: {
    minify: false
  },
  
  database: {
    // Default connection
    default: 'sqlite',
    
    // Named connections
    connections: {
      sqlite: {
        driver: 'sqlite',
        database: path.join(__dirname, 'db', 'jux.db')
      },
      ... // props to feed drivers for mysql/postgres
    }
  },
  
  server: {
    port: process.env.PORT || 3000,
    host: process.env.HOST || 'localhost'
  },
  
};

As a user, I will want to control where JUX sends queries. As a user, I may want to specify a default proxy for backend. I may also want to specify, explicitly, URL's to hit other service endpoints

• [ ] Escape hatch (backend API proxy vs default)
  • [ ] As a user, I may want to run my own server for backend requests/proxies.
  • [ ] As a user, I may want to hit multiple endpoints in the same JUX file.

CORE

STATIC SERVING (your local file system, s3 bucket static sites, any host that allows serving etc...)

Should JUX function, as a 100% client side app (STATIC WEBSITES)

• [ ] Chore: Discovery... I think the answer is yes. I think what might be missing is bundling.

REACTIVITY LAYER.

Goal for Reactivity

We are shooting for better than nasty amounts of javascript, not as sophisticated as vue/react.

As a user, I want changes in state of my objects to be consumable by other objects on the page so they can paint changes and interface with each other seamlessly.

• [ ] Build a basic v-model strategy in pure javascript. Different than jquery, javascript etc.
• [ ] Build standard eventing systems, listeners and emitters on components where they make sense. `

ROADMAP

KEY UI PAGES

• [ ] JWT Authentication (authJWT) (demo examples only)
  • [ ] Token generation (demo examples only)
  • [ ] Token validation middleware (demo examples only)
  • [ ] Refresh token logic (demo examples only)
• [ ] Login system PAGES! Ships with vendor assets like lib files/layouts etc.
  • [ ] Login
  • [ ] Logout
  • [ ] Profile

Additional Features

• [ ] API documentation
• [ ] Testing setup

LAYOUT NOTES...

Jux Standard Layout Regions

• [ ] CHORE : REVISIT! I think maybe we ship with our figma, notion, default etc. But then document how to build and reuse a .jux page as a layout using the jux.layout class.

Start with a layout page

You can build a simple one, or copy and use one of the Jux presets.

npx jux preset notion|default|figma|slack|other