DEV Community

Adam Crockett 🌀
Adam Crockett 🌀

Posted on • Updated on

Grunt then Gulp then Webpack now Parcel 🤖🔥🤔

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 this week. 🙄😠 (Nobody likes a complaining developer but it's my birthday next week and I'm getting old)

Opening codesandbox and clicked on Vanilla, I wanted to just write some vanilla loose, quick and dirty old fashioned not complicated, not transpiled passed through a quantum molecular demodulation superconducting tree shape graph. I think it's called simple.

I am greeted with a Parcel configuration. "Hello parcel what are this file be?" I ask myself in the most efficient wording known to man. But before we get to that, let me remind you, I clicked vanilla! Why has JavaScript become a compiled first and interpreted second language, what we write is not what we ship, doesn't that bother you?

I have spent a while justifying the 10 or so config files to run a front end, "it's normal", everyone's doing it, it's just a part of life for a frontender, doesn't this bother you?

We are so busy going forward, has anyone looked back at old friends? gulp 4, that's not the gulp I remember but it's nice.

Okay so a task runner is not a bundler (a compiler of things) so yeah bad example, still my point stands. Why is JavaScript (browser vendors) not keeping up with demand, why must we have so much fluf between the code we wrote and the mangled and larger code that nobody really knows what's inside.

Lately it's got to the point, I found learning C++ and emscripten around the same amount of effort to setup as it was to build the "perfect Webpack" setup, that's crazzy, time-consuming.

Don't you wish you could just write JavaScript with optional static typing. Maybe even just have an official specification for a JSC (JavaScript compiler), Less new hotness tooling and more development?

So yeah I ask a lot of questions, on with the point of this post and the conclusion, Parcel, that sounds like Fusebox, 0 config bundler, yep that's not really new, bundling things that's like dynamic linking sort of, a dll, an .exe that's a bundle too, conceptually this is all old hat stuff. Makefiles, the OP bundler, the list goes on. None of those tools compiled scripting languages back to itself, is there something seriously wrong with
JavaScript today? 🧐

(He says all this then gets back to work programming the modern stack without any further thought)

Update: (he then wrote didi)

GitHub logo adam-cyclones / didi

Convert a project from common JS to ESmodules, with included bundler-like / task runner behaviour.

didi the dino is a pterodactyl logo

didi

A transpiler for JavaScript and Typescript, transforming CommonJS modules into distinct ES Modules

Who uses didi?

Frontend and deno developers will find didi useful.

Try it out.

didi is not ready for production however you can still take didi for a spin!

npm install -g @didi-js/client-didi-cli

# or

yarn global add @didi-js/client-didi-cli
Enter fullscreen mode Exit fullscreen mode

Create a project an entry file, some installed node_modules and then require the browser dependency into your entry file using the base specifier.

const colorThief = require('colorThief'); // base specifier example, no paths needed
Enter fullscreen mode Exit fullscreen mode

run didi path/to/example-project

The result should have output a new target directory within this example-project and also a server should have started on http://localhost:8086. You may see some console errors in the browser, this is normal for this stage.

You may also notice that your import looks like this:

import colorThief from "color-thief"; // still no path?
Enter fullscreen mode Exit fullscreen mode

Top comments (13)

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.