12 ms·

Show HN: Server.js – A modern Express alternative

295 points by franciscop 9y ago

ekryski 9y ago
I think a lot of people still haven't seen https://feathersjs.com/ https://feathersjs.com/. Has been around for a while and offers all of this and more AND is drop in replacement for Express.
franciscop 9y ago
It is built on top of express to keep all of the good things, but it adds basic middleware and some more advanced functionality like websockets through socket.io and security through helmet by default. It is designed to work perfectly with Promises and async/await, the new ES7 features that makes asynchronous code awesome. Also, I put a lot of work into making the documentation extensive and clear and I'll keep working on that for the future while preparing for the 1.1. Edit, release notes: https://medium.com/server-for-node-js/server-js-1-0-released-12a419ab187a https://medium.com/server-for-node-js/server-js-1-0-released...
- picardo 9y ago
  I like the design of the API, but I don't understand what you mean by "built on top of express?" I see you have express in a plugin module, but I'm not sure how it's being used.
  - franciscop 9y ago
    It is being used underneath to connect all of the moving parts.
  - niix 9y ago
    In the package.json you can see its a dependency of the project. So it seems like its more of an abstraction of Express than an alternative.
- josephorjoe 9y ago
  Looks interesting -- will check it out. I've definitely found the batteries-not-included nature of express to be annoying at times.
- josephg 9y ago
  Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide? http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets
  - Can_Not 9y ago
    Socket.io adds rooms/namespaces as a feature, automatically reconnects with effort to not have all clients reconnect at the same time, covers compatibility edgecases, heartbeat, timeouts, custom events, multiple transport methods, server side implementations in multiple languages, supports non-ws fallback for reasons that might not be browser compatibility, and a good API.
  - aphextron 9y ago
    >Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide? The real reasoning is browser support. Socket.io supports automatic fallback to AJAX long polling if the client doesn't support websockets. It also standardizes the interface across clients. It's essentially to websockets what jQuery is to the DOM.
  - always_good 9y ago
    For one, it has message_id ackbacks so that you can have a request/response rpc style system. A basic feature for any websocket-heavy application. socket.send('login', [uname, pass], (err) => ...) And there are socket-io clients for most languages that can interop with a socket-io server, once again supporting message_id callbacks. Reconciling my own message_id + reconnect buffer system is not something I want to build on the client + server every time I build an application. People talk shit about socket.io and then never recommend an alternative that implements this fundamental feature. Without message_ids, I get flashbacks to working with IMAP.
drinchev 9y ago
> Note: this option can be ignored and server.js will work with both .pug and .hbs (Handlebars) file types. [1] : https://github.com/franciscop/server/blob/master/package.json https://github.com/franciscop/server/blob/master/package.jso... I think around express 3 the guys decided to go with a modular approach and decouple the server from any of those heavy ( render ) libraries, as well as body-parser ( once it was core module in express itself ). My really friendly feedback is that I think express carries so much experience that it will be really hard to replace it with something so monolithic. I use express for REST APIs as well as full web app, where I need no render engine and having this installed on my server is an overkill. Best approach I would think of is having someone rewrite express from scratch and call it express 5, while keeping the same balance of core and extra functionality, as well as new async / promise goodies.
- kosinus 9y ago
  Basically what I find Koa does for me: http://koajs.com http://koajs.com
  - vidar 9y ago
    I am in the Koa boat as well, does Express have anything that Koa does not? (not trying to start a framework flamewar, honestly!)
    - drinchev 9y ago
      Koa was created by the very same person as Express itself [https://github.com/tj https://github.com/tj] TJ Holowaychuk. The initial idea is to do the next level express framework using back-then generator functions. What is missing ( for me ) is the smaller community and popularity. So it makes it tough to argue about the business impact between choosing koa over express. Honestly, being a nodeJS freelancer for the last decade there was not a single project, where koa was in use. Mostly I've seen express or sailsjs [http://sailsjs.com http://sailsjs.com] which is quite a full-blown MVC Rails style solution.
    - franciscop 9y ago
myf01d 9y ago
> npm install server How could the package name "server" be available all these years :D?
- XCSme 9y ago
  Asking the real questions! I wonder if deleted package names are made available again. It makes sense that they did, but it's also a security issue, if one package is removed an attacker could add a new package with the same name and with a malicious functionality.
  - alvis 9y ago
    In theory, no. Unless you have the magic power like what Laurie Voss have. Remember he saved the world by resurrecting left-pad[1]? [1] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
- alvis 9y ago
  Apparently the author registered the package name back in 2012. From `nam info server`, it shows that the initial development started on 9 Aug 2012, but stopped very soon on the same day. Then the author picked up the work again last year.
- franciscop 9y ago
  It was not available! But it was abandoned and without any content, so after talking with npm for this specific scenario they decided to give it to me. I wrote an article called "Getting a great npm name": https://medium.com/server-for-node-js/getting-a-great-npm-name-b0b2b27a0e1b https://medium.com/server-for-node-js/getting-a-great-npm-na...
TheAceOfHearts 9y ago
I'd argue koajs was the first modern express alternative, although it's arguably more of a connect alternative. I've been happily using it since generators were available under a flag with node 0.11 and it has always been a joy. There's a huge list of middleware [0] on their wiki, and you just pull in whatever you need. It means that your initial setup takes a bit longer, but it forces you to understand all the moving parts. The session in production tutorial makes no mention of secret rotation, which I'd consider an important detail for a production environment. The docs don't mention the feature either, but if you look at the underlying express-session library you see that the secret can either be a string or an array of strings. Although redis is an amazing tool, I disagree with recommending it as the first choice for a session store. Unless you really need it or plan on using it for more stuff, you'd probably be better off keeping sessions in whatever data store you're using for the rest of the application. That lets you avoid having to setup and maintain yet another tool. No documentation at all for how the socket.io stuff is supposed to be configured. Chat tutorial assumes a single-node environment, which I'd consider unreasonable for anything outside of a hackathon. Wouldn't you at the very least want a process per core? [0] https://github.com/koajs/koa/wiki https://github.com/koajs/koa/wiki
- franciscop 9y ago
  I didn't know about that middleware list, thanks for sharing. About session rotation, it was my impression that it is a smaller problem compared to how it can be exploited if we're using cookies [1][2], could you share some more info about it please? About Redis, I totally agree. You can add any store that you want with the plain `{ session: { store: ... } }` option. There is an issue though for some of them that need the original `session` passed in which I'll have to fix. So the main fix would really to improve the documentation to explain how to use the appropriate store. Finally about socket.io, I also agree. I am not a large-scale system expert, so this is part of my limitations and that's why I recommend server.js for small-to-medium sized projects. Long-term I am working on improving on my knowledge here, but not the highest priority right now (compared to security for instance). Also, socket.io right now is not stable officially, so use with care. I'd love any help in here if you want to share some of your expertise. [1] https://stackoverflow.com/questions/2846401/does-session-id-rotation-enhance-security https://stackoverflow.com/questions/2846401/does-session-id-... [2] https://www.owasp.org/index.php/Session_fixation https://www.owasp.org/index.php/Session_fixation
weego 9y ago
So it's just another express abstraction rather than an alternative then, considering express is a dependency.
maxpert 9y ago
Title should say wrapper rather than alternative. Since it’s built on top of express.
sideproject 9y ago
As a side thing... is anyone getting a little wee tired of reading the following magical statement about every framework that comes out? :) > [insert the latest framework here] that just works so you can focus on your awesome project
- franciscop 9y ago
  Ah I didn't even think about it being a thing, thanks for the feedback. I did make server so I wouldn't have to worry about so many middleware pieces any longer and could work on my actual projects, but I see how this is fairly common wording.
- dozzie 9y ago
  No, I find it funny. Even hilarious, given that code with initial version published mere six years ago is considered "not modern" somehow. I write in a language that was published twenty years ago and hasn't changed very much since then, and is unequalled to this day. Also, ask any Lisper about "being modern".
mynegation 9y ago
Coming from Python, my understanding is that Express is sort of like flask (add your own everything), and something like sails.js is like Django (bundled, convention over configuration). I am wondering, why, unlike, Python and Rails, Django-type frameworks did not take off in Node.js? I would like to have a popular “Django.js”, so I am rooting for this project.
- franciscop 9y ago
  My opinion is that Node.js follows a lot more the philosophy of small reusable modules, which is a lot more flexible with the disadvantage of a lot more initial work. I still don't think server.js is Django.js-like, since it leaves most decisions up to the developers. The main difference is that Django, Rails, Sails, etc are opinionated about both the libraries AND the code structure, while I tried to keep server opinionated only about some basic functionality, but leaving the more advanced and code structure totally up to the devs using it. But I do try to do batteries-included, because express-like workflow involves following a bunch of steps that are basically the same for most projects. Edit, maybe you are interested on Sails: https://sailsjs.com/ https://sailsjs.com/
- Can_Not 9y ago
  1. Node focuses on modularity. You pick your express clone, you pick your ORM, you pick your front end, you pick your logger, you pick your passportjs plugins. Because so many great things are just unopinionated modules, there's less need to make packages like express-mongoose, koa-mongoose, express-postgres, koa-postgre, express-pug, koa-pug, etc. (although I bet those exist anyways, they are simply gratuitous). If you want redis, you just pick your redis module from npm. 2. You could say npm is the framework. 3. You could say Adonisjs did kick off (pretty good if you wanted a laravel clone) 4. Mainstream webdev in Node is younger, so a clear rails clone is not evident but could already exist under your nose. 5. Maybe front end frameworks are the new "MVC frameworks". You can make both SPAs, MPAs, and hybrid SPA/MPAs with nuxtjs and nextjs. Do you need a full backend MVC framework to do what your frontend framework already does, but better?
debacle 9y ago
It's very interesting watching node developers re-implement the PHP ecosystem.
- DTrejo 9y ago
  it's very interesting watching php composer developers reimplement the npm ecosystem ;)
  - bagol 9y ago
    It's very interesting watching both of your comments XD
chmln 9y ago
This might be somewhat negative, but I don't quite see what problem the library is solving. It looks like as if Express wanted to become more like Koa (obvious from the context object). Frankly, it has missed out - koa's simplicity and elegance is unmatched. The routing and middleware syntax is particularly clunky. Documentation seems really nice though.
- franciscop 9y ago
  No problem, didn't sound negative. The main difference with Koa would be having a starting point with default middleware, security and websockets. I do agree with your points, Koa is probably the most elegant library out there, probably followed closely only by express. But that is not why I created server. It is not about library elegance and simplicity, it's all about making it easy to use. Both of Express and Koa involve external middleware that the user has to manage manually, and there is a subset that is really common for most situations. Server.js is all about usage simplicity, including this subset by default and making things work by default. Context was inspired initially by the way Promises work with a single return value, but then expanded further (and named after) Koa's context.
  - simplify 9y ago
    Isn't koa flexible enough for you to build a framework on top of it to accomplish your goals of elegance and simplicity? That way you could take advantage of the ecosystem that already exists, instead of trying to bootstrap your own.
rawnlq 9y ago
Rather than changing express's syntax, I would much rather have a better express boilerplate generator with an opinionated stack with good documentation/justification. I recently started learning express/node and wasted weeks googling for blog posts for each dependency to figure out how to configure them. I guess this is somewhat valuable for end-to-end understanding but not for productivity. There are a bunch dependencies I am now kind of decided on (not for technical reasons, but because they are clear popularity contest winners) and figured out how use: body-parser compression serve-favicon express-session csurf helmet cors dotenv moment selfsigned chalk debug But still a bunch that I haven't gotten to googling and still need to decide on what to choose: logging (morgan vs winston) validation (express-validator, joi) auth (passport jwt, local, social) session storage (redis vs keeping it in database?) database (mongo/mongoose vs pg/knex/bookshelf/sequelize, graphql) storage (s3 vs gcs) ajax requests (request vs axios) mail (mailgun, sendgrid, mailchimp) error handlers rate limiting geo ip I would be so happy if someone took away my power to choose and just forced me to use something that will "just work".
- rorykoehler 9y ago
  Couldn't agree with you more. Have been involved in a few projects this year where a bunch of freelancers who had never worked together were thrown together to get something up and running quickly. The results were slightly horrifying precisely because everyone had their own tooling and way of doing things. Opinionated boilerplate would have solved so many problems for us upfront.
- jypepin 9y ago
  maybe time to make a "node on rails"!
  - abritinthebay 9y ago
    Please no.
    - clintonb 9y ago
jypepin 9y ago
Surprised at their choice of socketio instead of leveraging http2 streams.
kevinSuttle 9y ago
If you’re just looking for a barebones static file server try this: https://github.com/zeit/serve https://github.com/zeit/serve
segphault 9y ago
This pulls in over 200 dependencies, with a total weight of 37MB. I'll pass.
- franciscop 9y ago
  Only 37MB? I expected more TBH, I guess I am too used to the dev side of it. 37MB is really cheap compared to the hours that you save by not doing everything manually, even more when you consider the quality of the underlying libraries from a security point of view. Long-term I would like to reduce this and have some ideas in mind, but right now this is not an issue.
jroseattle 9y ago
Are there docs or maybe a blog post that identifies the value-add on top of Express? While I see the API design example (which applies to me), we already do that with Express v4 (it's more code organization than anything else.) I'm super-interested, but I'd like to know at a deeper level what this gets us over plain Express.
nawitus 9y ago
Does it support automatic documentation generation for the API (kinda like what swagger + express.js does)? That's the biggest missing feature in Express.js for me.
arrty88 9y ago
Does passport plug into this?
- nawitus 9y ago
  Passport can be quite easily used with any framework, but of course an existing library can make it even easier. Though to be honest Passport.js is trivial enough that I don't see a need for it usually..
webfolder 9y ago
It's enough. We do not need another javascript framework.
benologist 9y ago
This is OK but a hello world app requires 203 modules and that's not really a safe position to start new apps. https://github.com/ChALkeR/notes/blob/master/Do-not-underestimate-credentials-leaks.md https://github.com/ChALkeR/notes/blob/master/Do-not-underest...
slackingoff2017 9y ago
Express is ripe to be replaced. It has the weirdest syntax I've ever seen and is basically designed around call back hell. I can't wait till somebody rebuilds it in Typescript or at least around async
- always_good 9y ago
  http://koajs.com/ http://koajs.com/ In Koa, handlers don't respond to the request. Instead, they update a representation of the response and return a promise. The response bubbles up to the top-level where the `res.send()` is done. This way you have real middleware. You can post-process the response or do something else entirely after the downstream has run. const middleware = async (ctx, next) => { console.log('request going down') await next() console.log('request coming up') }
  - slackingoff2017 9y ago
    Haha this is exactly how I pictured it working! Made by the makers of express too.
itronitron 9y ago
no mention of TLS, which is unfortunate
- clintonb 9y ago
  Why? TLS/SSL termination is normally (at least on every project I've worked with) handled by the web server.
  - franciscop 9y ago
    Exactly, it was initially intended to be a core feature but after searching around (and from my experiences) I found out it is rarely done at the language-level.
amk_ 9y ago
Fastify is a similar project that aims to be faster than Express and adds a number of API improvements like baked-in schema validation for routes, logging, and async-by-default APIs. Haven't used it in production but replaced Express with it in some side projects. Since server.js is built on top of express it might even be possible to build a variant of it on Fastify instead and get those benefits as well. https://www.fastify.io/ https://www.fastify.io/
zmix 9y ago
Is there any Node.js web-framework/app-server like Express, that uses XML as backend, rather than JSON? Or, that can have this plugged in, at least? I'd like to use BaseX (XML document database) as a backend to something like Express.
- deleted 9y ago
  [deleted]
mtarnovan 9y ago
Imagine googling for stuff about this project... (issues, bugs, tutorials etc) Must be a nightmare, with such a generic name

295 points by franciscop 9y ago

I think a lot of people still haven't seen https://feathersjs.com/ https://feathersjs.com/. Has been around for a while and offers all of this and more AND is drop in replacement for Express.

franciscop 9y ago

It is built on top of express to keep all of the good things, but it adds basic middleware and some more advanced functionality like websockets through socket.io and security through helmet by default. It is designed to work perfectly with Promises and async/await, the new ES7 features that makes asynchronous code awesome. Also, I put a lot of work into making the documentation extensive and clear and I'll keep working on that for the future while preparing for the 1.1. Edit, release notes: https://medium.com/server-for-node-js/server-js-1-0-released-12a419ab187a https://medium.com/server-for-node-js/server-js-1-0-released...

picardo 9y ago
I like the design of the API, but I don't understand what you mean by "built on top of express?" I see you have express in a plugin module, but I'm not sure how it's being used.
- franciscop 9y ago
  It is being used underneath to connect all of the moving parts.
- niix 9y ago
  In the package.json you can see its a dependency of the project. So it seems like its more of an abstraction of Express than an alternative.
josephorjoe 9y ago
Looks interesting -- will check it out. I've definitely found the batteries-not-included nature of express to be annoying at times.
josephg 9y ago
Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide? http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets
- Can_Not 9y ago
  Socket.io adds rooms/namespaces as a feature, automatically reconnects with effort to not have all clients reconnect at the same time, covers compatibility edgecases, heartbeat, timeouts, custom events, multiple transport methods, server side implementations in multiple languages, supports non-ws fallback for reasons that might not be browser compatibility, and a good API.
- aphextron 9y ago
  >Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide? The real reasoning is browser support. Socket.io supports automatic fallback to AJAX long polling if the client doesn't support websockets. It also standardizes the interface across clients. It's essentially to websockets what jQuery is to the DOM.
- always_good 9y ago
  For one, it has message_id ackbacks so that you can have a request/response rpc style system. A basic feature for any websocket-heavy application. socket.send('login', [uname, pass], (err) => ...) And there are socket-io clients for most languages that can interop with a socket-io server, once again supporting message_id callbacks. Reconciling my own message_id + reconnect buffer system is not something I want to build on the client + server every time I build an application. People talk shit about socket.io and then never recommend an alternative that implements this fundamental feature. Without message_ids, I get flashbacks to working with IMAP.

drinchev 9y ago

> Note: this option can be ignored and server.js will work with both .pug and .hbs (Handlebars) file types. [1] : https://github.com/franciscop/server/blob/master/package.json https://github.com/franciscop/server/blob/master/package.jso... I think around express 3 the guys decided to go with a modular approach and decouple the server from any of those heavy ( render ) libraries, as well as body-parser ( once it was core module in express itself ). My really friendly feedback is that I think express carries so much experience that it will be really hard to replace it with something so monolithic. I use express for REST APIs as well as full web app, where I need no render engine and having this installed on my server is an overkill. Best approach I would think of is having someone rewrite express from scratch and call it express 5, while keeping the same balance of core and extra functionality, as well as new async / promise goodies.

kosinus 9y ago
Basically what I find Koa does for me: http://koajs.com http://koajs.com
- vidar 9y ago
  I am in the Koa boat as well, does Express have anything that Koa does not? (not trying to start a framework flamewar, honestly!)
  - drinchev 9y ago
    Koa was created by the very same person as Express itself [https://github.com/tj https://github.com/tj] TJ Holowaychuk. The initial idea is to do the next level express framework using back-then generator functions. What is missing ( for me ) is the smaller community and popularity. So it makes it tough to argue about the business impact between choosing koa over express. Honestly, being a nodeJS freelancer for the last decade there was not a single project, where koa was in use. Mostly I've seen express or sailsjs [http://sailsjs.com http://sailsjs.com] which is quite a full-blown MVC Rails style solution.
  - franciscop 9y ago

myf01d 9y ago

> npm install server How could the package name "server" be available all these years :D?

XCSme 9y ago
Asking the real questions! I wonder if deleted package names are made available again. It makes sense that they did, but it's also a security issue, if one package is removed an attacker could add a new package with the same name and with a malicious functionality.
- alvis 9y ago
  In theory, no. Unless you have the magic power like what Laurie Voss have. Remember he saved the world by resurrecting left-pad[1]? [1] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
alvis 9y ago
Apparently the author registered the package name back in 2012. From `nam info server`, it shows that the initial development started on 9 Aug 2012, but stopped very soon on the same day. Then the author picked up the work again last year.
franciscop 9y ago
It was not available! But it was abandoned and without any content, so after talking with npm for this specific scenario they decided to give it to me. I wrote an article called "Getting a great npm name": https://medium.com/server-for-node-js/getting-a-great-npm-name-b0b2b27a0e1b https://medium.com/server-for-node-js/getting-a-great-npm-na...

TheAceOfHearts 9y ago

I'd argue koajs was the first modern express alternative, although it's arguably more of a connect alternative. I've been happily using it since generators were available under a flag with node 0.11 and it has always been a joy. There's a huge list of middleware [0] on their wiki, and you just pull in whatever you need. It means that your initial setup takes a bit longer, but it forces you to understand all the moving parts. The session in production tutorial makes no mention of secret rotation, which I'd consider an important detail for a production environment. The docs don't mention the feature either, but if you look at the underlying express-session library you see that the secret can either be a string or an array of strings. Although redis is an amazing tool, I disagree with recommending it as the first choice for a session store. Unless you really need it or plan on using it for more stuff, you'd probably be better off keeping sessions in whatever data store you're using for the rest of the application. That lets you avoid having to setup and maintain yet another tool. No documentation at all for how the socket.io stuff is supposed to be configured. Chat tutorial assumes a single-node environment, which I'd consider unreasonable for anything outside of a hackathon. Wouldn't you at the very least want a process per core? [0] https://github.com/koajs/koa/wiki https://github.com/koajs/koa/wiki

franciscop 9y ago
I didn't know about that middleware list, thanks for sharing. About session rotation, it was my impression that it is a smaller problem compared to how it can be exploited if we're using cookies [1][2], could you share some more info about it please? About Redis, I totally agree. You can add any store that you want with the plain `{ session: { store: ... } }` option. There is an issue though for some of them that need the original `session` passed in which I'll have to fix. So the main fix would really to improve the documentation to explain how to use the appropriate store. Finally about socket.io, I also agree. I am not a large-scale system expert, so this is part of my limitations and that's why I recommend server.js for small-to-medium sized projects. Long-term I am working on improving on my knowledge here, but not the highest priority right now (compared to security for instance). Also, socket.io right now is not stable officially, so use with care. I'd love any help in here if you want to share some of your expertise. [1] https://stackoverflow.com/questions/2846401/does-session-id-rotation-enhance-security https://stackoverflow.com/questions/2846401/does-session-id-... [2] https://www.owasp.org/index.php/Session_fixation https://www.owasp.org/index.php/Session_fixation

weego 9y ago

So it's just another express abstraction rather than an alternative then, considering express is a dependency.

maxpert 9y ago

Title should say wrapper rather than alternative. Since it’s built on top of express.

sideproject 9y ago

As a side thing... is anyone getting a little wee tired of reading the following magical statement about every framework that comes out? :) > [insert the latest framework here] that just works so you can focus on your awesome project

franciscop 9y ago
Ah I didn't even think about it being a thing, thanks for the feedback. I did make server so I wouldn't have to worry about so many middleware pieces any longer and could work on my actual projects, but I see how this is fairly common wording.
dozzie 9y ago
No, I find it funny. Even hilarious, given that code with initial version published mere six years ago is considered "not modern" somehow. I write in a language that was published twenty years ago and hasn't changed very much since then, and is unequalled to this day. Also, ask any Lisper about "being modern".

mynegation 9y ago

Coming from Python, my understanding is that Express is sort of like flask (add your own everything), and something like sails.js is like Django (bundled, convention over configuration). I am wondering, why, unlike, Python and Rails, Django-type frameworks did not take off in Node.js? I would like to have a popular “Django.js”, so I am rooting for this project.

franciscop 9y ago
My opinion is that Node.js follows a lot more the philosophy of small reusable modules, which is a lot more flexible with the disadvantage of a lot more initial work. I still don't think server.js is Django.js-like, since it leaves most decisions up to the developers. The main difference is that Django, Rails, Sails, etc are opinionated about both the libraries AND the code structure, while I tried to keep server opinionated only about some basic functionality, but leaving the more advanced and code structure totally up to the devs using it. But I do try to do batteries-included, because express-like workflow involves following a bunch of steps that are basically the same for most projects. Edit, maybe you are interested on Sails: https://sailsjs.com/ https://sailsjs.com/
Can_Not 9y ago
1. Node focuses on modularity. You pick your express clone, you pick your ORM, you pick your front end, you pick your logger, you pick your passportjs plugins. Because so many great things are just unopinionated modules, there's less need to make packages like express-mongoose, koa-mongoose, express-postgres, koa-postgre, express-pug, koa-pug, etc. (although I bet those exist anyways, they are simply gratuitous). If you want redis, you just pick your redis module from npm. 2. You could say npm is the framework. 3. You could say Adonisjs did kick off (pretty good if you wanted a laravel clone) 4. Mainstream webdev in Node is younger, so a clear rails clone is not evident but could already exist under your nose. 5. Maybe front end frameworks are the new "MVC frameworks". You can make both SPAs, MPAs, and hybrid SPA/MPAs with nuxtjs and nextjs. Do you need a full backend MVC framework to do what your frontend framework already does, but better?

debacle 9y ago

It's very interesting watching node developers re-implement the PHP ecosystem.

DTrejo 9y ago
it's very interesting watching php composer developers reimplement the npm ecosystem ;)
- bagol 9y ago
  It's very interesting watching both of your comments XD

chmln 9y ago

This might be somewhat negative, but I don't quite see what problem the library is solving. It looks like as if Express wanted to become more like Koa (obvious from the context object). Frankly, it has missed out - koa's simplicity and elegance is unmatched. The routing and middleware syntax is particularly clunky. Documentation seems really nice though.

franciscop 9y ago
No problem, didn't sound negative. The main difference with Koa would be having a starting point with default middleware, security and websockets. I do agree with your points, Koa is probably the most elegant library out there, probably followed closely only by express. But that is not why I created server. It is not about library elegance and simplicity, it's all about making it easy to use. Both of Express and Koa involve external middleware that the user has to manage manually, and there is a subset that is really common for most situations. Server.js is all about usage simplicity, including this subset by default and making things work by default. Context was inspired initially by the way Promises work with a single return value, but then expanded further (and named after) Koa's context.
- simplify 9y ago
  Isn't koa flexible enough for you to build a framework on top of it to accomplish your goals of elegance and simplicity? That way you could take advantage of the ecosystem that already exists, instead of trying to bootstrap your own.

rawnlq 9y ago

Rather than changing express's syntax, I would much rather have a better express boilerplate generator with an opinionated stack with good documentation/justification. I recently started learning express/node and wasted weeks googling for blog posts for each dependency to figure out how to configure them. I guess this is somewhat valuable for end-to-end understanding but not for productivity. There are a bunch dependencies I am now kind of decided on (not for technical reasons, but because they are clear popularity contest winners) and figured out how use: body-parser compression serve-favicon express-session csurf helmet cors dotenv moment selfsigned chalk debug But still a bunch that I haven't gotten to googling and still need to decide on what to choose: logging (morgan vs winston) validation (express-validator, joi) auth (passport jwt, local, social) session storage (redis vs keeping it in database?) database (mongo/mongoose vs pg/knex/bookshelf/sequelize, graphql) storage (s3 vs gcs) ajax requests (request vs axios) mail (mailgun, sendgrid, mailchimp) error handlers rate limiting geo ip I would be so happy if someone took away my power to choose and just forced me to use something that will "just work".

rorykoehler 9y ago
Couldn't agree with you more. Have been involved in a few projects this year where a bunch of freelancers who had never worked together were thrown together to get something up and running quickly. The results were slightly horrifying precisely because everyone had their own tooling and way of doing things. Opinionated boilerplate would have solved so many problems for us upfront.
jypepin 9y ago
maybe time to make a "node on rails"!
- abritinthebay 9y ago
  Please no.
  - clintonb 9y ago

jypepin 9y ago

Surprised at their choice of socketio instead of leveraging http2 streams.

kevinSuttle 9y ago

If you’re just looking for a barebones static file server try this: https://github.com/zeit/serve https://github.com/zeit/serve

segphault 9y ago

This pulls in over 200 dependencies, with a total weight of 37MB. I'll pass.

franciscop 9y ago
Only 37MB? I expected more TBH, I guess I am too used to the dev side of it. 37MB is really cheap compared to the hours that you save by not doing everything manually, even more when you consider the quality of the underlying libraries from a security point of view. Long-term I would like to reduce this and have some ideas in mind, but right now this is not an issue.

jroseattle 9y ago

Are there docs or maybe a blog post that identifies the value-add on top of Express? While I see the API design example (which applies to me), we already do that with Express v4 (it's more code organization than anything else.) I'm super-interested, but I'd like to know at a deeper level what this gets us over plain Express.

nawitus 9y ago

Does it support automatic documentation generation for the API (kinda like what swagger + express.js does)? That's the biggest missing feature in Express.js for me.

arrty88 9y ago

Does passport plug into this?

nawitus 9y ago
Passport can be quite easily used with any framework, but of course an existing library can make it even easier. Though to be honest Passport.js is trivial enough that I don't see a need for it usually..

webfolder 9y ago

It's enough. We do not need another javascript framework.

benologist 9y ago

This is OK but a hello world app requires 203 modules and that's not really a safe position to start new apps. https://github.com/ChALkeR/notes/blob/master/Do-not-underestimate-credentials-leaks.md https://github.com/ChALkeR/notes/blob/master/Do-not-underest...

slackingoff2017 9y ago

Express is ripe to be replaced. It has the weirdest syntax I've ever seen and is basically designed around call back hell. I can't wait till somebody rebuilds it in Typescript or at least around async

always_good 9y ago
http://koajs.com/ http://koajs.com/ In Koa, handlers don't respond to the request. Instead, they update a representation of the response and return a promise. The response bubbles up to the top-level where the `res.send()` is done. This way you have real middleware. You can post-process the response or do something else entirely after the downstream has run. const middleware = async (ctx, next) => { console.log('request going down') await next() console.log('request coming up') }
- slackingoff2017 9y ago
  Haha this is exactly how I pictured it working! Made by the makers of express too.

itronitron 9y ago

no mention of TLS, which is unfortunate

clintonb 9y ago
Why? TLS/SSL termination is normally (at least on every project I've worked with) handled by the web server.
- franciscop 9y ago
  Exactly, it was initially intended to be a core feature but after searching around (and from my experiences) I found out it is rarely done at the language-level.

amk_ 9y ago

Fastify is a similar project that aims to be faster than Express and adds a number of API improvements like baked-in schema validation for routes, logging, and async-by-default APIs. Haven't used it in production but replaced Express with it in some side projects. Since server.js is built on top of express it might even be possible to build a variant of it on Fastify instead and get those benefits as well. https://www.fastify.io/ https://www.fastify.io/

zmix 9y ago

Is there any Node.js web-framework/app-server like Express, that uses XML as backend, rather than JSON? Or, that can have this plugged in, at least? I'd like to use BaseX (XML document database) as a backend to something like Express.

deleted 9y ago
[deleted]

mtarnovan 9y ago

Imagine googling for stuff about this project... (issues, bugs, tutorials etc) Must be a nightmare, with such a generic name