Hacker News new | past | comments | ask | show | jobs | submit login

> 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.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.




I totally agree, somewhere in the homepage I explain what this package is for. I decided not to bomb myself and not writing "where you should NOT use it" but I still hint to it. Server is good for small to medium projects where you don't want to be writing the same thing again and again. Think of it as express with a bunch of sane defaults and some extra functionality.

An extra render engine does not affect on anything except on file size (and a tiny bit of install time), which is cheap nowadays. If you are making a single big project server might not be the best option, since you might want to fine-tune many things. If you are making several projects per year with Node.js then it is perfect, since you don't want to waste time doing the same thing again and again.

As others commented, express 5 with async/await = Koa.js

BTW, bodyParser was just added back into the core of express.


Basically what I find Koa does for me: http://koajs.com


I went from hapi to express simply for the plethora of middleware (specifically passport).


Really? Hapi has its request lifecycle and built-in auth that makes auth much simpler than injecting authentication/authorization middlewares on every route.


agree,also hapi has a pretty big ecosystem of middleware. a lot of it 1st party


I am in the Koa boat as well, does Express have anything that Koa does not? (not trying to start a framework flamewar, honestly!)


Koa was created by the very same person as Express itself [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] which is quite a full-blown MVC Rails style solution.


IMHO, and one of the reasons I decided to go with server, simplicity is a feature and the advantage of express over Koa. It is hard enough for new users to get started on Node.js, but to have to handle all of the new middleware concepts, PLUS to have to learn a lot more advanced features like generators is a no-go for my framework of choice.

- server: return something to reply to the browser. Can use `async` for more advanced features.

- express: reply.send() is fairly straightforward. next() for middleware is a new concept but conceptually in the right place (when you are digging a bit deeper in the middleware).

- Koa: yield, function with asterisk, etc.

So I think Koa is fine for devs who have been a while in JS dev, but the learning curve is too steep to get started. Same as what happens with React and the reason create-react-app has become so popular.


Koa has been doing async for a while. It's basically connect with promises instead of callbacks: `app.use(async (ctx, next) => { await next(); });`


As long as you're on Node >=v7.9, you can also use `await` in Sails, Koa, or any other tool that supports promises. There's some work we had to do to make it feel nicer, and we had to update docs and stuff, but for the most part it was pretty painless-- all thanks to the JavaScript engine.

And `await` is so much easier and safer than callbacks in userland code! Really excited about Node.js in 2018, now that `await` is supported in the LTS release. Callback hell is finally dead.

(Diff showing a refactor of an example app from traditional callbacks to async/await: https://github.com/mikermcneil/chatkin/pull/4/files)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: