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... [Read Full]
markdown guide
 

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.

 

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.

 

I feel your pain. I do not envy someone who has to enter the JS environment today if they have to set up a bunch of toolchains to get even the simplest thing working. Now it's gotten almost as bad as Java. Having said that, I don't have a better idea than the webpack/parcel folks, and don't have any interest in thinking up an idea. I just write off a day of a project getting things setup the way I want, including customizing the build process to scratch any itches I might have.

 

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.

 

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.

 

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.

 

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?

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.

 

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")

 

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

 

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.

 

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.

 

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.

 

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

code of conduct - report abuse