5 ms·

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?

codereflection 8y ago
Perhaps because David J. Wheeler said "We can solve any problem by introducing an extra level of indirection."
- mpweiher 8y ago
  Except too many levels of indirection...
  - rpeden 8y ago
    Just wrap it in an IndirectionManager and instantiate that via an IndirectionManagerFactory and you're good to go. :)
    - toyg 8y ago
      You forget the IndirectionPolicy interface...
      - rpeden 8y ago
        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.
  - jitschlit 8y ago
    I guess that threshold is different for everybody, who's to say what works best in a certain situation?
jitschlit 8y ago
How else would you fix complexity if you don't want to reimplement something non-trivial? I guess its always a tradeoff: a more complex (or bigger, at any rate) implementation vs a slimmer/easier to use interface.
notus 8y ago
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.
- ricardobeat 8y ago
  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.
  - notus 8y ago
    I'm sorry but you should have a basic understanding of something before using it, that is just common sense.
- kn8 8y ago
  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)?
paultopia 8y ago
Isn't that what programmers do? Abstractions are great...
NewsAware 8y ago
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.
kn8 8y ago
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.
- mnutt 8y ago
  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.
  - kn8 8y ago
    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).
jhuni 8y ago
Excellent point, how many layers of accidental complexity are we on now? I have lost count.
sonnyblarney 8y ago
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.
- asar 8y ago
  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.
  - hguhghuff 8y ago
    >> 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.
    - itsrajju 8y ago
      The eventual evolution of DO into an AWSesque service provider is how market becomes ripe for yet another 'lite' service :)

codereflection 8y ago

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

mpweiher 8y ago
Except too many levels of indirection...
- rpeden 8y ago
  Just wrap it in an IndirectionManager and instantiate that via an IndirectionManagerFactory and you're good to go. :)
  - toyg 8y ago
    You forget the IndirectionPolicy interface...
    - rpeden 8y ago
      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.
- jitschlit 8y ago
  I guess that threshold is different for everybody, who's to say what works best in a certain situation?

jitschlit 8y ago

How else would you fix complexity if you don't want to reimplement something non-trivial? I guess its always a tradeoff: a more complex (or bigger, at any rate) implementation vs a slimmer/easier to use interface.

notus 8y ago

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.

ricardobeat 8y ago
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.
- notus 8y ago
  I'm sorry but you should have a basic understanding of something before using it, that is just common sense.
kn8 8y ago
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)?

paultopia 8y ago

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

NewsAware 8y ago

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.

kn8 8y ago

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.

mnutt 8y ago
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.
- kn8 8y ago
  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).

jhuni 8y ago

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

sonnyblarney 8y ago

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.

asar 8y ago
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.
- hguhghuff 8y ago
  >> 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.
  - itsrajju 8y ago
    The eventual evolution of DO into an AWSesque service provider is how market becomes ripe for yet another 'lite' service :)