DEV Community

Ben Halpern
Ben Halpern

Posted on

I'm having some "not this again" feelings with Parcel, how should I be feeling about this tool?

It seems like yesterday Webpack emerged as the most viable option for bundling JavaScript. I still have a lot of tooling fatigue, especially since Rails really bought into Webpack.

Parcel does seem pretty great, but I feel like I'm still having a hard time with so much bleeding edge stuff in JS world.

How are you feeling about this tooling landscape, I'd love to just chat this out a bit.

Top comments (51)

Collapse
 
jamesmh profile image
James Hickey

I was thinking about trying out parcel... but for most of the stuff I just need webpack for vuejs + sass. I already have a working webpack config that I can just copy from project to project that works great.

I am tired of learning about more bundlers. I just want to build my apps.

Collapse
 
entrptaher profile image
Md Abu Taher

"I am tired of learning about more bundlers. I just want to build my apps." Ah, best comment ever about bundlers.

Collapse
 
v6 profile image
🦄N B🛡

// , What, no obligatory xkcd?

Collapse
 
shubhamsinha profile image
Shubham Sinha

Parcel has really a very small learning curve. And if your feel parcel is gaining momentum you can invest in it

Collapse
 
jamesmh profile image
James Hickey

I agree - it does look super easy! The only thing is I know from experience that at some point there will always be "something" that doesn't work properly or "something" that is an advanced feature that requires more digging.

I'm trying to make sure my learning is very focused (using a plan) and parcel just isn't on there.

But again, I agree, it does look very promising and - at first glance - very attractive.

Thread Thread
 
georgecoldham profile image
George

Care to share your plan, or at least how you planned? My learning is scattered and needs focusing to keep making progress.

Collapse
 
nektro profile image
Meghan (she/her)

still using gulp here!

Collapse
 
markerikson profile image
Mark Erikson

What's the concern? Just because a specific tool exists doesn't mean you have to use it, or even have to learn how to use it.

It can be helpful to know that various tools exist, so that you can evaluate them later on if and when there's a need to make a decision, but otherwise it's totally fine to stick with your current toolset.

In this specific case, Parcel looks like it's got some interesting ideas, and it might be worth looking at if you're starting a new project from scratch, but there's no need to go throw out an existing project's build config just because Parcel exists.

Collapse
 
ben profile image
Ben Halpern

This is all true.

Collapse
 
thomasjunkos profile image
Thomas Junkツ • Edited

And there is just a renaissace (or breakthrough) of brunch :D

How are you feeling about this tooling landscape

Javascript tooling is really evolving in a fast pace. Which is in itself a good thing. People are working on improvements everywhere. For many different problems there are a variety of solutions to pick from. So in terms of supply and demand, it is a nice market.

The only thing which in my eyes causes problems is the overoptimistic attitude of people, trying to learn the latest and greatest in order to feel their skillset staying sharp.

It's a bit like developers became some kind of fashion victim: »Oh, what you are still using $blerg when everybody else is using $blarg. This is so 2017«.

Another problem I see is big insecurty: Becuase of having (too) many choices people are afraid of making the wrong choices (which is not even limited to the javascript ecosystem).
»What framework should I use to accomplish X?«

My standard answer to this:
»Pick the one you are understanding fast and feel the most productive with«

Most of the time, projects or companies die before they feel any serious pain because of wrong technological choices. And if they survived up to that point, they have enough money to pay people making the right decisions for them.

My approach to this in general, or parcel in special is purely hedonistic:
If I find a minute, I have a look at it and play with it. If not, it's okay - I know, it's there; and when webpack at some point in the future should make me cry (again), I'll give it a try. If it's fun, I'll use it. If I am bored. I leave it.

OTOH, I've been long enough in the industry to have learned, that all tools/languages are in one way or the other "crap". And sometimes it is better to stay with "crap you know". There are less bad surprises waiting.

Collapse
 
avalander profile image
Avalander

I usually don't look much into new stuff until I've heard about it for a while and it looks like it's getting widely adopted, or I have a specific interest in it.

I didn't move into Webpack until I felt it was becoming the most commonly used bundler and I had some issues with Gulp.

So far I'm happy with Webpack and I haven't looked into Parcel or Rollup at all. Webpack solves my problems and it's still actively developed and getting good updates, so I don't see any reason to change.

Collapse
 
orels1 profile image
orels1 • Edited

I use parcel for "on the spot" things, experiments and prototypes.
It's just nice to get all the benefits of modern JS just by writing a basic index.html and doing parcel index.html.

But for larger and long-term stuff I would still prefer webpack. And nowdays, with webpack 4 - it's pretty easy to have a simple setup, thanks to their advances with sensible defaults.

TL;DR every tool has its job. IMHO - parcel really shines for quick bits, no need to go to codesandbox or any other service like that to have a one-click modern environment anymore.

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

I still feel the same as my last post on the topic -- I hate front end build processes.

My disappointment with front end processes is very influenced by using Visual Studio all these years. It has templates which automatically setup the build processes. Then the IDE does a decent job of keeping the build process up to date as you use it. Example, when you Add New File from the UI, it also adds that file to the build template. If you add a source file, it will be added to the compile list. If you add a content file, it will be copied to the output as-is. And you can adjust the behavior on the file's properties. In effect, file organization is a separate concern from file build settings... you don't have to put certain files in static and other files in src to get it to build correctly. Nor maintain build configurations for each file by hand.

The IDE cannot do everything you might ever need -- in which case you can use the command-line build tools and scripts -- but it does a great job of covering standard cases. I've never really needed to write command-line build scripts until recently with .NET Core. And that is mostly to build docker images. VS added Docker image build support in 15.7, but I had major issues with it for multi-container projects. So I'm building the images with scripts.

But front end basically has very limited coverage of even common cases. You are expected to write custom builds from the get-go. It is such a large barrier to entry that many setup tools have sprung up such as Create React App to start you off right. If I take a lesson from VS, what we really need is some build template support integrated into editors so they can manage common cases and just let me worry about coding my features. Maybe "IDEs" are not so bad after all.

Collapse
 
bhgsbatista profile image
Samuel Batista

I felt the same way until I started a new project and tried out Parcel. It's now my goto choice, unless the project is already built and working with another bundler.

parcel index.html

That's pretty much all there is to parcel.

Collapse
 
sgolovine profile image
Sunny Golovine

I recently moved my portfolio site from create-react-app to parcel. Parcel is GREAT. I can't speak for how well it will work for large scale projects with custom webpack configs but for smaller ones I can see it working very well.

Collapse
 
matteojoliveau profile image
Matteo Joliveau

Well, Parcel would be interesting if it wasn't for Webpack 4, which is config-less (or better, it is strongly designed to work in a convention-over-configuration way to the point that if you follow its way of thinking you need little to no configuration) the same way Parcel is.

Put together a folder with package.json, index.html and src/index.js and run webpack from the command line. Your webpack project is served.

Collapse
 
shubhamsinha profile image
Shubham Sinha • Edited

I keep and open mind to it. There are many alternative for everything in JS world. Parcel does have an edge over webpack when it comes to learning curve. If you're the guy making decisions on what bundlers, framework, state management package your team will be using, it's your duty to try out new stuff. If you keep on working on same set of tools, you're bound to get bored. That's how developer work. They're tired of trying out new stuffs and bored of using old stuff. I feel when you feel the burden of using new tool, ask someone new in the team to implement it and compare it with the present setup. Thus the new guy will enjoy working on something new and big and you'll not feel fatigue.

Collapse
 
jrop profile image
Jonathan Apodaca

The best thing about JavaScript is also the worst: everything is in userland, which can tend to anarchy at times. However, it does yield (multiple) killer tools that everybody chooses from regarding which to use.

"Your greatest strength is also your greatest weakness."

Collapse
 
tux0r profile image
tux0r

I'm still having a hard time with so much bleeding edge stuff in JS world.

And rightfully so. The JS world seems to revolve around itself a lot.

Collapse
 
ben profile image
Ben Halpern

I'm sort of expecting that Rails will lean into Webpack and forget about the new hotness, even if it's kind of great, which is fine for my world.

Collapse
 
adrienpoly profile image
Adrien Poly

The good news is I don't think Rails will drop Webpack any soon, the goal is really to make it the default in Rails 6.
github.com/rails/rails/pull/33079

As for Parcel, I use it only when I need to test something really quick.

Thread Thread
 
jrop profile image
Jonathan Apodaca

And, even then, there's usually create-*-app

Thread Thread
 
adrienpoly profile image
Adrien Poly

exactly. I am just missing the create-vanilla-app... or I don't know it :)

Collapse
 
nepeckman profile image
nepeckman

Parcel fits a niche in the tool ecosystem that is much different from the one Webpack occupies. Webpack is a very flexible and powerful tool, but this comes at the expense of complexity. I'd argue a lot of complexity. There's a reason that there exist so many tools that have the sole purpose of managing webpack configs and project structure. Parcel sacrifices a lot of this flexibility and power for speed and simplicity. It gives you default access to a lot of features that take time and setup in webpack. But if your codebase has specific needs that parcel doesn't understand, it may lack the flexibility needed to build your project.

I personally hope that parcel gains traction in projects with straightforward needs. If all you need to do is basic module imports and cache busting, webpack is overkill. On the other hand, if your build is very specific and complicated, parcel probably won't fill your needs. It comes down to making the tradeoffs that make sense for your situation. This is my experience as someone who helped implement webpack in a very complicated legacy codebase, and also someone who used parcel for some side projects that were small in scope and complexity.

Collapse
 
jrohatiner profile image
Judith

I went thru tooling fatigue for a while and finally decided to stay with the most stable, long-term supported projects as my go-tos (like webpack). I did that, not because I reject new, exciting stuff; but because I have to limit the amount of time I spend getting a project from dev to prod. Its that simple. I can't learn everything; but I can pick and choose what my toolbox is made of and know how to use what I have. That being said, there are pros and cons to being strictly frontend and not writing in a compiled language like C++. @kspeakman makes a good point about using Visual Studio and not having to worry about browser options for compiling. What I really think is that over the last five years js has mutated in an "out-of-control way" and frontend devs have had to suffer through its gigantic growing pains. I really love js but sometimes its just easier build those features on to a .net base. That's why I think .net core is a good fit for some of my projects.

Collapse
 
graemeworthy profile image
Graeme Worthy

I've experienced tooling fatigue as well, and it can be refreshing to realize that you can just keep using the tool you used yesterday, it still works.

You can get your focus and your energy back by stepping off the hamster-wheel, and focusing on building what you came here to build rather than re-writing every time a new library is announced.