DEV Community

Grunt then Gulp then Webpack now Parcel 🤖🔥🤔

Adam Crockett 🌀 on July 19, 2019

disclaimer: this post is not an attack on tooling specificly, nor an attack on anything. Okay so let's do another rant post, I seem to be angry th...
Collapse
 
dinsmoredesign profile image
Derek D • Edited

Bundling/compilation tools are the product of browsers not staying up to spec on language features, not a problem of JavaScript itself. Server-side languages generally can add new features to languages with the only tooling update needed being the version on the server; we can't do this in front end, because we rely on the client to serve our code. If the browsers supported more modern JS features or we could install versions as easily as we can to a server, compilation would be irrelevant.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

I think this was more inline with what I wanted to say. I have made some edits to reflect this. I know JavaScript is only as good as it's browser.

Collapse
 
daneren2005 profile image
Scott

Using Vue CLI it took about 10 minutes to get up and running. Webpack replaced the others because it did a lot more. Parcel does it better but not really anything new so I don't care about it. There are ways to abstract out the complications already.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀 • Edited

Vue cli, and NG cli both abstract Webpack to the point that it's teivial, yep that's a fair, but misses the point of my post, how many tools where needed to get to this point? It's tools upon tools upon tools heavily abstracting the route from point A to point B, simple JavaScript goes, in complex JavaScript comes out. That's what bothers me. JavaScript has become a compiled to interpret language in effect yet there is no official recognition of this fact nor compiler speciation unlike c++ where clang g++ and more all try to follow an official specification. You would hope for a singular level of tooling, a hypothetical es universal compiler of sorts that could produce an Angular, Vue, React, Vanilla and so much more, the rules for which, all coming from a governing body, simple JavaScript goes in, optimized smaller and complex JavaScript comes out. Framework would then be authored following this predictable specification, as opposed to change the tooling they are built on, trying to keep up with the next new hotness build tool.

Collapse
 
daneren2005 profile image
Scott

I'm not sure what you mean complex js comes out. The tools are to bundle, which doesn't change the code, to minify which doesn't change what the code does and does obey a spec, and to allow the latest version of the js spec while working with older browsers that don't know that syntax yet. None of that is super complex and they all solve really problems that attacking the tools doesn't solve.

Sure there other parts like single file Vue components, but they also are fairly straightforward tools that arent particularly hard to understand. I guess I have done all of this stuff without the simple method webpack provides so I understand exactly what all of these tools are doing and why they are there. Does this seem like its an interpreted language to you because what the tools are doing seems like magic?

Thread Thread
 
adam_cyclones profile image
Adam Crockett 🌀

This is no attack on any particular tool 🤯, I hope you didn't read it that way.

Complex as in this simple src code becomes larger and more complex as the features you require such as require are shipped in the bundle, const becomes var classes become functions again. Your bundle code indeed does change depending on what your doing.

I think there are crossed wires here, I will leave it at that.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

Yeah I can relate, it's good fun to setup toolchains (for a while).
I totally agree, there's probably not a better way. But this is a language level problem. Perhaps when chromium monopolies most of the web, this problem could come to decline.

Collapse
 
robertomaurizzi profile image
Roberto Maurizzi

The thing that pains me most is that if you're using things like Django or Rails, all this tooling necessities brought back the situation to 10 years ago.
There's no obvious way to go from the definition of your data to a change in the front end without manually updating things around (wasting time and possibly doing it "wrong")

Collapse
 
js2me profile image
Sergey S. Volkov • Edited

Gulp and grunt are not forgotten, some libraries and "legacy" projects still using these things for build.

Each tool for build application like gulp, rollup, grunt, webpack or parcel have own unique opportunities. For example gulp have ability of creating "custom" tasks which can do build or something else like logging. Webpack have ability to adding/creating custom loaders (not only webpack, but still).

And in summarize I can say that all things even not hyped still have popularity and unique features

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

I particularly liked gulp, it's not really in the same space as Webpack in truth. A bundler vs a task runner, a Car vs a Motorcycle.

Collapse
 
trifit profile image
David • Edited

Just curious if you are writing vanilla why do you need a task manager? Even if you don't, they are not required, there are works arround, the problem is that the works arround take more time than the to configure the task managers.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀 • Edited

Precisely, I didn't say I did need a task runner. In fact the title of the post isn't what this post ends up talking about, it's about tooling in general.

Collapse
 
pspierce profile image
pspierce

Amen. God damn serious bullshit all of it. Exhausted.