Hello friends 👋! I'm Henry, an engineer on the Behance team at Adobe in NYC. I started with an interest in data visualization but then moved to tooling.
I luckily got an interview at Behance because of my contributions to JSCS. I helped to merge it with ESLint and along the way discovered Babel and learned about "compilers". Now I get to spend about 50% of my time working on Babel at work. I am looking forward to the time when projects are able to work on OSS part/full time though!
Recently I gave some talks on what it's like to be a maintainer, how Babel is more than just the code itself, and dealing with burnout and the community. I did post I was going to spend less time on it to focus on health, so hopefully some people/companies will step up!
I enjoy playing ping pong, board games like 7 wonders, video games (a lot of Mario Odyssey lately 😊)
Ask me about OSS (its myths, its community, and its relationship to community/faith) or about the nature of Babel: it's difficult role in the ecosystem trying to glue it all together: spec compliancy with TC39, code speed/size complaints, JS fatigue, and handling it all as a group of volunteers.
Latest comments (67)
Looks like I am late to the party. What are the prerequisites to contribute to the babel repo?
I want to know the history of Babeljs. Who make original idea of babeljs. Who build babeljs? How do you get involved to this project?
Merry Christmas Henry!
Playing some devil's advocate here, why should large companies engage in open source software and what's the value of spending development resources to maintain open source projects?
What's your take on open source sustainability?
Do you think open source is impacted by economic issues? If so, why?
to
What are the myths you speak of in OSS?
Maybe I shouldn't call them myths but I was thinking more about the things of assumptions one might make before getting into OSS? I might of mentioned in before but things like:
I don't think this is true (also from personal experience)? Of course you might want to have some kind of baseline and that does shape the kinds of things you can contribute upfront but it's really about sticking with it and progressing in figuring out the kinds of things you like to do. Like I started not knowing git/github that well so maybe I could of learned that first but doing everything on the fly was fine. Everyone who is on the team learned it on the fly, and likewise, Sebastian created Babel to learn about ES6 and compilers. And you don't have to do it alone if you can do it with someone and our help.
I will say that we don't make it easy to contribute currently and there is still a huge burden on the maintainers to support new contributors when they come so there's much we can improve on.
I would like to be part of the open source program but anytime I look at issues, most are beyond my skills as at now? What should I do to be able to tackle an issue
thanks for putting those videos up on the babel website that explain the theory behind babel. babeljs.io/docs/community/videos/ They are really helpful. What do you think is a good starting point if someone who like to contribute to the babel project?
Awesome, good question Maurice!
I would read through our readme.md and contributing.md, and yeah the videos for sure.
As for something specific I might suggest looking through some new (or even old)
good first issuelabeled issues. If you want to contribute, simply learning about the project is a contribution in itself even though you might not be "committing" code to the project necessarily. That's why I think if we make a new issue and someone "solved" it or made a PR already, it doesn't mean you "can't" work on it, just that you might not get your name on the commit since you can just work on it own your own or even better pair up with someone to figure it out or even give someone a PR review.I'd like to think we can expand the definition of what it means to contribute to a project: not a PR or a commit but so many other things (I can expand on this in a separate post) but I think this is good for now.
Like better documentation doesn't have to mean a typo fix, or writing docs when they aren't there, but also making these accessible to newcomers and other various ideas that even I haven't come up with. Maybe the best thing you can really do to contribute to a project is just to learn more about the project itself; maybe after that it will be easier to actually realize what a project is "missing" or what needs help. Otherwise you are just going into it dark and doing what the simplest thing is. Not that that is a bad thing because all of it is helpful but there is a lot more out there that I know everyone is capable of doing.
Ideally you would have a mentor for these things but that is something I can't myself do right now.
How is "JS fatigue" evolving? Are things settling down in any way? What's your sense on the current state?
Dan had a nice talk/post about this.
I'm probably too fatigued with "js fatigue" to talk about it that much in depth, but I'll say that tool authors have a lot to deal with, and use-cases to handle that not everyone cares or thinks about.
This is a similar situation with TC39 and how people complain why there are so many OO features and that JS should be a "functional" language. But JS is used by a lot of people, and in many different situations/environments.
In a similar way tools should try to work "out of the box" but defaults can be hard, and not everyone will agree on what those are. It does seem to go back an forth in this cycle of "being able to do everything, everything is configurable" and "no config, only the basic use case is supported and you have to fork otherwise". Convention and configuration happens, and people have different views on whether you should build on top of tools, create new ones, integration, make "plugins", etc. I think we should admit it's a difficult problem? Something can be a lot faster, have less config but there are tradeoffs being made. But having new ideas can bring change to the larger/fatigued projects too.
Personally babel-preset-env has been my try at beginning to combat this kind of thing. Even though that itself is complicated it helps to make decisions easier for the end-user. It helps the project since there's less choice in the presets, and allows for other decisions to be made instead. Reducing the amount of choices is a goal for us, so there's always improvements to be made.
Hello Henry,
What do you like about your job both on behance and on babel?
Where do you think that a beginner in javascript should start?
Do you have any book or tutorial recommendations about javascript?
Thank you for your time.
Thanks for the question Nick!
I like Behance because we are able to work on a website that helps others - specifically artists/creatives. We have a free to use, no ad product that allows us to focus on just making it better for ours users. The business goals also align with our users (in helping them share, collaborate, and get jobs) and that's good to understand. And I like our team because like I mention in dev.to/hzoo/im-the-maintainer-of-b... we care about software quality in it's various forms, we do "lunch and learns" every once in a while to talk about various things we are learning whether it's something technical or Mike's "analyzing song lyrics" talk. We care about our users, the teams wellbeing, and collaborate between design, community, development, business, etc.
For Babel, feel like I could say a lot but I like being able to contribute to a project that shapes the future of JavaScript and web development. There's just so many parts to it, it doesn't really get boring. I know some people want to move on to different things, but it at least feels big enough that there's always another aspect of the project or open source that I want to look into and figure out: whether it's the compiler itself, language design, managing github/open source, keeping contributors and making maintainers, handling the various communities whether it's other frameworks, tc39, new developers, other languages, plugin authors, etc. There's really an endless amount of things to work on that I want to express, so like I think I mentioned in another answer I will probably transition into doing more of that kind of project manager role (which is what a maintainer seems to mean anyway) just because that seems interesting? I think doing oss lets you put on a lot of hats, kind of like making a startup/company except at least until you try to work on it full time isn't your livelihood 🙂. It means you are free to do whatever you want*
I would sum being a maintainer like the tweet I posted recently: twitter.com/left_pad/status/940384....
I think you can start by trying to make something you'd like: a website, an app, a game and learning to do the steps it takes to make that happen. Unless you are the kind of person who is able to take classes or learn from tutorials on more abstract or other things. I would find a group that you can do it with instead of doing it alone.
As for books, there are a lot like eloquentjavascript.net or amazon.com/Understanding-ECMAScrip..., but I personally I didn't read anything when I got started. I think if you are interested enough you'll find the right resources but I guess it depends on where you are at?
Thanks for your time and answers.
Well to be exact i'm doing good with javaScript but i always trying to find ways to improve myself. I am more of a Backend developer.
If i am allowed one more question.
I am trying to start side project(it will be an SDK) and find it hard at this time to plan and structure my library and get started. Could you give me some tips on this matter ? (I'm looking on getting myself to the next level on thinking the bigger picture and to creating libraries/sdks/systems)
Thanks again.
Does Babel have explicit "governance"? How often do you get together and talk non-code stuff related to the health of the project?
Yeah governance is a big topic for open source, especially as a project gets bigger. I think for those that are non-linux/big ones it just starts with a single person and grows organically from there. Babel itself isn't that structured unlike ESLint or Node.
We did make a team page and have definetely discussed trying to do a more formalized structure but that's hard to enforce/commit to all the time when people are coming and going, having a mostly volunteer time, people taking weeks off, burnout etc.
We talk about it periodically in our slack channel and we started doing "weekly meetings" and posting them at github.com/babel/notes. I was doing it for a while and trying to schedule it. Our GSoC intern Karl puts it well: babeljs.io/blog/2017/08/16/contrib.... It's hard to do meetings when people are across the globe and literally not a good time for everyone in some cases.
I'm kind of tired of doing them so it went to 2 times a week and now I feel like it's better sometimes to just do a weekly summary of what's been going on in the community and the repo (notable PRs, issues, talks, etc). And if someone wants to do a call we can do that. I'd like to ask other members in the community for some calls to talk as well. Recently I joked maybe our meetings should just be playing Mario Kart on the Switch (we just played some yesterday finally).
I just added Angus to the team because he made an awesome song, and why not just make it the "Babel" song. twitter.com/left_pad/status/938956...
I was looking for other ways for people to get involved in OSS/Babel, especially in non-code ways and this is certainly one of them 👏!
Or Jordan with his awesome medium post which lead to the whole Guy Fieri meme: medium.com/friendship-dot-js/i-pee...
Henry hello!
So I don't think Babel "won't" be needed soon, and it's not because I happen to work on it 😂.
I think that is a result of thinking it is still "6to5". I'll admit that yes ES6/ES2015 was a huge change that lead to this kind of thinking/tool, but I think maybe we all need to think a bit longer-term?
github.com/babel/babel-preset-env shows the change in thinking that I had. Babel doesn't do a static thing of just turning your ES6 code to ES5, but it actually will move forward as the language progresses and browsers update. As long as we need to support old browers, and the language continues to update with new syntax, AND all of us continue to want to use that new syntax (that's key), then something like Babel seems to be necessary?
If you think ES6 is good enough and you only support evergreen browsers, then yeah Babel isn't necessary and lucky for you! Or if you are in Node and are able to update to the later versions than the same thing there.
2.
This goes well with the points above: Babel isn't just a backwards compatible tool, but actually helps inform the future of the language itself. By using the plugins that are TC39 proposals, you can help give feedback to the committee that makes JavaScript to make it better. Maybe the proposal is unintuitive, slow, etc and they can get that real feedback from developers during the Stage process (0-3) without having to implement and waste time/money in browserland to find that the idea was bad and developers don't want to use it at all.
It's a fine balance though, people don't really understand what Stage 0 means, and that's actually understandable too. There's an education problem there. As much as I try to push for better docs, codemods to remove killed proposals or to upgrade in between proposals (decorators, etc), it's just a lot of work, and a lot to manage for a few people, let alone the whole community.
We need more people/companies involved, and people thinking about these issues that will impact the future of how we write JavaScript and websites in the future - whether it's via JavaScript or interop with another language that compiles to JavaScript (via js libraries).
A bit personal, but... Does someone with your accomplishments not have to worry about "imposter syndrome" at all?
Have you ever had someone explain how babel really works and what it's for before discovering who you are?
--Do web-programmers behave differently towards you--once they do?
twitter.com/left_pad/status/859789...
I think when you are learning new things, you discover how much you don't know and it may give the feeling of "imposter syndrome". I remember reading a post about it (maybe someone remembers) that a lot of us don't actually have imposter syndrome but it's something else.
There are different levels of progression: maybe it's first issue/comment, first PR, first publish, first repo, etc and the next thing always seems so overwhelming. It's helpful to remember that it just means you are learning more. I think I just have a confidence issue, starting from knowing nothing doesn't mean you are unqualified, if you are there than someone wanted you to be. Like feeling nervous about giving a talk or even attending TC39. Everyone has different things to bring to the table, we shouldn't have to live up to the stereotype of what we think a developer or whatever is, it's just an average/typical thing that doesn't describe the diversity of people and their journey to where they are today.
I try to put my efforts into getting others involved in the project: it's the part of open source I appreciate the most (the people part), it is in my interest to make sure I don't become the only person involved and to make make all of our efforts as a team better, and it brings in different ways of thinking. We've tried many kinds of efforts like participating in Rails Girls Summer of Code and Google Summer of Code, talking with various companies, joining meetups, etc. Of course I'd like to be able to spend full time doing these efforts because none of this community effort is usually what you would be paid to do at a company given it isn't as direct a benefit
Yeah that happens haha. It's kind of like how people are mean to your online (twitter/github) because they don't understand it's a person behind the username/project. Once they know you everything changes. I think it's like how open source can be a victim of it's own success: being a popular project doesn't do anything to help the sustainability of the project and only increases the burden. The same small amount of people are helping improve it while more and more people are using/consuming it, and it creates this cycle of burnout in maintainers. People think that Babel is a company, that I work at Facebook or Google, or various other things because of their assumptions.
wow... awsome. Lots of food for thought. thanks, Henry!
Great question!
Hey! I’m often seeing that I should contribute to Babel, but when using it I don’t see anything that I can improve. Do you notice that it’s harder for a project that seems “complete” to get contributions than something small?
Hey Haroen, good question!
It's not something that projects do a good job at in general. Making beginner-friendly (good first issue) issues is hard, takes lots of time, and scales inefficiently. And I've made a lot of those: github.com/babel/babel/labels/good first issue.
It is hard because it seems overwhelming. I was intending to make a better guide with real issue/PR examples but haven't one it yet.
It's ironic because on my side I think it's not even close to being "complete" as a project but I need to figure out how to express that in the right way 🙂. That should probably be my priority instead of trying to fix all these specific bugs/issues myself.
That's maybe because very rarely when I have a problem with Babel it's a problem in the project itself, but usually it's something I set up wrong, rather than being wrong. For you to notice that things aren't following specs needs you to 1. know the specs very good, and 2. actually care about the differences.
Thanks for your answer!
Yeah I think the scope of the issues I think about aren't really about the syntax/output but how it affects the ecosystem.
Examples:
Hey Henry! Since most of your work is being a maintainer, how often do you get burned out? And what do you find is the best way to deal with it?
Hey @lianafelt ,
Thanks for the question, sorry for the later response. Just going to type out quick thoughts!
I guess it depends on the definition (or if it's a severity level before you get to burn out)? If it's just a matter of not wanting to work on the project then that happens often and at least in that case I know that's pretty normal. Even for your hobbies, your work/job, or your passion it's possible to want to take a break. When you are thinking about something all day every day you lose sight of a lot and sometimes simply not doing it helps so much. Maybe it's easier with a job if you can take off weekends or not have to work late, if it's a startup it does seem like it consumes your life?
It's funny since open source may seem like a startup too: you don't get paid, you may work on it with a few people, you are trying to grow and get usage etc. Except you don't care about raising money or making a living off of it so you are free to leave. It's really an interesting thing where to me when we feel this burden as a maintainer it's this trap I put on myself. Nothing is forcing me to continue working other than the fact I choose to continue to do it. That self-motivating factor this negative idea that if you stop working on this the "world will end" or everyone's lives will be worse doesn't help and contributes to the further working and frustration of working. I kind of talk about this in github.com/hzoo/maintainer-heal-th... (there's a stream link but kinda low quality).
I still deal with this all the time (even now so I should take my own advice 😂), but I think maybe in a few ways.
Simplest/obvious solution that we don't want ever want to do - stop working on whatever is taking time that isn't actually priority/necessary (in this case open source). Free up the time and get the rest of life in order because most likely something else is suffering as a result (could be work, relationships, money, or in my case health). So that is more of a lifestyle/physical change?
Maybe next is probably more of a change in attitude/motivation. Really think about why you are doing open source in the first place and the reason it feels like everything is falling down. Are you scared that the project will die, or it will become useless, or that if you stop then who else will take over, etc? I think it's an opportunity to look at yourself and see the pride you may have: do I really think I'm the only own capable of doing it? Maybe I should solely focus on training someone else, asking the community, learning to delegate, learning to trust? Maybe remember why you started doing open source in the first place and why you aren't feeling or doing that anymore. Maybe you just need to focus on the things you are interested in, after all you can decide that as a maintainer?
Ultimately for me it's about understanding where the feeling of burden/exhaustion/lack of passion lies. That I feel compelled to continue working despite me not actually wanting to because of various things: negativity in the community, barrage of issues, overwhelming feeling of "things" that need to be done + lack of the sense of any sort of control. But I must remember there is grace in all of that. We shouldn't be defined by our work; our identity isn't in this "thing" and I shouldn't think of myself as the "x person", otherwise I really am trapping myself and cannot leave. I think about whether I'm feeling some sort of entitlement/pride/unfairness and bring that up to God. Sometimes you can get lost in yourself trying to help others and forget what it's all about in the first place, that the work itself becomes the source of joy and not people. If all this "doing" is causing more trouble, maybe it's the source of trouble in the heart? Maybe all these activities and busyness shows that it's impossible to keep up and that a certain focus/clarity is absolutely necessary, that "no" is also a viable answer. Maybe in trying to doing everything you end up being able to do nothing, and the core of what it's all about is lost. Rest!
"Come to me, all who labor and are heavy laden, and I will give you rest. Take my yoke upon you, and learn from me, for I am gentle and lowly in heart, and you will find rest for your souls. For my yoke is easy, and my burden is light."