Consider extract the routing code from core

Hi @jbucaran,

I felt in love with hyperapp because is almost the perfect essence of the Elm application architecture. All the code is clean, simple and functional 👍 The only part that looks a little bit hacky is the routing code. But there are other reasons to extract it:

• Not all applications need routing. That would help to reduce the size of the core.
• Even if they use routing, is not always to change the view.

I don’t know the best solution (that’s why I’m opening this issue), but I think the API could be something like:

import { html, routes, app } from 'hyperapp'

const model = {}
const view = routes({
     "*": (model, msg) => {},
     "/": (model, msg) => {},
     "/:slug": (model, msg, params) => {}
    }
})

app({ model, view })

The new routes function should create a view (function) that selects the route proper view function using the browser history, and previously it registers the required event handlers, probably using the lifecycle events (more or less, the same code now it’s inside the app.js file)

What do you think?

Anyway, congrats for this nice library

[jorgebucaran]

@danigb You still want to get rid of the router?

Should we get rid of the router?

Please 👍 👎 .

[tunnckoCore]

But yea, in anyway it should be in the core. Because the purpose of the hyperapp is to be kinda “complete” solution for building apps.