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.