search

outmoded / discuss

The "mailing list"
99 stars 9 forks source link

ES6 plans for HapiJs (would like generator support like KoaJs) #318

Closed mmc41 closed 5 years ago

mmc41 commented 8 years ago

I am evaluating various JS frameworks for a new REST API and so far HapiJS seems to be a winner except that KaoJS's approach of using ES 6 generators rather then callbacks looks very attractive. Does HapiJs have any plans for supporting ES6/generators so HapiJS can compete here ?

Marsup commented 8 years ago

Kind of already supported with https://github.com/estate/hapi-generator or https://github.com/ide/hapi-async-handler.

mmc41 commented 8 years ago

Thank you very much for your quick response....I am however looking at first-class support like KaoJs that is baked-in so it something that is officially supported, unlikely to break in edge cases and future releases and is documented and understood by HapiJS developers in general.

P.S. What are the HapiJs maintainers attitude on dedicated ES6 support in general in the core framework (in order to provide even easier API's) ?

Marsup commented 8 years ago

You're using nodejs which had this success mostly thanks to its userland module ecosystem, no offense but I think your reasoning is somehow flawed :)

I'll let others speak for themselves as I don't speak for the whole organization, but I can't imagine a decent solution with either generators or async functions, you can't achieve the same richness, using the this to attach your response just feels plain wrong. We'd have to think of an API that makes sense. If you have proposals that are not a simple copy of koa I'd love to see that. FWIW we're already supporting promises so in a sense we already support async functions, but you can't do everything with it, you can't change headers, cookies, status code, ...

mmc41 commented 8 years ago

NodeJS Modules are good but they are no magic bullet. One still have to consider limiting dependencies - especially for crosscutting concerns like error handling. I don't want to go against what HapiJs has to offer here. As for flawed logic, I don't want to start an argument here. I just hope you understand that different people have different priorities, experiences and different willingness to take risks. Ones logic does not have to be flawed just because they differ.

I don't want to start a religious discussion. As I said, I actually think HapiJs is more attractive then KaoJs. I just think that KaoJ - because it embrace ES6 rarther than being stuck at ES4 - has a few attractive features. I am not the only one (f.x. read this article "https://www.airpair.com/node.js/posts/nodejs-framework-comparison-express-koa-hapi"). So my message here that maybe HapiJS can be even better by embraching ES6 also.

I don't have any concrete suggestions yet about the API at this time - I leave it to JS experts like you.

Marsup commented 8 years ago

Sorry if my message came out as negative, not my intention. My point is you'll have to accept that your application is living from hundreds of tiny modules at some point, that's the way of node. hapi maintains a tight control over which modules are included in the core (28 out of the box already) but that's an exception in node's world, you'll have to have other modules at some point, and then the http framework you'll choose won't count as much. Having a pretty robust test suite to keep that under control and shrinkwrapping when you ship will help, but I doubt limiting the number of modules is necessarily synonym of a better quality. Just my 2¢ on the matter...

For those hapi plugins I mentioned, I don't know them at all, but we're speaking of 20 lines modules. I can't guarantee it won't break for the years to come, but you'd probably be able to fix it yourself even if the maintainer went missing. I don't see anything wrong with having plugins if they're of good quality, that's actually been a major selling point for hapi since the beginning - easy integration of new features without the hassle that you'd see in express/koa.

As for hapi itself, we've been gradually adopting ES6 features when they made sense and brought value, both in terms of usability and performances (it's not a hype contest for who's using most of ES6), not that generators don't, they haven't been discussed yet afaik, so we're definitely not against and good point kicking off the discussion ! I'd personally say it's more of a trade-off, koa's way doesn't seem marginally better nor worse to me, just different. I'd love to see ideas that improve over what we have, not try to copy koa.

Enough of me, let's hear the others...