Webpack 4 course: What is Webpack?

https://wanago.io/2018/07/16/webpack-4-course-part-one-entry-output-and-es6-modules/

by mwanago • 8 years ago

70 65 8 years ago

nailer7• 8 years ago

ES6 modules will hopefully be great in a few years, but I just redid my own site https://mikemaccana.com (it's a nice, small project) to learn ES6 modules and some other new tech, and the lack of a repository even a hundredth the size of npm means you'll be spending a bunch of time downloading files, editing exports, and fixing dependencies between code. I'd be hesitant to use ES6 modules for a larger project as a result.

npm Inc recently joined TC39 so maybe that will change. Also if deno takes off, it's ES6 modules only.

ealhad2• 8 years ago

FYI, your site is kinda broken on my laptop (both Firefox and Chromium), I can only see part of the text at the bottom. You might want to tinker with that middle section with the slides.

nailer7• 8 years ago

Thanks for the heads up, I'll have a play. What's the vertical height of your display and zoom level?

_Codemonkeyism2• 8 years ago

Webpack4 got much slower with startup and recompilation of TS compared to 3.

noir_lord3• 8 years ago

Curious that wasn't my experience, it was about the same.

johnny_reilly• 8 years ago

ts-loader / fork-ts-checker-webpack-plugin maintainer here. I'm sorry to hear that's been your experience. It hasn't been my own; it could be worth you comparing your setup with one of the examples available. These are some good candidates:

https://github.com/TypeStrong/ts-loader/tree/master/examples...

https://github.com/TypeStrong/ts-loader/tree/master/examples... (written by Kenneth Chau of the Outlook.com team)

You may of course you may be using another typescript loader (there are several!). I thought it worth sharing in case you are using ts-loader and your config is catching you out.

Best of luck!

noir_lord3• 8 years ago

As a ts-loader/fork-ts user thank you for all the work you do!.

_Codemonkeyism2• 8 years ago

Thanks a lot, I really appreciate your comment and will take a look. Keep up the great work!

alexanderchr• 8 years ago

If you use Babel 7 alongside TS you can use the typescript preset to speed up builds a lot. The downside is that you don’t get typechecking on compilation.

divan6• 8 years ago

https://www.quora.com/What-is-accidental-complexity

pluma2• 8 years ago

If you think Webpack is solving an easy problem, you don't understand the problem.

divan6• 8 years ago

I do not think so. And I think Webpack actually clearly shows the way where JS ecosystem goes – creating one layer of complexity on top of another. Each new layer, of course, solves the problem (not an easy one) of the previous one, but creates new problems, that will be resolved by the next layer.

Essential complexity in this case is just a need to run a code. That's it. I just want to run one command, with one or two switches max, and get the result running in a browser.

Accidental complexity is when you have a tool that 99% of developers couldn't quickly grasp and need to spend many hours studying courses or reading books (!) on Webpack.

Someone should stop this madness.

Back in 1975 (43 years ago!) Tony Hoare said:

"The pursuit of complexity is easy... But the pursuit of simplicity is one of the most difficult and challenging activities of the human mind. Progress is likely to be extremely slow, where each complexity eliminated must be hailed as a breakthrough. We need not only brilliance of intellect but breadth of experience, nicety of judgement, excellence of taste, and even more than our fair share of good luck. And finally we need a puritanical rejection of the temptations of features and facilities, and a passionate devotion to the principles of purity, simplicity and elegance."

sametmax9• 8 years ago

Babel is solving a complex problem.

Webpack is not.

Webpack is basically a task runner, a bungler and a configuration system. It relies on plugins to do anything hard.

The fact it's breaking compat again is so few years itself is alarming.

But it's crazy that a tool that only glues things together is still unable to provide a better API that it currently is.

sebazzz• 8 years ago

Do you have an better alternative? I haven't seen other tools which have a community this large, do automatic bundling and can handle (through plugins) all kinds of inputs. But that may just be my ignorance.

sametmax9• 8 years ago

There is a reason we use this terrible tool: it's the only one that does everything it does.

That doesn't make it good.

It's like JS itself: it's a horrible language, but it's the only one that runs natively all popular web browsers.

When you have a monopoly, you don't need to be good. You just need to be here.

sametmax9• 8 years ago

And it's an accident that could have been prevented.

The JS ecosystem looks like an isolated entity that contracted amnesia and a learning disability. It then proceeded to remake every single mistake done in 30 years of prior art, while ignoring every other communities warning again and again about it.

And to add insult to injury, devs from the community answered that everything was fine, and that it was us who didn't understand, and failed to live in modern times.

It's getting better. But it took a while because so many JS devs have only ever coded in JS, giving them an incomplete and crooked big picture.

onion-soup• 8 years ago

What is Webpack?

A several horrific hours of googling how to fix its configs so that it just works

lwansbrough• 8 years ago

What is Webpack?

A question you’ll find yourself Googling every month as the “best approaches” change.

gedy• 8 years ago

I hear this trope here a lot, always seems to gloss over what webpack improved on, which is replacing bespoke build scripts for web projects. Also that it greatly reduced the ye olde tradition of coding to the least common denominator subset of features that runs on all browsers. Webpack was and is awesome for that.

sametmax9• 8 years ago

The fact having a broken arm is better than having aids doesn't mean breaking an arm is nice.

lucisferre• 8 years ago

coding to the least common denominator subset of features that runs on all browsers

Did Webpack do that or did Babel?

dxhdr2• 8 years ago

replacing bespoke build scripts for web projects

Does it, though? No project of moderate complexity will be able to reuse a Webpack config. Conversely, how large of a problem was this for simple sites?

jlebrech• 8 years ago

it shouldn't be config based, should be a DSL or a library that's verbose enough to understand the workings of.

YuukiRey• 8 years ago

Interesting that you should mention it. This talk https://www.youtube.com/watch?v=mVVNJKv9esE mentions some arguments why a DSL would not be a good approach for frontend/JS build tools. Namely that a DSL isn't adequate if the underlying best practices or requirements change a lot. That's why operating at a higher level of abstraction (function chaining/piping/composition) would make more sense.

Now... that doesn't really favor Webpack. And I still don't quite understand why that tool is so popular.

epicide2• 8 years ago

I have spent many hours on many versions of WebPack for code that has gone to production for a large company. I cannot give any more detail than that.

WebPack 1.x was very powerful but very difficult to understand and configure. There weren’t a lot of sane defaults and the docs did very little to adequately explain the core concepts. The problem(s) WebPack wolves are pretty complex and I haven’t seen anything else do quite what it does.

Starting with 2.x, the docs are great. They explain the concepts pretty well. They give you basic setups and examples throughout. 2+ also has a simplified base config: you only need a few items in your config to start getting some pretty big benefits.

While WebPack was not the first and certainly isn’t the only tool that provides what it does, it does provide a sort of one stop shop for a lot of what used to be separate tools. I don’t feel like it locks me in however.

Along with the ability to minify and other such “utility” functions (which you don’t have to do with WebPack), you get things like tree shaking. This can drastically shrink your final bundle.

As someone who does a lot of UI development, it’s also nice to be able to use ES2015 features like import without having to worry.

tl;dr I see complaints about WebPack being complicated and config heavy. It used (1.x) to be exactly that. It’s much better and the benefits from using it far beyond worth the (now little) upfront learning IMO.

sametmax9• 8 years ago

The problem(s) WebPack wolves

This is such a great typo. I'm going to keep this sentence next time I need to explain webpack in my trainings.

swaggyBoatswain• 8 years ago

Something that should be avoided unless you really need it

Raed667• 8 years ago

For those intimidated by the webpack config you should check parcel : https://parceljs.org/

onion2k2• 8 years ago

ParcelJS was great before Webpack 4, but now Webpack has a very good zero config mode you don't really need ParcelJS. It's still nice though.

sametmax9• 8 years ago

Zero config offer only limited features. And if you want to add any one more, you are back to conf everything from scratch, including the zero conf stuff.

create-react-app and vue-cli and much better designed in that regard. And yet they are using webpack.

External projects manage to be better at webpack than the webpack team.

weiming4• 8 years ago

My pet peeve is each one of these (Webpack, Parcel, Brunch, $your_favorite_alternative) involves a very bloated node_modules folder and so many dependencies that no sane person with have time to verify by hand.

A vanilla install of Phoenix with Brunch yields a node_modules with 388 packages. What are the odds of one of them becoming rogue due to a hack, and how would I know?

Add to this the overall (perhaps perceived) fragility of having to maintain a node project and fumbling with JavaScript. Node was a great new thing for server-side stuff, but whose idea was it to start using it for building every single command-line tool?

onion2k2• 8 years ago

A vanilla install of Phoenix with Brunch yields a node_modules with 388 packages

Look at what Phoenix (https://hexdocs.pm/phoenix/overview.html) and Brunch (https://brunch.io/) can do. To suggest 388 packages for all that stuff is too much is ridiculous - there's a lot of functionality, so there's a lot of code. The fact that it's not one huge, opaque blob is a good thing. Could they be implemented with less code? Maybe. Does that mean they'd be better for it? I don't think I've ever come across a reasonable argument that says 'less code is always better'.

You could very reasonably argue that you don't need all those features, and maybe the two things are bloated. I would suggest that means you've picked two things that do way more than you need, and you've not chosen your tech stack very well.

weiming4• 8 years ago

Phoenix is actually very agnostic as far as asset packaging goes, one can swap Brunch for Webpack or Parcel (or nothing) easily. So it's not to say those 300+ build-time-only node packages have anything to do with Phoenix (or Elixir, or Erlang's) ability.

AluminiumPoint• 8 years ago

there are many reasons while less code is better -- https://blog.codinghorror.com/the-best-code-is-no-code-at-al...

"very new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity."

More code, more bugs, more issues. 388 packages is ridiculous compared to practically every major system including operating systems. Javascript is Stockholm syndrome.

sametmax9• 8 years ago

Look at all what django does.

It has one dependancy.

No, there are 2 reasons for this dependency creep:

- the fact JS has a so few features and such a little stdlib. So everyone has to rewrite even basic stuff.

- the community culture toward stability, maintenance and future proofing is almost inexistent in JS.

Too many JS devs have only ever coded in JS. This give them have a very twisted, unbalanced view of programming.

duhi883• 8 years ago

It's a common pattern in JS to use many small packages over fewer large ones. Some maintainers might take this too far, breaking their package up so that each function gets its own package. That is how you get 388 dependencies in complex packages.

pjmlp• 8 years ago

For those on .NET, we now have LibMan to save us.

https://blogs.msdn.microsoft.com/webdev/2018/04/17/library-m...

ausjke• 8 years ago

Again, nodejs really pushes me away when each 'npm install' could install god knows how many modules/dependencies in that I have absolutely no idea or control, it just feels so bloated and unsafe sometimes.

because of that, plus now it is also used for frontend, it is no surprise the "packaging" tool becomes mandatory and complex.

so it's not really webpack's fault.

dxhdr2• 8 years ago

Here's a great article for learning Webpack step by step, starting from first principles: https://what-problem-does-it-solve.com/webpack/index.html

It also has a fantastic summary at the end describing what's wrong with Webpack and how to write better tools.

Webpack 4 course: What is Webpack?

Related Stories