Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direction and 1.0.0 #1

Closed
franciscop opened this issue Jan 26, 2017 · 2 comments
Closed

Direction and 1.0.0 #1

franciscop opened this issue Jan 26, 2017 · 2 comments
Milestone

Comments

@franciscop
Copy link
Owner

franciscop commented Jan 26, 2017

I was going to release the first beta 1.0.0 soon but I've decided to step back and rework and improve some areas. Since 1.0.0 is a big step and I want it to be the foundation of what is to come for the foreseeable future*, it should at least be forward-looking:

  • Future-proof middleware. I just like (not love) the way Express middleware works, and I think with Promises a lot more could be accomplished, while I find Koa's approach too complex for server's goals. The specifics will be detailed later, but the fingerprint would be basically a (context) => new Promise() or a (context) => { return; }. Note: should they still be called middleware?
  • Past-proof middleware: provide an easy way to include all the middleware that exists today.
  • Router: goes along with the previous point, making it compatible.
  • Plugins: nothing at all released publicly, however the router can be using them to iron-out the edges. Or perhaps just wait until 1.1 with websockets; the public interface should remain the same though as plugins won't be released in 1.0.

That is for finishing the alpha versions. Then the betas will focus on testing, documentation and website.

What do you think? Anything to be improved? Your opinion is wanted here.

*I think that for any project aimed to be big-ish, you should try to make it right on the 1.0.0. See python 3 mess or search for tutorials of Express where you'll be flooded with V3 tutorials instead of V4 (which changes a lot). For this I think a minimal, extensible and well tested and documented base is crucial. Of course I can still make a big f**k-up and break something big-time meaning a major version bump, but I'm trying to plan it properly so that doesn't happen even if it means a few more weeks of development.

@franciscop franciscop changed the title Direction Direction and 1.0.0 Jan 27, 2017
@franciscop franciscop added this to the 1.0.0 milestone Jan 27, 2017
@futurist
Copy link

How this project's direction compared to hapijs ? Which also is declarative style, similar to this lib.

@franciscop
Copy link
Owner Author

franciscop commented Jul 12, 2017

@futurist I would say from a quick glance that syntax brevity and defaults are two of the main differences. While some people like it more (it does look neat!) with everything explicitly expressed, I prefer to have defaults and then the option to modify those. The same 19 lines example from the homepage could be something like this:

const server = require('server');
const { get } = server.router;
server(get('/hello', ctx => 'hello world')).then(ctx => {
  console.log(`server running at http://localhost:${ctx.options.port}`);
});

Not sure about Hapi, but including Express' middleware into server is also trivial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants