Hyperapp: Remove Router from core?

[Facel3ss1]

Hello!
Just looking through HyperApp and I am very impressed! 👍 I am just wondering why Router is in the core package that everyone downloads because it's just a plugin. Wouldn't it be better to separate Router from core and put Router and similar plugins elsewhere? It's just a question, as I was wondering about community plugins/extensibility. E.g. The core hyperapp repo is just h and app and Router and other similar plugins could be in other repos and the user could choose which one they install alongside hyperapp.

npm install hyperapp
npm install hyperapp-router
...

What do you think?

[FlorianWendelborn]

@Facel3ss1 we thought about this a lot. Main reason is primarily that this doesn't have any major disadvantages, while it maintains the "one system" aspect of hyperapp.

Look at react, there are 20 different routers, 20 different state manangement libraries and they don't integrate nicely with each other. Hyperapp (while not forcing you to use our router) gets rid of most of these problems by providing it out-of-the-box.

[lukejacksonn]

humm, I'm still torn on this one.. there are pros and cons to abstraction imho.

Reasons for abstraction:

• Makes it very clear that it is in fact just a plugin, not core (blurred lines atm)
• Makes it easier to focus on and develop in parallel with core (not blocked by core issues/PRs)
• Makes it easier for others to fork/copy/experiment/adapt to suit their own needs
• Makes for less of a locked in feel (preempting _why you ship me a router I don't want_ comments)
• Makes for a good plugin example (encouraging people to build/install/import plugins is good?)
• Makes for a smaller library overall (there is the tree shaking argument but not everyone does)

Reasons not to abstract:

• Makes for a more simple and out-of-the box solution for multipage apps
• Makes for one less npm install or <script> tag include
• Makes for one centralized place for hyperapp issues/PRs

Anyone got anything to add to either of these lists?

As I see it, nearly the best way to handle it would be to create hyperapp/router repo. That way it is made very clear that this is the recommended general purpose router _but_ we understand that frontend routing is non trivial and encourage adaptation and feedback. Although it pains me so to not ship frontend routing with core.. core does exactly as advertised without the router.

¯_(ツ)_/¯

[FlorianWendelborn]

@lukejacksonn You dropped something: \

[jorgebucaran]

Hi @Facel3ss1 👋

Good question! Now that the router is just a regular plugin, it would be possible to distribute it as a separate package. I am not against the idea. Maybe after #172 and #174.

Leaving this open to encourage more discussion.

[Facel3ss1]

Hello everyone!
Thanks for your thoughts, they are quite interesting...

@dodekeract I do get how react has tons of routers/state management etc but a good side is that the user has some choice over what plugin they want. Sure, 20 plugins doing the same thing is overkill but a few plugins offering variations on the same functionality will give the user some freedom. E.g Vue.js has Vuex, their 'official' Vue Flux library which they have documented and recommended to everyone. But there are also a few Redux bindings for Vue as well if you like Redux.

@lukejacksonn I agree with the points you've made above, but a user could also just use a module bundler like Webpack or Rollup to bundle the core and the Router and have one <script> tag that wouldn't be much bigger than the bundle we have on unpkg.com and npm now. Other plugins could be in the tag as well.

I think removing Router would encourage more plugin development in the community. It would be the first 'official' plugin which would inspire people to make plugins. As far as I can tell, there aren't any hyperapp plugins in the wild (Let me know if I'm wrong)? Also, I think the attraction to hyperapp plugins is that once you know the basics of hyperapp, you can make a plugin. This is extremely powerful for new users who can just read the docs and then make a plugin that contributes towards the community.

Those are just my ideas, Its just I am really excited about the idea of a hyperapp ecosystem with tons of cool plugins! 😀

[FlorianWendelborn]

@Facel3ss1 The issue with React isn't that there is freedom. It's that there is too many different things and they don't interact nicely with each other. To replicate hyperapp you'd basically need react, react-router, redux, react-redux and react-redux-router. Good luck trying to actually set that up so that it works perfectly and so that your routing state is inside your normal state.

Hyperapp solving all of this in a straight-forward matter without 300 KiB bundle sizes is the reason why I'm using it for some projects. It's like Apple vs Linux - customization is nice, but sometimes you want something that "just works".

[Facel3ss1]

@dodekeract I agree with that. We wouldn't want to have tons of plugins that do similar things like React does. How would the hyperapp community make sure this doesn't happen? Part of me wonders whether the amount of React plugins is a reflection of React's massive popularity? Also the user can make the distinction of whether they use some-unneeded-plugin in their project.

[jorgebucaran]

This is a tough decision. One part of me wants the router out, but maybe the time is still not right?

[Facel3ss1]

Yes, Maybe. Thinking about this more, I think the reason why I opened this is because of the lack of community plugins in the wild, not because Router isn't needed in core. I really like the ideas behind hyperapp and even if we do keep Router in core hyperapp will still be tiny! 😄 I will keep this issue open anyway because this is still a valid option imo, but we also need to think about growing the hyperapp ecosystem and community. I think the website (#146) could be a good way to start this. I honestly don't mind anymore about whether Router does stay in core, but I think the decision should be made with the community in mind. What are your thoughts on this?

[lukejacksonn]

Just an update here.. this exists now https://www.npmjs.com/package/hyperapp-router thanks to @jbucaran nabbing the namespace.

There is probably no need to use it yet.. unless you are treeshaking and really want to do.

import { h, app } from 'hyperapp'
import { Router } from 'hyperapp-router' 

[jorgebucaran]

@lukejacksonn Just to be correct, you can already do tree-shaking the way things are. That's why we're using import/export! 👋

[lukejacksonn]

Indeed. I was just trying to emphasize that without tree shaking, this is is counter productive!

[lukejacksonn]

Updated https://www.npmjs.com/package/hyperapp-router to support 0.9.3

[jcpst]

Perhaps there could be a 'minimal core' without the router, and still distribute the main hyperapp package with the router. Similar to how vuejs ships a version with the runtime, and another without the runtime.

[jorgebucaran]

@jcpst Something like this?

For people using npm:

npm i @hyperapp/router

For those grabbing via the CDN:

<script src="https://unpkg.com/hyperapp" ></script>

or

<script src="https://unpkg.com/hyperapp.core" ></script>

[jorgebucaran]

Or we could just wait until 1.0 and then just remove the router and be done with it.

We'll take a bit of damage, it's always cool to say hyperapp is 1 KB and that includes the router, but we had it coming.

[lukejacksonn]

Or we could just wait until 1.0 and then just remove the router and be done with it.

You mean it would be removed in 1.0.0 or removed after 1.0.0 has landed? The latter makes not much sense.

it's always cool to say hyperapp is 1 KB and that includes the router

Less cool when that statement is quite far from true.. like you say, that was coming

[jorgebucaran]

I mean that when we release 1.0 the router won't be in the bundle. I am just speculating btw.

[jcpst]

@jbucaran yep, something like that.

[jorgebucaran]

266