You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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:
constserver=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.
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: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?1.1
withwebsockets
; the public interface should remain the same though as plugins won't be released in1.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.
The text was updated successfully, but these errors were encountered: