Hacker News Reader

Comment by joemanaco | Hacker News Reader

Haven't looked deeper in it, but why does it happen all the time that people think they can fix complexity by adding another layer of complexity too it?

View on HN

That's a fair point. I don't know what the best solution to this problem is, but I do think there's a problem.

Requiring the users to install 20 or more dependencies (@babel/, @postcss/, webpack-*, etc.) and write dozens of lines of configuration every time just doesn't feel right (or maybe it is..).

And we know what the developers need, they need to bundle a web project in a way that's optimised for production, js and css compiled to run on N (configurable) most recent browsers (optionally). But that's not that trivial in webpack, if it was, perhaps we wouldn't have so many abstractions trying to improve upon status quo.

Perhaps that's just an inherently difficult problem. E.g. there are many many ways to handle CSS, people use variety of transpilations such as TypeScript or Flow, projects have different requirements.

Another data point is that Parcel this problem in a much more "everything works automatically" way and it's really resonating with people.

Despite its apparent complexity, webpack is much more suited for the common case than it is for use cases with more complex requirements. To make an analogy, webpack is the HighCharts of the js build system. If you just need a chart it’s fine for that, or if you need to configure the chart and they’ve thought to add that config option it’s fine for that too. But if you have something esoteric and instead need a set of composable pieces, you probably need d3. The closest thing to d3 in this analogy is probably Broccoli.js.

Ideally webpack would be a set of composable pieces and you could use a simpler API for common use cases and drop down to a more granular abstraction when needed, but unfortunately as with HighCharts/d3, going from “batteries included” to “build from scratch” can be pretty jarring.

That's an interesting perspective. I'd add that one option in those situations could be to utilise Webpack plugins. In one project we were bundling JavaScript with webpack in a service behind an online IDE. We used a couple hand rolled plugins to do custom resolving (find the packages in this memory-fs structured by name/version), caching (what is safe to reuse) and sandboxing (only allow safe requires and plugins).

There is a problem with 'critical path use cases' for complicated products.

AWS used to be easy, now it's hard, and you almost need an AWS 'devops' person for it.

There is 100% a use case for an AWS light: simpler security model, basic services etc. that was hopefully on the ramp/learning curve to 'real' aws.

Git. My god git. A random smattering of arbitrary commands from the daily nuances of Torvalds. It's barely a product, it's useful only because it's powerful, but Git should have a set of commands that encompass everything you normally need to do (and reversible i.e. 'safe'), no 'golden rules' needed. Git in 'full mode' is really an administrator level tool. The arbitrary complexity of Git is really expensive and costing everyone a lot of pain and money. As a 'product' Git could have a couple of different API layers, if it had a different history.

I don't know enough about Webpack to really be specific, but it's feasible there is a problem.

Also - the makers of Wepback should consider the fact that someone went out and did this, and there there is a 'need of some kind not being met' possibly, after all, that's why we do these things.

Completely agree with how ridiculously complex AWS is already, with new services and products added every month. To me digital ocean sort of is AWS light, also really hope it stays like this.

>> To me digital ocean sort of is AWS light, also really hope it stays like this.

DO just added Kubernetes support. Despite being pretty darn technical I don’t even know what kubernetes is and never intend to know.

So no, Digital Ocean is not planning to stay simple.

The eventual evolution of DO into an AWSesque service provider is how market becomes ripe for yet another 'lite' service :)

I'm not entirely sure but I see this pop up a lot with webpack. Webpack is not inherently difficult to configure, it just requires you to read the documentation. All these solutions are doing is adding what they feel are sane defaults to the webpack experience. I don't see how this would appeal to someone who knows webpack well. In my opinion these solutions are just intended for a minority of new developers. For anyone else they could roll out their own faster than they could learn how to use abstraction layers built around someone else's.

On the other side, comments like yours also pop up with the same frequency. 'Just read the documentation', which sits at 50+ pages, does not make for a good developer experience. Projects like this are a symptom of the pain developers, new and old, feel when faced with a mountain of complexity just to get a module system and ES6 working on any small project.

I'm sorry but you should have a basic understanding of something before using it, that is just common sense.

Thing is, in my experience, the configuration can get quickly very difficult when the plugins don't play nice. It's not just webpack's configuration, it's also babel and babel-loader and postcss and postcss-loader and so on. Next thing you know, you're spending hours tweaking the config to get it to work.

I wanted something that is a good fouondation for _any_ project. If it needs extending, sure. But there's not much to remove.

You could argue you don't need all those plugins, but.. I would like to use jsx, async/await, css autoprefixing, css imports, hot reloading, compile it all for older browsers, split chunks and generate html. Those seem to be expected features today (or maybe that's a wrong assumption I have)?

Generell agree with the sentiment and also the specific case here. One thing to note though is that a lot of the complexity of setting up Webpack correctly for a standard user is the very high and contradicting amount of SO/Google advice. This is caused by the (relatively) long history of Webpack and the major version jumps. A layer on top doesn't carry this baggage so may indeed reduce complexity.

Perhaps because David J. Wheeler said "We can solve any problem by introducing an extra level of indirection."

Except too many levels of indirection...

Just wrap it in an IndirectionManager and instantiate that via an IndirectionManagerFactory and you're good to go. :)

You forget the IndirectionPolicy interface...

Funny you mention that. I was considering amending my post to include IndirectionStrategy.

But I was worried about opening a Pandora's box of indirection design patterns.

I mean, who are we to assume that you want to invoke all this indirection now? Better to wrap it all in an IndirectionCommand so you can invoke it whenever you want.

And there's no need to keep too many copies of identical IndirectionCommand instances around, so you'll also want an IndirectionCommandCache class, which will of course need an IndirectionCommandCacheStrategy because you don't want to just assume you know how and for how long people will want to cache those commands.

I guess that threshold is different for everybody, who's to say what works best in a certain situation?

Isn't that what programmers do? Abstractions are great...

Excellent point, how many layers of accidental complexity are we on now? I have lost count.

Reply on news.ycombinator.com