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.
Latest comments (50)
I come from a database back ground and was writing server side CGI Apps in 1994. After too long a career writing server side apps I was thrust into writing SPA's about 3 or 4 years ago. I appreciate all the innovation but good god what a mess! Starting a new project ever 6 months means having to climb a new stack of tools. ...and "transpilers???? Really. I can not for the life of me ever imagine writing an app with TS and LESS. I do understand that those innovations helped light the way for improvements to the platform standards...but it is not for me.
I am very happy that web components have matured enough that I can use them without a polyfill. That is a big step forward. NPM being the defacto standard for distributing components has apparently laid bare another issue. I am not fully versed in this but my understanding is that due to the way people prepare packages for NPM for use on node, means that when I use npm to add components to my spa I am pretty much required to use a bundler. I can't just make a relative reference to the path of the component and go. That is very frustrating. I am using parcel and it was pretty painless to setup, but debugging through source maps is a giant pain in the ass. I would really like to option to bundle without needing maps at least for development, and then bundle ..tighter...for production.
I have seen a tool called snowpack, but it would be nice not to have to use a tool to get around another tool...if you know what I mean. Not sure if this functional requirement to use a bundler is npm's problem, or the package writers....but it annoys the hell outta me.
In a perfect world, I would be able to write js code and run in the browser, no transpiling, no bundling, no minifying. No additional tools required...for anything. Then if I want to optimize my code for production, well then ya sure, line up the tools! Just strive to make the tools optional not required.
PS: The confusing stacks of tools make it very hard to newbs because code examples don't always point out what is native ES6 and what is a decorator from some tool. Having to install a different tool environment just to run some sample code is way to much to ask.
This is a pretty old article now, but after using Parcel for almost two years (since it came out, really) I feel I can add something.
I think it's good to approach any new technology with a goal in mind of how you think that technology will improve your workflow or project. If it's not going to have some tangible improvement (your personal productivity, better performance, better job prospects, etc.) you should not waste your time with it.
However, there are a few pieces of technology that I find so revolutionary that to use them improves my productivity greatly. I find Parcel to be one of those projects. I never really liked Webpack to be honest, I found it too confusing to set up with nightmare webpack configs. Parcel doesn't need any config, it's just smart enough to handle almost any file you have. It can even compile a Rust file and make it available to JavaScript via Webassembly, with no config. It knows how to handle Vue, React, ReasonML, SASS, Less, TypeScript, Elm, PostCSS, etc. etc. without config. Code splitting works great. Also, you don't have to configure how it operates in dev or production, it looks at your node env and will make the right choices for minification, not including the HMR server, etc. It's amazing. It works so well, in fact, that to convince me that there is a better way than how Parcel does things would be extremely difficult.
I've been using it for nearly two years with very little issue, building a front-end app with Mithril. There are snafus here and there but no show-stoppers yet. It actually makes me like front-end more than before because it makes it so easy to experiment with all this new tech and no need to configure or add plugins, for the most part. It actually succeeds in taking away so much friction from getting up-and-running with a new project and scales up beautifully.
I ended up tearing out Parcel out of a client project out of sheer frustration and replacing it with webpack just so I could tweak my config slightly to output separate bundles for IE.
Trying to do the same thing with Parcel was akin to pulling teeth, even though I considered it to be generally easier to grok than webpack, and I wasn't really that big of a webpack fan to begin with.
I've suffered from JS fatigue as much as any other developer has and abhorred tooling when I decided to deep-dive into vanilla JavaScript a few years ago.
Back then, I was mainly a WP page builder junkie with just enough knowledge of PHP, jQuery, HTML, and CSS to be dangerous, and I wasn't prepared for the massive onslaught of all the tooling, libraries, and seemingly endless ways to configure JS builds. It drove me nuts!
I started off with the most basic tooling possible and avoided command line tools or anything advanced like the plague. Now I can't imagine life without my current setup. Go figure!
All that said, I think it's pretty clear that webpack has pretty much become the industry standard as far as bundlers go.
My goal is to touch my tooling as little as possible, though it needs to be flexible enough for me to make changes as needed depending on project needs. FWIW, I think webpack has come a long way, and it complements my current workflow quite well.
I was a fairly early adopter of Parcel, but my biggest gripe with it is the lack of flexibility when it comes to adapting it to different projects in which legacy support is a non-negotiable deliverable. Maybe this will change with Parcel 2, but I have no desire to jump off the webpack bandwagon anytime soon.
I have to do some post build gymnastics to get things how I want with parcel, but it's worth it for me because it doesn't use that terrible eval() mess for every module like webpack does. If webpack got rid of that implementation, I'd give it a second look.
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.htmlThat's pretty much all there is to parcel.
Parcel is very fast to use, it can build react, angular and vue without a tons of configurations.It have hot reload, code splitting, statis assets support and it support any css/html preprocessor. It's perfect for simple projects, but its community look a bit dead.
// , About the libraries, I guess you could say I'm feeling vellichor.
Honestly? "Shoot me now!" is the prevailing feeling
I'm always struggling with setting up Webpack configuration, tend to avoid configurating it for myself and use something like
create-react-appinstead. This came with new problems, like questioning if I have to 'eject' for customization of the build scripts.Thanks to Parcel, I am able to start from scratch without having to copy configuration files from other projects.
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.