4 ms·
Javascript build tools seem to be the worst offenders here. I just want to transpile and bundle my app, not program a build tool by clobbering together 100 libr
by n0us 11y ago
Javascript build tools seem to be the worst offenders here. I just want to transpile and bundle my app, not program a build tool by clobbering together 100 libraries. Grunt was okay, but it was slow and required lots of configuration. Not much worked out of the box without downloading plugins.
Gulp was much much worse. Nothing worked at all out of the box and months later I still hadn't found the patience to get everything working right. Documentation was next to non-existent and there were points where I wanted to rip my hair out trying to work around "vinyl source streams", whether I needed a buffer or not, how to wrap a regular stream, how to get live reload to work, figure out why they had "blacklisted" popular modules that just made it easy to plug things in. At least it was fast but I never did get it working for some of the things I wanted to do and fell back on grunt sometimes.
Webpack is somewhat better I suppose but at this point I'm just prepared to be disillusioned every time I try some new javascript package which has maybe nulled the pain to some extent.
It isn't even that doing this stuff would be that difficult it's just that the docs are usually wrong, missing, incompatible, or outdated. No one bothers to fix them because by the time they do the JS community has just chugged along to the next "framework" leaving a trail of broken and abandoned projects in its wake.
I don't give a damn about bloat and modularity. Most of the time I'm just looking for a quick solution. If I have to download a big package so be it. Do everyone a favor and package things together that are compatible and work together so I don't have to spend hours tracking down the proper module for doing something like compiling sass and then another hour figuring out how to configure it and insert it into the build tool.
If I wanted to work on build tools then I would work on build tools but I get so tired of doing this stuff each time I need to set something up. In theory it sounds nice for there to be a million ways of getting something done but in practice I think it's just easier for someone to set a precedent for doing it one way and then have the community work on incremental improvements to that one way of doing things. This eliminates a load of confusion, incompatibility, and excess work.
All this might be an unpopular opinion but when I'm working on a project I like to direct my time towards the project, not the supporting development tools.
- BinaryIdiot 11y agoI'm with you. In fact my last project I simply wrote my own build script by including the dependencies that normally would have been wrapped with grunt / gulp and used them directly. So much easier and far fewer development dependencies. Grunt and Gulp make building slightly easier. Slightly. That's really it honestly. In fact my build scripts look very, very similar to what a Gruntfile.js file looks like.
- meric 11y agoI get what you mean. Our application broke during the Redux 3.0.4 => 3.0.5 transition because one of our other dependencies didn't play well with the new version. Yes, that is just the tip of the iceberg.
- tacomanblars 11y agoSlightly off-topic but holy cow, this! I've been describing this to many JS developers when it comes up and I find that many feel entirely the same way but we tend to not do anything about it. Gulp can use babel, babel can use webpack, webpack can do babel, it's madness frankly and yet the pattern continues. Maybe I'm beginning to become a curmudgeon but I'll just sit out of this game and use stable tooling and potentially other languages that can provide a more mature workflow. What really gets me is there are things like Dart that don't get a lot of traction though it provides mature support for a lot of the things we need to bolt on to JS to make it a usable and productive language. Not that you need those things anyway to be productive I digress.
- gkya 11y agoIn the JS community there are overkills à gogo, a cacophony of many build tools, package managers, various --pilers, minifiers, maxifiers etc. The cadence of reinvention is unfathomably fast, I don't understand how one keeps up, but I guess most of the non-problems these quasi-tools solve would easily be solved with make and some vendoring, though that is already invented and time-tested ergo bad and boring...
- userbinator 11y agoA lot of web development in general seems to be more about reinventing things as much as possible and creating problems for solutions. Then again, web design is heavily fashion-driven so that attitude pervades into everything. There is a lot of churn, often for little gain.
- kansface 11y agoI have shared your experience with front end tooling. I was recently pleasantly surprised by browserify. Next to no configuration - just a few chainable deps that are all built to work together. All in all, it took about 30 minutes from start to end to get a es6/jsx transpiler -> JS working.
- forrestthewoods 11y agoI hate the "open source way". Projects should include 100% of dependencies. Don't make me waste hours chasing down one dependency after another. My own project has it's own build pipeline. Don't force your crappy system into mine.
- mrmondo 11y agoCould not agree more, as an ops / automation engineer I find the js ecosystem to be especially terrible to deploy, manage and maintain, don't even get me started on nodejs and npm - it makes me feel sick and disheartened to see so many 'developers' succumbing to that ecosystem.
- deniska 11y agoNever managed to achieve what I want in gulp. Switched to makefiles. Make just needs executables. It doesn't need specific plugins for each compiler. Its syntax is arcane but it was much easier to make it up and running.