6 ms·

Looking at the list of changes (https://webpack.js.org/guides/migrating/ https://webpack.js.org/guides/migrating/), it seems like a lot of "magic" has been remo

Looking at the list of changes (https://webpack.js.org/guides/migrating/ https://webpack.js.org/guides/migrating/), it seems like a lot of "magic" has been removed. That's good. It's kinda funny how this is a very frequent pattern: Build something full of magic and, as you grow more mature and hit pain points, end up removing the magic. I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves. Anyone else with the same experience?

baconomatic 10y ago
Yep, I've become very fond of explicitness. Leaves nothing to question when others are working on the same code.
fourstar 10y ago
I'm a huge fan of verbosity.
thelarkinn 10y ago
Thank you guys for the positive feed back. If you find anything quirky or just want to get involved, feel free and drop us a github issue. ️
- dictum 10y ago
  Hey Sean — I've been away from JS for a while and I'm just getting back, so I used Webpack for the first time this week. I always felt indifferent about it, and the config style felt a bit like Revenge of Grunt, but after using it and especially after reading your tweets and responses to issues on github, I finally understood why Webpack is so popular. I know project maintainers often work hard for little reward, but you're consistently gentle and helpful with beginners and people with complaints about Webpack. Thank you.
  - thelarkinn 10y ago
    Well thank you for always being candid and honest with your feedback to us. We really rely on feedback from the community who is ultimately in charge of the direction of this incredibly humbling project. This goes to more than just you, but please always feel welcome to reach out.
- abritinthebay 10y ago
  As much as a give you crap on Twitter about Webpack I have to say: it's getting better day after day. Mostly due to less magic, tbh
  - dvlsg 10y ago
    Yeah, the sheer amount of magic was definitely my largest complaint about webpack. It's nice to see that the process is becoming a bit more explicit.
zephraph 10y ago
Oh man! That exactly describes my 2016 experience. We spent the entire year working on a project at work. It started off with a lot of magic to make on-boarding other "non-technical" people easier. After the summer we began ditching magic for a simplistic approach. The thing about magic is it's just as mystical when it breaks as it is when it works. That's why it's magic.
- erikpukinskis 10y ago
  "The thing about magic is it's just as mystical when it breaks as it is when it works." That's the most concise way of describing the problem I've seen yet. I'm stealing that. Thank you!
acemarke 10y ago
Yep. That's one of the reasons why I love Redux, and why I don't quite get a lot of the complaints about it requiring "too much boilerplate". I've certainly looked for some ways to be a bit more DRY in using it, but there's also good reasons for having things like action type constants and action creator functions.
tootie 10y ago
Every time I look at my webpack config and it's nested properties with no descriptors I yearn for Maven and it's rigorously-defined XML.
- sugarpile 10y ago
  Different strokes but I just had the severe displeasure of constructing a pom.xml for the first time and I would pay good money to never do it again. I would infinitely prefer to use JS tooling over Java's in general so maybe that's not saying much.
  - tootie 10y ago
    POM is not exactly intuitive, but the configuration directives are at least discoverable. If you're using a decent IDE, all the config options and values work with autocomplete. It's also pretty trivial to generate an archetype for most common needs. Webpack is practically a blank slate.
    - Sacho 10y ago
      But that's more of a documentation issue rather than an xml/json issue - you could certainly have an xml file without a schema. I think it mainly shows the maturity of Maven vs webpack(which is currently working hard on documenting everything).
pkrefta 10y ago
For me that's one of a reasons that as full-time Ruby/RoR developer I've started learning (& loving) Python. Some time ago I've started to realize that too much is happening under-the-hood in many of the libraries I'm using and somewhat in my applications. After few months Python is much more verbose and readable for me and I don't have dilemma whenever I should I implement certain thing this or that way.
- owaislone 10y ago
  This thing kept me away from Ruby and RoR. I tried it a few times but never liked the magic after using Python/Django for a few years.
  - qwertyuiop924 10y ago
    Ruby is actually fairly good about this. RoR, OTOH...
    - hobarrera 10y ago
      The problem is that 90% of Ruby jobs are RoR jobs. It's a shame really, but true.
      - qwertyuiop924 10y ago
        It is pretty sad. Especially considering that Ruby is like Smalltalk's weird younger cousin that is actually considered acceptable in The Industry.
rl3 10y ago
I find that where there'a magic, there's usually tutorial-style documentation. Not to say there's anything wrong with tutorial-style documentation in and of itself. However, it becomes problematic when it is the only documentation. Then you just find yourself digging around in source code because the "It's easy, simple and magic!" style of documentation turned out to be woefully inadequate, if not actively confusing.
- patates 10y ago
  This situation keeps occurring especially with tooling. I guess one reason is that the tooling is there to bring in the magic in the first place. The other could be that tools being created because of the needs of a specific workflow and the magic is there because authors just wanted to have something working, then it got popular and now people want to use it in all sorts of workflows.
julenx 10y ago
> I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves. Speaking of magic or trying to be too clever with your code reminds me of the Grep Test [0], which I always try to conform. In the end it's not fun forcing others to deal with your magic. Remember: code is read way more often than it is written, so don't be lazy to type a bit more — help others. [0] http://jamie-wong.com/2013/07/12/grep-test/ http://jamie-wong.com/2013/07/12/grep-test/
fusiongyro 10y ago
Definitely. But I have come to appreciate a sprinkle of magic, especially if you can say show how the magic transforms something into something else that happens to be more verbose. Hibernate went through this too. I came to prefer myBatis, but going through JPA is nicer. JPA is certainly not less magical than Hibernate though, just the culmination of many years of work in this area. SQL Alchemy is also nice like this. The magical ORM is built on an extremely robust and well-documented relational database querying library. There's an escape hatch to reality if the magic fails you, always. Can't say that about Hibernate 3—see the HQL/Criteria API madness (again, fixed in JPA). I went through a very hyper-annotation period with Java. I have since calmed down. I still make annotations, occasionally, but I don't let them be the only route to the work. Always have the annotations help something build a configuration through a standard API, then the work happens against that configuration. You can ditch the annotations if they're a pain that way, or bridge between something else (XML probably) without writing the same code twice.
sergiotapia 10y ago
Smart defaults, allow configurations. That's the key. I learned how to use Webpack but still think it sucks and it's incredibly complicated for what it does for 90% of use cases. Smart defaults. -Then- let me configure if I need to.
- mtrpcic 10y ago
  I solved this by keeping my Webpack build process in it's own repository, with a JSON file that dictates entry and exit points for builds. When doing a new frontend project, I use git submodules to import my build pipeline and just change a few variables and I'm set.
  - matallo 10y ago
    This sounds a lot like Grunt.
- thelarkinn 10y ago
  Totally understand, now that webpack 2 is almost out the door, this is one of our top 5 overhauls we want to make. "Can we make smarter defaults" We support a lot of build targets and are agnostic to library and stack so it's going to be a challenge but with your help and the community I know we can get it done.
  - bpicolo 10y ago
    An alternative is a command line tool that could combine bits: webpack-make --scss --hot-middleware --blah or something, potentially?
    - thelarkinn 10y ago
      Do I have a github issue for you!!!! This is a feature tons of people ask for all the time so this week I officially marked it as RFC. https://github.com/webpack/webpack/issues/3466 https://github.com/webpack/webpack/issues/3466 Since the core team needs to focus on implementing more opt features like rollup and better top level minification, we left this for a chunk of our contribute team to help design and come up with. Help always wanted!!!
eberkund 10y ago
I used to wonder what people meant when describing "magic code" but after using a dynamic language MVC framework and seeing how things can be done different ways I have realized that mostly what people mean by that expression is using strings to indicate what code should be called rather than the features of the language. I'm somewhat undecided still on what to think of these sorts of patterns.
qwertyuiop924 10y ago
I avoid any library that is too magical. If a project asks you to just run this magical tool that will organize your source tree just so, and then it asks you to put your source code for each thing in a certain place, and don't worry about anything, it'll just work (cough cough RoR cough cough), then I'm not interested. Because sooner or later, it won't just work. And then I'll have to figure out what went wrong, which you won't have told us how to do.
bryanrasmussen 10y ago
The problem with magic - and I think it's the problem in webpack's case - is that magic is often predicated not on a clear model of how things work in your system but just a list of use cases that will be automatically handled without you having to think. However I think that if you have a clear model of how everything works you don't need that much magic because building the solution to any particular use case is not really an onerous task in itself.

baconomatic 10y ago

Yep, I've become very fond of explicitness. Leaves nothing to question when others are working on the same code.

fourstar 10y ago

I'm a huge fan of verbosity.

thelarkinn 10y ago

Thank you guys for the positive feed back. If you find anything quirky or just want to get involved, feel free and drop us a github issue. ️

dictum 10y ago
Hey Sean — I've been away from JS for a while and I'm just getting back, so I used Webpack for the first time this week. I always felt indifferent about it, and the config style felt a bit like Revenge of Grunt, but after using it and especially after reading your tweets and responses to issues on github, I finally understood why Webpack is so popular. I know project maintainers often work hard for little reward, but you're consistently gentle and helpful with beginners and people with complaints about Webpack. Thank you.
- thelarkinn 10y ago
  Well thank you for always being candid and honest with your feedback to us. We really rely on feedback from the community who is ultimately in charge of the direction of this incredibly humbling project. This goes to more than just you, but please always feel welcome to reach out.
abritinthebay 10y ago
As much as a give you crap on Twitter about Webpack I have to say: it's getting better day after day. Mostly due to less magic, tbh
- dvlsg 10y ago
  Yeah, the sheer amount of magic was definitely my largest complaint about webpack. It's nice to see that the process is becoming a bit more explicit.

zephraph 10y ago

Oh man! That exactly describes my 2016 experience. We spent the entire year working on a project at work. It started off with a lot of magic to make on-boarding other "non-technical" people easier. After the summer we began ditching magic for a simplistic approach. The thing about magic is it's just as mystical when it breaks as it is when it works. That's why it's magic.

erikpukinskis 10y ago
"The thing about magic is it's just as mystical when it breaks as it is when it works." That's the most concise way of describing the problem I've seen yet. I'm stealing that. Thank you!

acemarke 10y ago

Yep. That's one of the reasons why I love Redux, and why I don't quite get a lot of the complaints about it requiring "too much boilerplate". I've certainly looked for some ways to be a bit more DRY in using it, but there's also good reasons for having things like action type constants and action creator functions.

tootie 10y ago

Every time I look at my webpack config and it's nested properties with no descriptors I yearn for Maven and it's rigorously-defined XML.

sugarpile 10y ago
Different strokes but I just had the severe displeasure of constructing a pom.xml for the first time and I would pay good money to never do it again. I would infinitely prefer to use JS tooling over Java's in general so maybe that's not saying much.
- tootie 10y ago
  POM is not exactly intuitive, but the configuration directives are at least discoverable. If you're using a decent IDE, all the config options and values work with autocomplete. It's also pretty trivial to generate an archetype for most common needs. Webpack is practically a blank slate.
  - Sacho 10y ago
    But that's more of a documentation issue rather than an xml/json issue - you could certainly have an xml file without a schema. I think it mainly shows the maturity of Maven vs webpack(which is currently working hard on documenting everything).

pkrefta 10y ago

For me that's one of a reasons that as full-time Ruby/RoR developer I've started learning (& loving) Python. Some time ago I've started to realize that too much is happening under-the-hood in many of the libraries I'm using and somewhat in my applications. After few months Python is much more verbose and readable for me and I don't have dilemma whenever I should I implement certain thing this or that way.

owaislone 10y ago
This thing kept me away from Ruby and RoR. I tried it a few times but never liked the magic after using Python/Django for a few years.
- qwertyuiop924 10y ago
  Ruby is actually fairly good about this. RoR, OTOH...
  - hobarrera 10y ago
    The problem is that 90% of Ruby jobs are RoR jobs. It's a shame really, but true.
    - qwertyuiop924 10y ago
      It is pretty sad. Especially considering that Ruby is like Smalltalk's weird younger cousin that is actually considered acceptable in The Industry.

rl3 10y ago

I find that where there'a magic, there's usually tutorial-style documentation. Not to say there's anything wrong with tutorial-style documentation in and of itself. However, it becomes problematic when it is the only documentation. Then you just find yourself digging around in source code because the "It's easy, simple and magic!" style of documentation turned out to be woefully inadequate, if not actively confusing.

patates 10y ago
This situation keeps occurring especially with tooling. I guess one reason is that the tooling is there to bring in the magic in the first place. The other could be that tools being created because of the needs of a specific workflow and the magic is there because authors just wanted to have something working, then it got popular and now people want to use it in all sorts of workflows.

julenx 10y ago

> I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves. Speaking of magic or trying to be too clever with your code reminds me of the Grep Test [0], which I always try to conform. In the end it's not fun forcing others to deal with your magic. Remember: code is read way more often than it is written, so don't be lazy to type a bit more — help others. [0] http://jamie-wong.com/2013/07/12/grep-test/ http://jamie-wong.com/2013/07/12/grep-test/

fusiongyro 10y ago

Definitely. But I have come to appreciate a sprinkle of magic, especially if you can say show how the magic transforms something into something else that happens to be more verbose. Hibernate went through this too. I came to prefer myBatis, but going through JPA is nicer. JPA is certainly not less magical than Hibernate though, just the culmination of many years of work in this area. SQL Alchemy is also nice like this. The magical ORM is built on an extremely robust and well-documented relational database querying library. There's an escape hatch to reality if the magic fails you, always. Can't say that about Hibernate 3—see the HQL/Criteria API madness (again, fixed in JPA). I went through a very hyper-annotation period with Java. I have since calmed down. I still make annotations, occasionally, but I don't let them be the only route to the work. Always have the annotations help something build a configuration through a standard API, then the work happens against that configuration. You can ditch the annotations if they're a pain that way, or bridge between something else (XML probably) without writing the same code twice.

sergiotapia 10y ago

Smart defaults, allow configurations. That's the key. I learned how to use Webpack but still think it sucks and it's incredibly complicated for what it does for 90% of use cases. Smart defaults. -Then- let me configure if I need to.

mtrpcic 10y ago
I solved this by keeping my Webpack build process in it's own repository, with a JSON file that dictates entry and exit points for builds. When doing a new frontend project, I use git submodules to import my build pipeline and just change a few variables and I'm set.
- matallo 10y ago
  This sounds a lot like Grunt.
thelarkinn 10y ago
Totally understand, now that webpack 2 is almost out the door, this is one of our top 5 overhauls we want to make. "Can we make smarter defaults" We support a lot of build targets and are agnostic to library and stack so it's going to be a challenge but with your help and the community I know we can get it done.
- bpicolo 10y ago
  An alternative is a command line tool that could combine bits: webpack-make --scss --hot-middleware --blah or something, potentially?
  - thelarkinn 10y ago
    Do I have a github issue for you!!!! This is a feature tons of people ask for all the time so this week I officially marked it as RFC. https://github.com/webpack/webpack/issues/3466 https://github.com/webpack/webpack/issues/3466 Since the core team needs to focus on implementing more opt features like rollup and better top level minification, we left this for a chunk of our contribute team to help design and come up with. Help always wanted!!!

eberkund 10y ago

I used to wonder what people meant when describing "magic code" but after using a dynamic language MVC framework and seeing how things can be done different ways I have realized that mostly what people mean by that expression is using strings to indicate what code should be called rather than the features of the language. I'm somewhat undecided still on what to think of these sorts of patterns.

qwertyuiop924 10y ago

I avoid any library that is too magical. If a project asks you to just run this magical tool that will organize your source tree just so, and then it asks you to put your source code for each thing in a certain place, and don't worry about anything, it'll just work (cough cough RoR cough cough), then I'm not interested. Because sooner or later, it won't just work. And then I'll have to figure out what went wrong, which you won't have told us how to do.

bryanrasmussen 10y ago

The problem with magic - and I think it's the problem in webpack's case - is that magic is often predicated not on a clear model of how things work in your system but just a list of use cases that will be automatically handled without you having to think. However I think that if you have a clear model of how everything works you don't need that much magic because building the solution to any particular use case is not really an onerous task in itself.