10/31/2016
react-text: 46 The hapi framework ecosystem has been pretty quiet lately. With all the community changes around other frameworks (express, restify) and the lack of splashy new hapi releases, I've been asked about the longevity and direction of hapi. This conversation will address these questions as well as answer any roadmap related questions you might have. /react-text react-text: 47 /react-text react-text: 48 I will also discuss how the framework is being maintained post-Walmart, what kind of contributions are needed, and look into the future as people and companies still rely on the framework for their critical infrastructure. /react-text
Nicolas Morel react-text: 63 Now that hapi is stable, do you think the project should make an effort on performance ? I know where you stand on benchmarks but so far there hasn't been much work on performance regression of hapi on its own, shouldn't it matter to at least monitor this ? /react-text
collapse
Eran Hammer react-text: 76 I am not sure I care much about the state of the project with regards to stability of the code base and it's relationship to performance. I approach performance based on real world needs and we have looked at issues when performance was degraded between releases or when the framework failed to deliver the metrics needed. /react-text react-text: 80 However, with a more stable code base, I think others might find the environment more worthwhile for performance work. We as a community have been pretty resistant to micro-optimizations that take advantage of specific V8 logic to gain a few CPU cycles. But there are areas where we can certainly refactor the code to be more efficient. /react-text react-text: 84 A good example for that is the work we started recently with reducing unused logging and previously with compiling the request lifecycle loop for each route so that we don't check for non-existing extensions on every request. /react-text react-text: 88 I would very much welcome someone developing a benchmarking suite for hapi for the purpose of ensuring performance doesn't degrade over time. But it needs to be clear that the goal is to compare hapi to itself over time, not to other frameworks. /react-text
Tim Navrotskyy react-text: 101 Walmart just released Electrode with Hapi.js as one of the out of the box ways for SSR. This is a sign that Walmart is still invested in Hapi. Why do you mean it's post-Walmart era for Hapi right now? /react-text
collapse
Eran Hammer react-text: 114 I am not sure Electrode signifies any existing or renewed investment by Walmart in the hapi ecosystem. I am very grateful to Walmart for three years of dedication and investment in the development of the framework. However, I have not seen much company-sponsored work since I left Walmart. This is not criticism, just my observation. It is perfectly natural for companies to shift their focus and resources and from my limited knowledge of how Walmart is using hapi these days, I understand why - the framework does what they need. /react-text
Gregor react-text: 127 What is the status of the Mentor Program? /react-text
collapse
Eran Hammer react-text: 140 The mentor program is not active. We tried putting it together as part of the diversity effort but it turned out to require a pretty significant time commitment to manage. Unfortunately, the people who stepped forward to try and run it all ended up letting it go. I still think it is a worth effort but I am skeptical it can be done without some corporate sponsorship paying someone to do it. /react-text react-text: 144 In addition, while hapi is not the usual target of new developers using node (that is still very much Express), we have seen more developers starting their node work with hapi. This means the effort required to support a mentorship program is only going to get bigger if we restarted it today. /react-text react-text: 148 I have largely stepped away from direct involvement with hapi community work other than the core module and general review of the ecosystem's code base at large. If someone wants to revive the mentor program, that would be great. My only concern would be being able to sustain it and I would rather not try, than enter it with the wrong expectations only to shut it down yet again for the third (or fourth) time. /react-text
Loc Nguyen react-text: 161 Have you seen anything in other frameworks that you think could benefit Hapi? /react-text
collapse
Eran Hammer react-text: 174 I don't really look at other frameworks anymore. I take a look when there is some new development but I don't keep up with incremental changes others make. The fact is, as an HTTP framework, there really isn't much more hapi can do. It is a pretty mature framework that does what it needs to - handle HTTP requests. /react-text react-text: 178 The areas I am always looking to improve are in the developer experience front. How to access the same existing functionality better, faster, and at larger team scale. Unfortunately, that's an area very few frameworks invest in so there aren't that many good ideas to copy. I believe hapi is still the best framework when it comes to the developer experience. It is not done yet and needs more work but it is pretty great. /react-text react-text: 182 There is also the limitation of the number of other comparable frameworks to look at. Most new frameworks seems to be aiming at a much higher level of the stack. They focus on specific use cases unlike hapi, Express, koa, and Restify. I am not away of new frameworks operating that the HTTP level like these other four. /react-text
devin ivy react-text: 195 Will hapi tend towards enforcing stronger plugin boundaries, i.e. further expanding/defining the concept of realms? /react-text
collapse
Eran Hammer react-text: 208 I had big plans for realms when I first introduced it 2 years ago but that never materialized into an actual use case. The goal with realms is to allow better sandboxing of plugins - allowing a plugin to set it's own route config defaults, etc. without having any impact on other plugins. /react-text react-text: 212 In practice, I've been using connectionless plugins more as my favorite architecture which means each one of these plugins already gives me the level of isolation I needed. I still think realms are a good idea and that they should be expanded to make isolation easier and better between plugins. I just haven't seen the need for that to support the effort needed to make it happen. /react-text react-text: 216 It would be helpful to hear from people about their experience breaking their application into plugins at scale and the challenges they had to deal with. Given how little information there is about the developer experience people have with hapi, it is hard to design solutions other than those based on my own personal experience. /react-text
devin ivy react-text: 229 We saw the introduction of /react-text react-text: 231 reply.entity() /react-text react-text: 232 and the server as an enhanced event-emitter (via podium) since you began working on Sideway. Over twitter it sounded like you saw these as important features that were missing. Given your recent practical experiences with hapi, what other notable blind spots have you found that will influence the long-term roadmap of the framework? /react-text
collapse
Eran Hammer react-text: 245 Pretty much every feature added in the past year came out of my own personal experience building Sideway (this website you are reading this on) and from contract projects I am working on. Having control over the framework's core allows me to jump right in and improve areas as I hit walls. /react-text react-text: 249 For example, I recently added support for conditional connectionless plugins. I was trying to design a deployment where a plugin can be loaded into a bare server or in combination with other plugins. This meant the creation of the connection was decided at plugin registration time and not ahead by the runner process. /react-text react-text: 253 I felt this was something that should be improved after I had to write some code to work around that limitation. Basically, whenever I find myself surprised by hapi's less than optimal developer experience, I jump in to fix it. /react-text react-text: 257 In the past, when people shared issues they had where they had to write extra code just to work around a hapi limitation, we did our best to address it. It doesn't always mean it has to happen in core (e.g. glue, rejoice), but having real world experience is key. /react-text react-text: 261 I am not yet satisfied with the overall developer experience. I think it is 85% of the way there but there are plenty of small changes we can make that will improve it. That's my main focus. I don't consider the changes I have made over the past few months to be missing features. As the framework gets older, I start to forget how certain features work which gives me the opportunity to experience them without bias. So just like everyone else, I open the docs and then write some code. Sometimes it doesn't do what I expect it to, and that's when I jump in to fix things. /react-text
josue rodriguez react-text: 274 What do you think about javascript isomorphic framework? /react-text
collapse
Eran Hammer react-text: 287 Meh. /react-text react-text: 291 Server side work is fundamentally different from client side work. The two worlds just don't really overlap until you get to optimizations which are usually moving client side code back to the server. /react-text react-text: 295 As a backend developer, I look at frameworks such as React as exclusively client side with the ability to run /react-text react-text: 297 client-side /react-text react-text: 298 operations on the server. I do not consider them a replacement for the work the server has to do regardless. /react-text react-text: 302 In many ways, rendering engines are really more of a front end tool than back end. This is pretty obvious when you look at who is using them, even when they run on the server - front end developers. I agree that deployment strategies have become pretty fluid and that people can run and share code on both the client and the server, but that is mostly a /react-text react-text: 304 front end /react-text react-text: 305 deployment strategy, not an overall isomorphic architecture. /react-text react-text: 309 So to the extent that I am able to run React code on both the client and the server (as well as on some native platforms) - that's great. But that is not really part of the back end developer tool box. It is still very much in the front end domain, regardless of which CPU is executing the code. /react-text
Luis Matute react-text: 322 I don't have a senior level expertise in JavaScript but want to contribute/learn the core of Hapi and how it works, what do you recommend? /react-text
collapse
Eran Hammer react-text: 335 Pick a test, run it, then look at the code and try to figure out how that test work. I am a /react-text react-text: 337 big /react-text react-text: 338 huge fan of /react-text react-text: 340 console.log() /react-text react-text: 341 . That's pretty much my exclusive debugging tool. That and staring at the code until it blinks. When I need to understand how something works, I start by placing a few bookends logging lines with numbers, run the test, then narrow down the area I am looking at, printing out variables and other information. /react-text react-text: 345 But yeah, go read the tests. There are a lot of them and they are pretty helpful in understanding specific areas of the code. When you do that, focus on specific areas first and then move to the more complex areas. For example, request validation and authentication are pretty self contained while response processing and transmission are are probably the most complext. /react-text
Gregor react-text: 358 What is the status of /react-text https://github.com/hapijs/makemehapi react-text: 360 ? /react-text  GitHub hapijs/makemehapi makemehapi - Self guided workshops to teach you about hapi.
collapse
Eran Hammer react-text: 525 I am not sure. I haven't been paying attention to it in a long time. /react-text
Rui Quelhas react-text: 615 With the advent of alternative API approaches such as GraphQL, do you think those are completely outside the realm of hapi? Do you think there might be any inflection point in the near future or HTTP will always outlive them? What particular challenges do you see for hapi in that context? /react-text
collapse
Eran Hammer react-text: 830 It's hard to say but history has proved HTTP to be pretty resilient. HTTP is more than just light semantics over TCP. It is a complex ecosystem including authentication, caching, and encoding. When XML-RPC tried to replace HTTP semantics it failed, and not just because of the XML part. It had to reinvent a lot of things that HTTP (and the massive infrastructure that supports it) does well. /react-text react-text: 1001 I think HTTP2 is a significant development that is going to have an impact. In that sense, I expect hapi to evolve more in line of how it approached WebSockets (the nes plugin) than a fundamental change in architecture. /react-text react-text: 1278 You also need to keep in mind, most of new developments are pretty focused on interfaces directly accessed by front end clients. While this is very much the front line of web development these days, it is only one part in a larger stack. I haven't seen any new patterns of building back end components in a long time. /react-text
devin ivy react-text: 1291 Do you foresee the possibility for any further "official" educational programs akin to the mentorship program or hapi university? /react-text
collapse
Eran Hammer react-text: 1367 Sure, just not from me. :-) /react-text react-text: 1614 Given the significant footprint hapi has, especially among larger entities, I expect to see more people and companies invest in making the technology more accessible. But given the size of the effort at this point (it is a pretty big ecosystem), I think commercial initiatives are more likely such as courses and books for profit. /react-text react-text: 1673 Thanks everyone! Stay hapi! /react-text react-text: 1675 (edited)