I'm Sean,
I maintain webpack.
I work on Microsoft Edge DevTools.
I love ðŸ”s.
Ask.
Me.
Anything.
:-D
For further actions, you may consider blocking this person and/or reporting abuse
I'm Sean,
I maintain webpack.
I work on Microsoft Edge DevTools.
I love ðŸ”s.
Ask.
Me.
Anything.
:-D
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (114)
If someone wants to become a core contributor on a popular open source project, what would you recommend they do to get started on that path?
Maintaining a project In my opinion takes a lot of passion and love for it and it's users. So with that in mind, I'd say picking a project that you really really really enjoy.
I love webpack, the experience it gave me, and most days I can't stop obsessing about it 😂.
I guess to answer the second half is: show whatever existing team that you want to help and build and create the relationships with them over time. Gaining trust is part of how new responsibilities are handed over to potential maintainers.
Great advice. How do you keep up the motivation to keep contributing to the project?
What motivates me more then the project itself is the people behind it.
A great example. I've been working to empower and create communities outside of the US for webpack. Specifically, Africa. I had recruited some very passionate and excited individuals who wanted to lead the efforts to help grow and teach the communities there and represent their voices (in many places where I cannot). So we met and talked about a few things and some take away items. This morning, I got this image in my twitter DM's:
This left me with watery eyes and a sense of overflowing joy and pride just being able to know that there are people out there who are just as passionate and excited to help grow and build a more vibrant, diverse, and inclusive community, even globally. At the end of the day if I can change one persons life for the better, I've won. And open source and the incredible blessings it has provided me, have been the perfect vessel to continue that mission.
How did you communicate to your employer that you have outside interests/pursuits that have nothing to do with the company? Along the same lines, how do you manage your time between your day job, your OSS maintenance, and your other interests?
When I was at Mutual of Omaha, I was very up front with them about my passion for maintaining webpack, working on open source, and speaking at conferences.
Because of that honesty I think that they were more flexible and generous with the amount of time I could spend on OSS and speaking.
How do I manage my time? Honestly I don't whatsoever. There are some days I feel I'm constantly under water. (Which may sound scary, but in fact, it's an open source authors greatest asset for new contributors as long as you work hard no matter what you do). If people see me drowning, they always reach out their hand. Many of our most active contributors we're drawn to us this way.
Sean: can you please tell me, in great detail, exactly why React is better than Vue? :)
Mark to me, I'll boil it down to a few things.
Ecosystem: Vue is a grass roots community driven project. They have no business incentives. Because of this, we see things like:
Supported router - This is maintained by the Vue team, doesn't have breaking churn, and is an incredibly nice experience.
Solved completed and maintained state management - Because of this it works seamlessly with a Vue app. Most of us know...a React app looks completely different then a React+Redux app. or React+StateManagementLibrary app.
Great interaction with community best practice build tools (like webpack). Code splitting in Vue takes one line change.
import Component from './vue-component.vue';to
const Component = () => import('./vue-component.vue');Its these kind of small and juicy details that screams "We give a shit about the people who use our project and they are always first when it comes to the innovation we bring".
Syntax: Single-file-components are the future of dev in my opinion. Not only are they backed by webpack to create a killer Hot Module Replacement experience out of the box, but they also allow you to write the JSX to have fluid composition if you need to. Most cases I've found that the familiar and rich system that Vue single file components provides is usually enough for me in most cases to never have to write JSX.
Tooling: The tooling behind vuejs for vscode etc is incredible.
A feature difference that sets them apart is their eventing systems also and "dependency detection".
So instead of having to use a bunch of componentWillUpdate, Vue automatically tracks what state has changed and saves the users the cost of needed to do these kind of things in React.
See here:
Oh and. There is nothing you cannot do in Vue, that you can do in React.
So to me it's like: If you are going to choose React as a project, just use Vue instead!
UPDATE: I just realized you asked why React over Vue. lol. In which (comments below have shown me its vice versa). Sorry!
Well I can say this:
React right now is better then Vue in only one way that I can think of. It's ecosystem has a pure native solution that is pretty strongly maintained. Right now Vue has Weex and NativeScript, but I'd like to see Vue/Evan write an official Native Renderer. However that would take a lot of time, and probably not on the roadmap for vue.
Yeah, I figured you either deliberately or accidentally misread the question :)
I love how he asked "why React is better than Vue" and you answered "why Vue is better than React" :-D
Easiest way to be right is to answer the question you wish was asked.
As someone unfamiliar with Microsoft Edge, what sort of innovation is the browser bringing with it?
As for the agriculture and farming world, are there any innovations there that you are particularly interested in?
Right now, as we speak, we are working on Remote Desktop Protocols and Remote Debugging APIS. This really excited me because it opens up the opportunity for us to debug edge on every windows device. Xbox One X, Hollolense, and Everything!
So that testing story will be fun playing with the super secret hardware dev kits 😎.
If I had any it would be an easy way to harvest pumpkins. Like, common. We need that.
Sean!! Two Qs for ya:
OMG NO IVE NO TIME 😭😭😭😭😭😭
My approach is to foster an environment that enables the mentee to go from Deer in Headlights, to brave enough to try anything and ask any questions. Most of the time I've seen the problem with paired programming is that it puts developers in either role in a nervous state and doing anything I can to remove that is super effective in the learning experience.
This may have been me. But then, I see something and I'm like ILL DO THAT SOME TIME.
Hey Sean, thanks for doing this AMA!
Can you expand on your love of 🐔s and farming in general?
I feel very disconnected from agriculture and animals — sitting here behind a computer all day — so I'm curious about your experience given that you have a career in tech alongside this entire other perspective and life experience.
Well I think the connection really likes with being in tune with the source. The source of the food we eat. The source of the code we write. I also wanted to breed chickens. they are perfect specimines for genetics studies as their young hatch in 21 days. So it's awesome to see and study how chicken breeds have evolved over time.
Anyone who has worked with Webpack will know just how horrible it was to learn and get used to. The made-up-on-the-spot terminology. Confusing, lacking and unempathetic documentation. Configurations using bizarre syntax contained in a single string. Mega-ultra hideous configurations, even for simple projects and boilerplates. Unintuitive naming conventions. Lack of useful tooling. Lack of GUI's.
What is being done to bring Webpack back into the real world where real human beings desperately struggle through the process of learning this unwieldy, fragmented, clustertruck of a tool?
Hey Jake. First, thanks a lot for the candid feedback. It's stuff like this which continues to set the bar high for us.
I can't speak as much for the terminology, but I know naming are hard. What's incredible to me is that if you feel you have some great ideas or suggestions, then your are simply an issue or PR away from webpack's next great contribution. So I totally urge you to submit one with some ideas.
In terms of our documentation, we know that webpack 1 was pretty bad, but when we released webpack 2, we considered our documentation the number one feature of the release. If you haven't checked it out yet, go to webpack.js.org/. Also if you have suggestions or ideas that can help us better empathize with developers here also, we yearn for your feedback.
This is one of the hardest things we struggle with as maintainers & users of this project. The single handed largest trade-off to JavaScript as configuration is that, like all code, can be written extremely poor. My advice for now is to try and treat your webpack config with the same amount of scrutiny that you do the rest of your code. That way it is readable, approachable, etc. I cover this in a course I did on webpack.academy/!
I'm not quite sure what you mean by lack of tooling, but I definitely know that having some sort of UI or VSCode integration would be a killer feature to add to webpack in some way or another. Again, feedback, ideas, RFC's, and simply communicating with us on GitHub, etc can really help getting these great ideas flowing.
Every day, we try and work with Framework Authors, users, contributors, even browser vendors to try and empathize on a variety of different levels to understand what we can do to continue to innovate not only the performance, and internals, but also public facing API's.
To be honest, the passion burning through this paragraph makes me believe you'd be a huge positive impact on webpack through your ideas and contributions. Doesn't have to be code either, bring your best skills, and make some real positive impact on the 5million users and 9million monthly downloads that use webpack.
100% agree with this
I've heard you are a farmer + developer, which is literally my end game.
How did you do it?!?
Or more specifically, if you'd prefer, what similarities in both do you see and how does one help the other?
Do you find farm work and programming compatible in terms of scheduling, or do you often have to choose one over the other?
When I was still living in Lincoln, Nebraska the laws for owning birds and chickens is pretty flexible and loose.
So it only took owning a house, building a coop, and filling it with birds. I might say urban farmer.
I haven't followed Webpack closely in a while, but we are going to look to integrate it via Rails' Webpacker gem. What's the latest for the project? What pain points from previous versions may have been resolved?
webpack 3.6 is the latest! We've solved a lot of bugs in regards to Scope Hoisting (ModuleConcatenationPlugin). 3.6.0 is definitely the most stable version of webpack we have so far.
For the rest of the breaking changes we want to land, they will all be pushed into webpack 4.
Nice, thanks.
side note: webpacker is great! I've migrated a project from the asset pipeline to it and I would never turn back. Still have to keep the asset pipeline for ActiveAdmin though :(
Webpacker has an awesome set of defaults, I wish it were "language agnostic", a sort of a webpack starter kit.
One of the most difficult part of webpack is learning how to configure it. Particularly, setting up loaders for different workflows. I heard many times from devs that they don't understand how to configure webpack because of the config file. Anything thoughts on how to improve the setup workflow for new/expert people?
Also, what's your opinion on javascript assets loading for an HTTP2 world? Code splitting, aggressive splitting, ES6 import all the things?
I would say this is one of the biggest misconceptions out there and I believe it boils down to fundamentals.
Most people fear the config because they don't realize:
It's just a JavaScript object that is
module.exports'd.somefile.js
That's a webpack config ^^^^ .
In addition to that, I think that really people not understanding the module ecosystem, why it exists, and why we write with modules. If you've never written a CommonJS, AMD, or ES Module before, you certainly are going to have a stronger uphill battle in understanding why webpack is awesome.
In terms of the configuration properties itself, we have bent over backwards creating webpack.js.org/configuration and keeping it strictly up to date to ensure that people understand what each property does or should do. IF NOT, please please please please please please please put in an issue to our docs GitHub. We consider even issues to be significant contributions!
H2 makes bundling even more powerful. Instead of shipping 6-7 bundles/assets to a page, now you can ship 20-30 of them.
BUT THE KEY TO WEB PERF IS SHIPPING LESS CODE.
So these 20-30 JavaScript bundles shouldn't ever add up to anything more then 250kb UNCOMPRESSED. I challenge anyone to do that, and see how impactful it can be on your project and web load time.
i agree with everything you said.
the point however that understanding all that AND figuring out the exact syntax needed in the config file AND sometimes also the order of things ( things that should go before other things) is very much a high bar for new developers.
very very high bar. only god knows how many developers quit web development all together in front of that fence.
Unfortunately lots of libraries push the code size way beyond 250kb. jQuery by itself is more than 250kb
Exactly. And really that is why we see a lot of slow web today.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.