It seems like yesterday Webpack emerged as the most viable option for bundling JavaScript. I still have a lot of tooling fatigue, especially since ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
"I am tired of learning about more bundlers. I just want to build my apps." Ah, best comment ever about bundlers.
// , What, no obligatory xkcd?
Parcel has really a very small learning curve. And if your feel parcel is gaining momentum you can invest in it
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.
Care to share your plan, or at least how you planned? My learning is scattered and needs focusing to keep making progress.
still using gulp here!
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.
This is all true.
And there is just a renaissace (or breakthrough) of brunch :D
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.
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.
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.
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
staticand other files insrcto 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.
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.
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.
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.htmlandsrc/index.jsand runwebpackfrom the command line. Your webpack project is served.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.
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."
And rightfully so. The JS world seems to revolve around itself a lot.
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.
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.
And, even then, there's usually
create-*-appexactly. I am just missing the create-vanilla-app... or I don't know it :)
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.
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.
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.
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 like webpack because of how general it can be. I don't know a lot about parcel, but it definitely seems focused on browser apps.
That said, parcel seems pretty awesome for browser apps. I really like how it lets you use the html file as the "entrypoint" to your application. I always felt the HTMLWebpackPlugin was a bit awkward.
Imho I'm currently on the Webpack wagon and I'm not going to switch anytime soon.
One of the reasons is as you said tooling fatigue, it's a pita to switch around technologies, especially when you have legacy code to configure.
Another reason for sticking to webpack is that, when you're trying to get 10+ projects under the same tooling system, it's way more flexible on deciding from where and what you want to bundle, minify, extract etc.
Also it's used as the base create-react-app and vue-cli and angular's so onboarding new hires or starting new projects keeps you in the same ecosystem.
I think the whole JavaScript world (frontend and NodeJS) is an incredibly unstable stack.
Frameworks and tools come and go really quick. They never really mature before they are abandoned. Next versions of seriously incompatible with the previous major releases.
This makes it really unapproachable unless you want to fully commit on this. You cannot start a simple side-project right now and play around with it for a year or so. Because by that point half the world moved on to various other things and you want left if a project which needs major redesign.
Even starting your side-project is incredibly difficult. Because where do you start. What is the current best-of-breed framework and tooling? You cannot simply search for information on this, because those articles are "old". They are from the last iteration of the stack (or even before that).
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.
Here are my two cents.
I've used it for small projects, but things got messy trying to use ES Modules without configuration, some third party libraries and Enzyme. I would still use Webpack or Rollup for large projects because doing something amazing requires some fine tuning.
There is no silver bullet in the JS world, and even if there was, you might still miss the target because everything is moving so fast.
Parcel is trying to establish the baseline 'modern frontend'
One now expects to just require() any assets the app uses - also, throw in all your configs in package.json
Parcel assumes that is now the standard way of doing things.
I dont see it as a replacement to webpack but rather as an exploration of the emerging standards.
It's simpler to get off the ground than webpack, less configurable (most stuff is done through babelrc), supposedly faster.
The big difference is using a HTML file as the entry point instead of a JS file, which means less weird stuff to do with CSS/pre-processors.
If you have a working webpack setup, don't worry about it.
If you're starting up a project that has an officially supported CLI, don't worry about it.
If you want fancy tree-shaking and only have JS, rollup has you covered.
Webpack is the most flexible (it's designed to be adaptable to all the weird stuff you might want to do).
Parcel is simple and designed for apps.
If you love endless configurations, then stick with Webpack. However, if you want to be on the cutting-edge, try Parcel. It takes a few minutes to get started. It has saved me a lot of time and my clients appreciate it too.
I feel the love on the Parcel from the first checking it just works.
Although you need to know that it generates two files: CSS and js . and Webpack can generate just one js.
I think one of the most frustrating things about most of this stuff is that it just sort of keeps reinventing the same wheel over and over, and rarely are things given the chance to actually adjust and change and iterate and all that stuff -- so a lot of the issues don't really get worked out and just sort of self-perpetuate.
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.
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.
Parcel did pick up my vue + typescript + wasm-bindgen project without any configuration, but that is the part that scares me.
Why doesn't it batter me over the head with information regarding what modules it's using to achieve that?
Too much magic.
I think I would be interested to see how these other bundlers work.
I'd be curious how easy it is to do certain things in these other bundlers. For example, do they support the asynchronous import() syntax for dynamically loading code from the server? Webpack does quite a good job of that. Also, I was able to get webpack to filter out excess locale files from moment.js, which was helpful in reducing bundle size. I wasn't using moment myself, but it's (somewhat annoyingly) a hard dependency of chart.js at the present time (I think they're working on that though). Another thing webpack does nicely is it let's you use a local loader on the browser for resources like fonts and images, and if they're too big, then you can fall back to a loader that gets them from the server...
As long as these new bundlers do support ways of dealing with stuff like that, it might be worth trying them out... although I also find myself a bit too lazy to actually dig into them since I do have things working in webpack right now. It's true that the configuration of webpack can get rather arcane quickly though!
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.
Iβve used Parcel for smaller applications and itβs worked great. I havenβt used it with any enterprise or large-scale apps. I would say this is one of the easier javascript tools to learn. I found (and wrote) a simple tutorial to get up and running. I spent about 15 minutes learning it and other than having to reference things on occasion, really donβt have problems with it.
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.
Uuuuuuuuuuuuuuuuuugh.
That's how I'm feeling about tooling overall.
UUUUUUUUUUUUUUUUUUGH.
With a pile of recent experiments with Phoenix, I finally got a vague default setup I am sort of happy with. And it ended up requiring Webpack for JS, Brunch for the CSS reloading. Which I feel a little gross about, but.
The more tooling options the better. There are definitely some people that it will click with and if it helps a few projects take off that wouldn't have otherwise I'm happy it exists
// , About the libraries, I guess you could say I'm feeling vellichor.
Honestly? "Shoot me now!" is the prevailing feeling
For big projects I need something equivalent to webpack's "magic" comments; Parcel doesn't provide any solutions for this yet.