I'll set a super high bar for you.

For your app, ship no more then 250kb JavaScript uncompressed for your initial page load. 👌

Do it.

Really. Don't get bent out of shape about it. I really dispise working on databases, apis, etc. It's boring (to me). So I would instead of worrying about not being able to go full rounded, just continue to focus on the things you love, meet people who love those things, create connections, thrive.

If you had to, just do it once to say you understand how it works.

There is a lot of work to be done still. I don't think we are anywhere close yet, especially cause I still need to understand how it works fully.

I'm a firm believer in a single compilation "unit", vs a task runner with excplicitly declared dependencies, that have to be "by hand" linked together. You gain a lot of overhead this way.

My thoughts are, what if you could compose, multiple webpack compilations, so you could have "separate" runnable build envs, but when deploying, can be one compilation for maximum performance.

I don't want to spoil too many details, however we want to prepare developers to build the web for the #NextBillionUsers, but also help foster their growth in open source for the #NextMillionContributors also. We see the webpack ecosystem as a way to help facilitate that and enable and provide more opportunities to excel!

• Modules
• Web Performance and Cost of using X vs Y
• HOW TO BREAK DOWN A JS FRAMEWORK to understand how it works.
• Modules
• WebAssembly and the JavaScript API's for it.

Arch. Philosophy

• Everything is a plugin :-D

User Philsophy

• webpack exists to let you write powerful and performant web code, without sacrificing user experience.

Brilliant.

My first contribution was made to a Ruby Gem, which used XMPP4R Ruby Chat protocol. I think I was writing a chat bot! <3

I truly entered the world of source really via webpack! How I got involved is a pretty lengthy story. But tldr, I hopped on gitter.im and made a private chat, invited the maintainers and told them I wanted to be involved. We built a relationship over a few weeks, and one day, I was asked to be apart of the team. You can check out my episode on the changelog for the whole story.

It can be, but the only caveat is that you will probably write a little JavaScript along the way. But yes totally! In the end, use whatever best suits your needs.

Awesome question!

I would say start by checking out our new documentation!!!! (webpack.js.org) We have a getting started section and a concepts section that are great for beginners.

I also released http://webpack.academy which has 2 free learning courses that mirror these concepts and documentation.

First is mentality: Accept that what you know now, may be obsolete in a month. And then with that mentality, you can have the assurance to be flexible and always try new things, and make connections on the underlying principles. I like to follow #JavaScript and folks on Twitter to stay up to date in many ways.

Yes absolutely!!!!!

My first recommendation is to take a look at an article series that I wrote just for this question.

https://medium.com/webpack/contributors-guide/

webpack has 100 repo's across two github orgs and we have so much to offer for anyone from a Technical Writer, to someone who wants to tweak graph traversal algorythms, even to someone who wants to rework some design on webpack.js.org.

So read the contributors guide, and then pick something that interests you! Then, as always you can ping me on Twitter/DM, or Tag me in a github issue and we can help answer any questions along the way.

In the end, Open Source is about people who share the same love for working on things they enjoy, and making it better for the greater good. If you can't find something you like with webpack, then we have lots of connections to other maintainers like Henry Zhu of babel who also would love to have you contribute to Babel as well.

#FollowWhatYouLove

That loaders are not the same as task runner tasks. loaders are a very imperative part of your build. If you had to learn something in and out, learn how loaders really work.

To solve all of the UX/DX/UI Concerns people had.

Also to allow webpack to be composed into multiple builds, without overhead.

Scale to cloud based builds.