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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
Well, as one of the maintainers besides working on core, and loaders/plugins, my role is to rep the voice of all of you to the core team, and also the other way around. Just here to help :)
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!!!
Hah, nice. Sounds like you guys are pretty on top of things :)
Afraid I'm not nearly caught up on webpack best practices to take a good whack at it, hah
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.
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.
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.
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.
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).
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.
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.
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?