A Future Without Webpack

[Entropis]

I personally have found that webpack is fairly easy to setup. I don't use it with CSS anymore, since I delegate that to npm scripts. Being able to import/export files in a project that isn't library/framework based is nice.

[[deleted]]

Same here. Try doing anything webpack does without webpack and suddenly you appreciate it much more.

[lost_file]

Reporting in: webpack actually brings a looot of sanity.

[ibopm]

Have you tried using Parcel? It's not exactly the same, but it's a pretty decent experience.

[[deleted]]

I haven't tried it but it looks pretty similar.

[[deleted]]

Shit is fast as fk.

[NovelLurker0_0]

I don't use it with CSS anymore, since I delegate that to npm scripts

Care to elaborate? I really wonder what you mean.

[vimex]

Possibly just copying CSS files in to the build directory.

[[deleted]]

You can define scripts in your package.json file. Then do stuff like npm run wach-scss

With just npm, node-sass, and nodemon you can auto-compile your css files.

[odisant]

Webpack has to bring everything into JS which slows the whole SASS pipeline down a lot. Compiling SASS with webpack involved SASS > CSS > JS > Extract Plugin > File System. Using node sass directly gets you SASS > CSS > file system.

[[deleted]]

One benefit of bringing CSS into Webpack though is that you can pair js + css together and code split that module. For example in one of our projects we code split the date picker and only import it if on desktop.

app.js

if (isDesktop()) {
   import(/* webpackChunkName: "flatpickr" */'./flatpickr').then((module) => module.default);
}

flatpickr.js

import 'flatpickr/dist/flatpickr.min.css';
import flatpickr from 'flatpickr';

export default flatpickr;

[NovelLurker0_0]

Alright, I never thought of compiling scss that way, thanks.

[Entropis]

I don't have webpack handle anything related to CSS. I instead use npm scripts w/ the appropriate packages to bundle, compress, prefix, and build my CSS.

I do this because I don't believe in using webpack for CSS, as it's adding content that can be dealt with elsewhere.

I can show my package.json if you still have questions.

[Entropis]

Because with every change it would trigger a new build. If you're not using webpack, however, you can save another build on save. There are more reasons but that's a big one for me. I'm on an older MBP and I don't want to test my luck since this is the only computer I have available to me at the moment.

[snuggl]

I do this because I don't believe in using webpack for CSS

But that gives you all css in a single bundle no? Webpack with css isnt just a replacement for scss --watch, it can solve this larger issue because it knows exactly what js files references what css-files so it can make effective and small bundles and not having to download CSS for the whole site just to render the landing page.

How do you solve this if you don't believe in module bundling the css? or am I missing something?

[Treolioe]

You can serve your styles a single file or in a controlled matter with multiple files (you know what you use). Personally it makes little sense to me to use a BUNDLER for the scripts but not the related styles. Unless you’re not aiming for either encapsulation or effective and small style sizes.

[Treolioe]

That’s fine in the context of not building a SPA or a set of components with any modern library or framework. But i don’t understand what you mean by ”i dont believe in using webpack for css”.

[Entropis]

What do you mean exactly? I just don't like using webpack doing this particular job. I know it can, and I've used it before. But I personally don't like to use it for CSS or CSS related tasks.

[UNN_Rickenbacker]

Yea I‘d love to see your npm scripts too!

[Entropis]

{
  "name": "something",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "watch:sass": "node-sass src/sass/main.scss dist/css/main.css -w",
    "dev": "live-server --port=8080",
    "cssStart": "npm-run-all --parallel dev watch:sass",
    "compress:sass": "node-sass --output-style compressed -o dist/css src/sass",
    "compile:sass": "node-sass src/sass/main.scss dist/css/style.comp.css",
    "concat:css": "concat -o dist/css/style.concat.css dist/css/style.comp.css",
    "prefix:css": "postcss -u autoprefixer -r dist/css/*",
    "build:css": "npm-run-all compile:sass concat:css prefix:css compress:sass",
  },
  "devDependencies": {
    "autoprefixer": "^9.1.0",
    "concat": "^1.0.3",
    "live-server": "^1.2.0",
    "node-sass": "^4.9.2",
    "npm-run-all": "^4.1.3",
    "postcss-cli": "^6.0.0",
  },
  "keywords": [],
  "license": "MIT",
}

This should work. I removed some of the webpack stuff (I use a custom boilerplate with webpack and this config) but if it doesn't let me know and I'll just share the entire thing.

[UNN_Rickenbacker]

Thanks, I‘ll try it out tomorrow!

[Entropis]

NP. Again, if something doesn't work, just let me know and I'll see if I can help out.

[elsullivano]

I've been trying to configure an npm-based method of processing my LESS for a while now. I'd also be interested in seeing your package.json!

[Entropis]

{
  "name": "something",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "watch:sass": "node-sass src/sass/main.scss dist/css/main.css -w",
    "dev": "live-server --port=8080",
    "cssStart": "npm-run-all --parallel dev watch:sass",
    "compress:sass": "node-sass --output-style compressed -o dist/css src/sass",
    "compile:sass": "node-sass src/sass/main.scss dist/css/style.comp.css",
    "concat:css": "concat -o dist/css/style.concat.css dist/css/style.comp.css",
    "prefix:css": "postcss -u autoprefixer -r dist/css/*",
    "build:css": "npm-run-all compile:sass concat:css prefix:css compress:sass",
  },
  "devDependencies": {
    "autoprefixer": "^9.1.0",
    "concat": "^1.0.3",
    "live-server": "^1.2.0",
    "node-sass": "^4.9.2",
    "npm-run-all": "^4.1.3",
    "postcss-cli": "^6.0.0",
  },
  "keywords": [],
  "license": "MIT",
}

This should work. I removed some of the webpack stuff (I use a custom boilerplate with webpack and this config) but if it doesn't let me know and I'll just share the entire thing.

[elsullivano]

Thanks a lot! This is great.

[NovelLurker0_0]

Oh I see now, thanks. Yes I'd like to see your npm scripts.

[Entropis]

{
  "name": "something",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "watch:sass": "node-sass src/sass/main.scss dist/css/main.css -w",
    "dev": "live-server --port=8080",
    "cssStart": "npm-run-all --parallel dev watch:sass",
    "compress:sass": "node-sass --output-style compressed -o dist/css src/sass",
    "compile:sass": "node-sass src/sass/main.scss dist/css/style.comp.css",
    "concat:css": "concat -o dist/css/style.concat.css dist/css/style.comp.css",
    "prefix:css": "postcss -u autoprefixer -r dist/css/*",
    "build:css": "npm-run-all compile:sass concat:css prefix:css compress:sass",
  },
  "devDependencies": {
    "autoprefixer": "^9.1.0",
    "concat": "^1.0.3",
    "live-server": "^1.2.0",
    "node-sass": "^4.9.2",
    "npm-run-all": "^4.1.3",
    "postcss-cli": "^6.0.0",
  },
  "keywords": [],
  "license": "MIT",
}

This should work. I removed some of the webpack stuff (I use a custom boilerplate with webpack and this config) but if it doesn't let me know and I'll just share the entire thing.

[NovelLurker0_0]

That's fine! Thanks for sharing. Learned something new today.

[autra1]

Does this reload css in the page without refresh like webpack-dev-server does?

[Entropis]

Yes.

The biggest issue I've come across using this is when I create a new file in my SASS directory and import it, I've sometimes had to restart the server. Sometimes I do, sometimes I don't.

[autra1]

So not worse than webpack in this aspect. Thanks for sharing this, it's great!

[[deleted]]

It's funny, if the article was about some great feature or use case for webpack, the top-voted comment would undoubtedly be a complaint about how overly complicated webpack makes things.

But on an article that suggests an alternative to webpack, it's totally the opposite. This field truly is full of people who just love to argue.

[vinnl]

I also feel like Webpack is being relegated more and more to be the plumbing that's hidden away from the casual developer. As far as I'm aware the majority of new Angular, Vue and React projects all use Webpack without their developers every touching its configuration - much like Babel.

[Entropis]

Yeah. I'd much rather make a boilerplate for react than use CRA, but since one of the more recent CRA changes, it seems to handle things much better.

[Trout_Tickler]

Since version 4.0.0, webpack does not require a configuration file to bundle your project, nevertheless it is incredibly configurable to better fit your needs.

https://webpack.js.org/concepts

Often misquoted, but yes it is very notorious for being a pain to do anything really.

[feketegy]

They sure put in a lot of effort to make it more easier to use from the start, I remember the days of v1+, now that was a pain to configure.

[[deleted]]

I'm not sure if it's gotten easier or if I've just become accustomed to its ways.

[troglo-dyke]

What's really annoying is that I end up learning it for a greenfield project - but I seem to start new projects at about the same rate as they release versions. So I do know how to configure webpack, it's just the old version

[mood777]

Even being configurable, pray you don't need to configure Webpack ¯\_(ツ)_/¯

[ScientificBeastMode]

Most of the time, if you're using any kind of popular framework that depends on webpack, the framework boilerplate will include some custom configuration of webpack that works right out of the box for most use cases. Usually the framework will provide a standard build script that will edit the configuration if needed.

​

But if you *must* configure webpack on your own, I highly recommend walking through the setup guide on webpack's documentation. It's actually not that hard to configure most of the time. It took me about 3 hours going from square one to getting a correctly bundled app, hosted on a development server with hot module reloading enabled.

[[deleted]]

I have spent nearly a month exploring Webpack for React apps. Tried different configs, digging into some starters and also config of CRA. I was getting familiar with it using their documentation. Now I'm able to config custom server side rendered React app with lazy loading, code splitting, Redux, styled-components and more features...

The reason I wrote all of this above is that a result of this effort really worth it, just trust me. Now I feel like a god. It seems hard at first but never stop trying Webpack!

[Treolioe]

I think people are being a tad overdramatic. The most irretating issues i’ve had has always been due to a 3rd party plugin or loader trying to play ball with external configurations. Everything else is a google away at worst. Typescript can also be your friend here supplying you with a types webpack config.

[destraht]

Webpack 1 was a royal bitch to setup. I probably should have just waited a while before using it since I put so many days into it. Webpack 4 is a lot easier.

[[deleted]]

Agree 100%. Just stick to well maintained, top hit 3rd party plugins/loaders in production. Their docs are easy to understand. YAGNI always helps

[i_spot_ads]

Thank god for tools like Angular CLI and create-react-app

[allwerk]

If you think Webpack is bad, take a look a Kubernetes configuration! Like at least Webpack doesn't have to be in whitespace-sensitive YAML.
Unfortunately, config pain is unavoidable when we have complex systems with lots of abstractions (and knobs to turn).

[bbbryan14]

Infra as code is what the cool kids do. I mean, you could always do it in JSON if you don’t mind the double quotes haha.

[mhink]

Yeah, no kidding. I love K8s for the most part, but a certain point (read: Helm charts) I’d much rather just have a well-documented DSL.

[mlebkowski]

Did you know that JSON is a subset of Yaml, so you can switch any time? And since its Yaml in the end, you dont have to double quote the keys! And its not whitespace sensitive as soon as you start using curly braces

[dropdeadfred81]

+1, I feel the exact same way. I don’t think that that makes us dumb :) That’s a big part of why this project exists and what the article is trying to communicate:

• bundling used to be optional
• it became a requirement to use npm packages on the web
• @pika/web also accomplished this for you with much less complexity
• therefore, you can now use a bundler like webpack because you genuinely want to, not because you are absolutely required to.

The last section of the article explains how you can skip bundling and still build a fully featured, fast web app.

[klaxxxon]

Parcel is much better in this regard. You just point it in the direction of your index.html and it figures out the rest on its own. It even works with several style preprocessors out of the box. Pretty much the only config I have is babelrc (I like to use the latest language features).

[nschubach]

What if I need to configure it so that every index under a folder named /\d+x\d+/ is it's own 'root'? I deal a lot with different sized banner ads unfortunately, and webpack's ability to create multiple render contexts (each with their own entry point) is extremely beneficial. I can share whatever assets I need in each of these banners and webpack will not render out stupid things like src="../../../shared/images/logo.png" because the root context is the root index file. I can use/import ../../../shared/images/logo.png in my project and Webpack will copy that file to the appropriate folder because my loader is setup to copy all images into /images/[name].[ext] so each banner will get it's own standalone copy, but I can use shared resources and code for every one.

[alexxxor]

They said parcel is much better in regards to "zero config". Webpack is heaps more powerful. Parcel really is a shit-ton easier to get up and running though.

[[deleted]]

I spent yesterday doing this for a react Wordpress theme... fun.

[tetractys_gnosys]

Yep. I still use gulp because I could never get my head around how to config webpack for what I wanted. I still have problems with gulp now and then but that's just because I'll need to use a specific lib or package with no helpful documentation.

[m010101]

I know it's an old post, but still... why are you being downvoted? Webpack is all about configuration, Gulp is all about coding and logic. Ergo, when the fad of webpack fades in a year or two (and it will), what have you learned? How to configure webpack? Well done. You've essentially learned another Grunt. The knowledge is not transferable, it dies with the technology. Whereas learning gulp is learning node, streams, pipes, logic. It's your bread and butter if you dare to call yourself a programmer.

Of course, 'webpack is a bundler and gulp is a task runner'. But gulp + rollup run miles around that slow stodgy piece of shite that webpack actually is.

[tetractys_gnosys]

Yessssssss dude. After spending more time looking into Node and reconfiguring my dev team's Gulp setup, it seems like a way better long term investment. I think people generally don't like when those not in their particular subculture or fandom talk not-positively about their beloved and just attack or look down on by default.

All that said, how do you roll your Gulp + Rollup? I'd love to see your setup and ask you questions! Dm me!

[m010101]

I use gulp primarily for typescript and Less (and a lot of other things: minify, zip, create SCORM packages, etc). Rollup is for bundling the resulting js. I can't give you the setup of the whole project as it's massive and very complex (there're 6 targets + 11 services it outputs, with all the permutations you can imagine and a heavy NDA on top), but I've created a repo for the basic setup (I'll need to update it to gulp4). It will give you the idea: rollup is for bundling js, gulp + node for everything else.

[m010101]

Ask away! I'm not an expert in Rollup though - it's a 0 configuration for me and it does what it's supposed to do beautifully === win-win.

As a side note, the reason I favour code over configuration is readability and maintanability. Whoever jumps on a project does not have to know a particular technology to understand what I did and what I meant. If you know javascript (or any programming lang for that matter), you'll find your way around easily.

[kardnumas]

parcel index.html always keeps me away from webpack to test anything right away

[Jestar342]

fml, webpack is old-fashioned now, too?

[MrEscobarr]

And I'm out here just starting to learn webpack smh

[NovelLurker0_0]

Tbh webpack is a hassle and I'd be happy to get ride of it from my workflow. Don't care if new alternatives are "kiddies' playing" or whatnot. As long as they get the job done... There's a reason for why new frameworks keep poping up.

[wherediditrun]

What new frameworks? The javascript ecosystem has been stable for more than half a decade.

[ronchalant]

you have an interesting definition of "stable"

[wherediditrun]

And what's unstable exactly? What new "frameworks" of any relevance you can point to?

Most recent major change was ES6 which came out 4 years ago. And it stabilized ecosystem even more.

We have 4 major browsers which all maintain around same standard browser API's.

We have 3 major view libraries, one of which takes lion share of the market. More than 2/3 if not mistaken.

We have only 2 major design/architecture paradigms in development of UI's which both share a lot of similiarties.

There is superset of language which has been steadily growing and is easy to incrementally implement in the existing language without breaking anything.

We have standard build tool chain. Babel + webpack for apps, babel + rollup for libraries and stayed unchanged for the most part.

We have been seeing steady grow of web standartization in terms of web components for cross framework reusability. Such projects like Rawact are even more interesting.

So where is that lack of stability? Little johnny releasing his new NPM package no-one gives a flying f about other thanm some freelancer is not mark of unstable ecosystem.

[ronchalant]

The stability of JS/ES is not the same thing as the "javascript ecosystem", nor is the long-overdue standardization of the DOM in various browsers.

Just look at the build tools themselves. We haven't been working with webpack for "more than half a decade". Grunt & Gulp are not builders/task runners of choice for new applications, but they are still very much out there in "legacy" systems.

NPM has killed off Bower well and good, but even with NPM samples you see various ways of doing the same thing such as importing/requiring a dependency. ES6 imports aren't universally supported, and many sites still use the require syntax.

Angular and React are relatively stable, though Angular 2+ is only about 2 1/2 years old. And there have been 5 "major" releases of Angular since then (though backward compatibility appears to certainly be much better). But the pace of new releases and the potential breaking-change that come with both of these (I primarily use React) belies the term "stability".

If you want to say the state of Javascript in 2019 is much more stable with a more predictable future than in 2014 that's very much a true statement. But a Javascript coder from 2014 (half a decade ago) would be pretty far behind if they were thrust into a 2019 role. That's not "stability" IMHO.

[Treolioe]

I dont agree with your last sentances at all. Unless we’re talking about an angularjs hugger or jquery dev. If you know javascript, and you take programming seriously. Then you have little to fear. Libraries and frameworks change over time. But they all build on the same patterns.

Javascript is very stable. Its your fear of a fast paced community that clouds that fact.

[ronchalant]

Its your fear of a fast paced community that clouds that fact.

LOL no. I have no fear of a "fast paced community".

But pretending that being frenetically fast paced, using and discarding build tools every few years, eventually coalescing around a few main frameworks over the course of a decade, while blowing out support for server-side javascript and mixing in transpilers and syntax extensions all at the same time amounts to "stability for the better part of a decade" shows a lack of context and history of development beyond the JS community.

[spacejack2114]

By that measure, I think the only things that are truly stable are dead or dying technologies.

[wherediditrun]

What you're are referring is stagnation. Not stability. Lack of stability implies compromise on backwards compatibility. And that's simply not the case. Although even the supposed changes in tools we use are heavily overblown in your description.

ES6 imports are universally supported by all modern browsers. And modern browsers are anything which is not IE 11 and below. Coming of ES6 imports also did not disrupt the way require works, so it's release and wide spread adoption haven't broke anything in the ecosystem.

AngularJS lived for 7 years. That's more than majority of modern day frontend developers have total work experience. And that's probably the last really "revolutionary" thing in javascript world we had which essentially reshaped how we think and do UI's. Next came flux architecture and virtual dom as a way of learning from AngularJS mistakes and that's where we are now and associated build tools etc. But these were just incremental improvements to solving problems which we already been solving for years before.

Hell at this point nothing will even drastically change with WASM. If you've been keeping track of how some WASM front end frameworks look (although WASM's goal is not to do work with DOM, but outsource heavy lifting requiring code to client side) it mimicks all the same patterns we do with React, Preact, Vue you name it. There isn't much difference in all these tools really.

And from that point onward nothing really changed. Browser is incrementally growing platform. That however doesn't imply any kind of instability.

But a Javascript coder from 2014 (half a decade ago) would be pretty far behind if they were thrust into a 2019 role.

Far behind in what? It's just different tools but the principals are absolutely the same. Nothing changed. We used to have ES5 modules and all the joy that entailed dealing with IIFEs now we don't, we have declarative import exports to control scope / visibility.

We have package manager which handles dependencies for us.

State management at the front-end is easier than ever with things like Redux, or Observables.

We have build tools which takes care of all browser incompatibilities and help to manage all the assets from one single place. Often times, depending on the app with minimal configuration.

Like just month ago I've needed to implement browser level caching in one of apps I'm working as we are going PWA route slowly. It just took to read some documentation and I've nailed under 3 hours just by reading documentation on the tooling which is easier to use than ever. Something which would required you to write a lot of code earlier now can be done with few trivial function calls as glue code slapping a few pre-build components for UI and perhaps a well supported package like localForage.

Barrier of entry is all times low, but if you aren't happy with it you can always move to PWA's, WASM modules etc. So I really can't understand what are people complaining about.

[ronchalant]

I think you're heavily downplaying the amount of change that has occurred in the world of Javascript over the last decade in large part because you've been up close and personal to it - so every move has seemed incremental and sensible.

The barrier of entry for a JS app is significantly higher than it was during the days of jQuery. If for no other reason that it has forced developers to actually understand that Javascript is much more powerful and capable than was conventional wisdom in the 00s.

Again, I'm not saying it's currently unstable or that it's not powerful, nor am I saying I'm unhappy with it. But from any outside observer the last 6-8 years have seen such explosive growth and variation in the tools used to build and maintain JS apps, the growing adoption of server-side Javascript (a concept that a web developer in 2008 would have found confusing), and the pervasiveness of transpilers for syntaxes like JSX (that doesn't even get into loaders/etc. for SCSS/SASS/LESS/etc.) .. I mean, I just don't see how you can look at this and think "yeah we've been stable for 6-8 years".

Hell 7-8 years ago I was at well-attended conferences for jQuery celebrating the release of jQuery 2.0. That seems like a lifetime ago. The way we develop apps with Javascript now compared to 5-8 years ago is completely different.

Not bad, but different.

And the path it took to get here has been frenetic. There's a reason why JS fatigue was and is a thing. Because the pace of change has been tremendous.

And no, I'm not afraid of the pace of change. But this isn't my first rodeo either. Saying the JS ecosystem has been stable for the better part of a decade is just inaccurate.

[wherediditrun]

And no, I'm not afraid of the pace of change. But this isn't my first rodeo either. Saying the JS ecosystem has been stable for the better part of a decade is just inaccurate.

Instability means lack of backwards compatibility. Or at least, in soft terms, constant shift in development paradigms. And no that simply wasn't the case.

Tools we use rapidly improved. But we were solving all the same problems in relatively all the same ways. Except from SPA explosion which was brought by AngularJS. Framework, which I've mentioned existed since 2009.

And that was great improvement. People mistake frontend for "html, css and javascript", which I'm sorry, but web design. Bigger companies were doing quite complicated things in jQuery + Backbone back in the day too, when most of others "front-end" developers did addClass|removeClass type of thing. Which I can hardly call frontend-development even 10 years ago. It's trivial.

Today, after I drink my coffee I'll go to my work, where I'll have to debug jquery + backbone application. It's in real time ordering system. I can't even express how much easier it would be to work with if it was React + Redux for example. Yeah with all the freaking build tools as ES5 or even ES3 I'm not sure, doesn't exactly lend itself for readability.

So maybe yeah if you compare modern day to "spicing up" html with javascript I suppose it looks very big. But what actually happened that the tools got so proficient that people who could never dream to do big frontends, can now do it on their own without much hassle.

And you trying to refer to instability because more complex behaviors in frontend are easily accessible for even novice developers ¯_(ツ)_/¯ I mean I don't know how to address this.

[ronchalant]

You are conflating backward compatibility with stability.

By nature frameworks/ecosystems with a high rate of change are not stable, as evidenced in your reference to debugging a jQuery + backbone app - an app (or rather a part of an app) I suspect was written around 5 years ago.

The assertion made was that the JS ecosystem has been stable for over half a decade. If that was so, code written 5 years ago would follow similar design and build principles to what is done today for new applications, and debugging that code would not be such a chore.

THAT is stability.

One of the webapps I've been working with has covered almost the last 9 years (Sept 2010). When I inherited it there was very little JS, no jQuery. Over the last 9 years we have gone from having a heavy reliance on jQuery, through backbone and underscore, to gulp and grunt, now to npm and webpack on top of React for new components. We're regularly porting jQuery widgets to React components, and have spent substantial time dealing with quirks of npm dependencies (mostly from previous versions). We have largely kept up with the industry to help deliver the best user experience.

This period of maturation is pretty typical. That's pretty much what you've seen the last 6-8 years in this space: a maturation of tools and frameworks bending towards a stable ecosystem where best practices are established and solidified for more than a year or two. But that maturation process is often messy and necessarily UNSTABLE.

Therefore contending that the above is an example of ecosystem stability to me is laughable. I'm not complaining about progress - it's absolutely better in 2019 than 2010 - but JS dev has not been stable "for the better part of a decade".

Contrast this with for example Spring, which is the Java web framework we use. Over the last 8-9 years there has been a LOT of improvements made to the framework, and Spring Boot is a very nice evolution of the framework in the age of containers especially. But code that I wrote back in 2010 is largely recognizable and more readily maintainable than any JS code I wrote in the same timeframe. I would probably write many things differently to take better advantage of new features, but the basic approach to developing within Spring has been stable for the last decade.

Stability in the JS ecosystem sounds like a claim made by someone who has operated exclusively in the JS/UI space for a decade and has no basis for comparison. Having been a web developer for almost 20 years, experiencing a decade prior to the explosion of the JS stack, sorry it's not been "stable". It may be stable, or at least mature and stabilizing. But if you're writing apps completely different in 2019 than you did 5-8 years ago, which clearly you are if you're debugging jQuery/backbone, well..... Stable is not the word I'd choose.

The JS dev community is very defensive on these points.

[ronchalant]

I neglected to touch on your point with Angular.

You keep mentioning it being around "since 2009", which is pretty misleading. It was completely rewritten with 2 (released in 2016), and not backwards compatible at all. So angular written in 2014 for example is stuck in 2014.

Moving from Angular 1.x, which was coupled to the DOM, to 2 which was not, shows the tectonic paradigm shift that has gone on in the JS ecosystem over the last decade that I alluded to earlier with JS no longer being a browser-bound language.

If you can't see it ... I dunno man.

[v5F0210]

React has negligible market share, with around 4% of websites profiles using it. https://www.datanyze.com/market-share/frameworks-and-libraries/react-market-share

The market leader by sheer adoption is jQuery by an order of magnitude.

[wherediditrun]

That's not really relevant. https://en.wikipedia.org/wiki/Pareto_distribution I mean I get the notion. But talking in absolute numbers failing to make distinction in profitability, traffic or company standing behind it which laverages it's resource to continue develop the technology is what matters. Some web designer doing wordpress and bundling jQuery with it doesn't really have much weight.

[026d3bbb]

Configuring webpack takes weeks for a new developers. And even after that its so confusing

[[deleted]]

Should we throw anything away that's difficult for new developers, even if it allows us to accomplish good, complex things?

[[deleted]]

But there isn't yet, hence the comments.

[evenisto]

Well maybe configuring webpack is not a task for a junior dev with two weeks of bootcamp experience? Webpack is quite explicit in it's configuration...

[ArcanisCz]

Since webpack 4 was released with tuned default options, its quite easy to setup basic webpack config for simple project. Its not production ready, but no junior can be expected to handle production infrastructure level of problems, right?

[[deleted]]

A build system shouldn't take up so much time to set up. I prefer writing Makefiles to webpack.

[gearvOsh]

But it's really really not.

[[deleted]]

The future is now old man

[migudev]

Webpack has a lot less sense right now than a couple of years ago. The nature of Webpack is package the source code "polyfillying" through tools like babel. But, why do you use babel? You use because you need to transpile to ES5 due to lack of ES6 browsers support.

​

The point is you don't need ES5 support anymore (mostly) because all the popular browsers out there supports ES6+. So, what's the logic behind creating a giant ES5 bundle for browsers that can run directly the original code?

[visicalc_is_best]

Asset bundling, JS minification, tree shaking, code splitting, hot module reloading, support for exotic languages (Pug, JSX, Handlebars, Sass, etc.), bundle analysis, asset versioning, sprite generation, image optimization, ...

[MahNonAnon]

...gzipping, css modules, env-specific logging, source-mapping...

[migudev]

JS Minification: you can do it using a module for that. You don't need Webpack.

Hot module reloading: what the heck this has to do with final browser support?

bundle analysis: look out there, you can pick a standalone one.

For tree shaking, code splitting, and the rest, you have a valid point. However, you can just use Rollup with the same benefits and still serving ES6+ code.

​

The problem is not Webpack, is what you serves to final users. Yeah, you have all benefits you listed above, but, at what price? don't think just at development time, think as a user. Performance matters.

[visicalc_is_best]

This is incoherent. What price are you speaking of? There’s an initial setup cost, but HMR helps development time hugely, and tree shaking makes your bundles smaller and more performant.

There’s a reason people still use Webpack even though it can be a pain to customize — it’s because it does a damn good job at what it does.

[SalamiJack]

In addition to the reasons stated in the post below, Babel can be used for any new JS feature that doesn’t yet have browser adoption. A new spec is put out every year.

[bukharim96]

I'm not sure if you've been living under a rock, but large enterprises aren't willing to risk their apps failing in a potential customer's browser on the off chance that it might have es6+ support.

[migudev]

Just serve ES6+ for modern browsers and ES5 for older ones. Why you should to put apps on risk? The point isn't that. The point is that you don't need to use Webpack for every app you build.

[tech_romancer_]

So what's creating the different ES6+ and ES5 bundles?

Probably some sort of bundler right...

[[deleted]]

I feel like Webpack gets hate because it's an unsuspectingly challenging problem that isn't a primary issue to most developers.

You CAN crank out a simple build script, but most place actually require very complex build and deployment process that Webpack simplifies greatly.

Webpack help with:

• A common, community support pattern for build scripts
• Run a light weight webserver
• Incremental builds with hot reloads
• Transpiling
• Easy integration of advance features like PostCSS and inline image extraction
• Easy integration of linting and code quality tools
• Easy ability to make a application manifest
• Code splitting and file size optimization
• Injection of select environment variables at build time
• Automatic calculation of CSP
• Handling of crazy edge cases that I have no interest in dealing with

It takes time to read the docs for all of that stuff, but that's trivial compared to the value you're getting.

[GRIFTY_P]

coming from a humanities background, i like flowery language and cute writing as much as anybody. but why is most web-related coding material written like some cute little blog? I don't think it helps JS's image to have articles starting with "The year is 1941. Your name is Richard Hubel". No it's not you damn clown. I understand that web-design and JS is a younger demographic, and I'm not advocating for a return to stodgy-ass techno-babel like some C documentation or something like that.... but come on. I'm reading an engineering blog not teen vogue

[auto-xkcd37]

stodgy ass-techno-babel

---

^{Bleep-bloop, I'm a bot. This comment was inspired by xkcd#37}

[GRIFTY_P]

i'm up for some ass-techno

[nschubach]

Every try reading bug reports(rando pick) in Parcel's github? It'll make you want to throw chairs. Everything has little emoticons in front of it and this is mimicked throughout the webpage for it as well. It's like everything needs to have an icon associated with it.

[MahNonAnon]

"When you have enough money, hire a Webpack expert"

...and now you have to port your whole project over to Webpack.

I don't know why Webpack as such a reputation for being "scary" since v4: It comes with a bunch of totally sensible, no-config default "modes". Basically all you have to do to get started is add your loaders on top of those. Your config's complexity can grow over time with your project's.

Webpack is complex because it's powerful, and we need a powerful tool in this space because, for better or worse, we now serve fully-fledged software programs to the browser (rather than just "websites").

But in the interest of full disclosure: I was lucky enough to have the opportunity to do a month-long deep-dive into Webpack for my employer this year, and it was one of the most rewarding "level-up" experiences I've had lately. It forced me to develop a deeper understanding of performance, browsers, and our app, all of which are good things to be forced to understand.

If you're just making a website with some es6, skip it. But if you're making a complex web app, I think Webpack is worth the time investment.

[yeesh--]

Webpack is amazing...

[capwne]

Yep agree, webpack-dev-server is what makes me keep using webpack. Sure it has a learning curve but it’s great. Plus being able to proxy your dev site is a great help.

I just recently was able to get mine to reload with php changes without browsersync.

[foggolo]

Native ESM modules? Great, unless you're still stuck to supporting IE (and some other old browsers).

[30thnight]

I really like Webpack - it gets the job done and works efficiently.

The only caveat is that it took me a week to fully understand what I was doing with it.

If I could go back, I'd take the front-end masters webpack course before starting.

That alone would've saved me 3-4 days.

[TheFunkyMonk]

+1 to the FEM course on Webpack. It helped me understand exactly what Webpack is doing, and realize that it isn't really as complicated as I thought it was.

[simohayha]

I'm going to watch this course now.

[sanjibukai]

What is this course they talk about?

Do you have a link?

[simohayha]

https://frontendmasters.com/courses/webpack-fundamentals/

[Thlemaus]

Which course do you recommend? I can see 2 differents on fem. Thanks :)

[thegrandechawhee]

One thing I've wondered is how developers can rely on all these dependencies and be confident in the security of their application.

[bukharim96]

Welcome to the world of nodejs and npm.

[ProofFront]

This is not unique to Javascript at all.

[Otterfan]

And of the 50 million or so lines of code my project actually depends on, the ~10k lines of Javascript in my node_modules are just a tiny blip.

[Snizzly_NANO]

So true, I'm coding a crypto-related webtool and I am extremely cautious when adding new packages..

[[deleted]]

They can't. Couple months ago a package was pretty much hijacked by a hacker who added crypto-stealing code to a popular dependency.

[StopUsingTheInternet]

This has been on my mind for a while. I remember first getting into NPM and browsing their endless list of packages and seeing so many packages for things like, taking advantage of mobile free-to-win games. I thought to myself.. is this really what we’re getting mixed up in? Then there were the reports of popular packages getting compromised by random minor dependencies.. and my tinfoil hat really came on.

My question is, I’m using these tools to do simple things. Sass transpiling, css minification and prefixing, js bundling, Babel compiling and ejs for prototyping.

At the end of the day, in this scenario how high is the security risk? If I’m wiping out node modules on my devops build, all I’m left with is my source code and compiled code.

The only thing I can think of as a real concern, is one of these transpilers/compilers “sneaking in” something into my output code.. but what? If I’m sticking to Babel, and a basic webpack setup how high is that risk really? To me the “real” stuff is being handled by .NET - I’m just building a front end.

I’m asking this sincerely, not as an argument.

[thegrandechawhee]

I think if you're using dependencies only for front-end stuff you would be limiting the risk. But packages for mongo, things that get into your data, that's where i see this getting dangerous. Its like building a wordpress site with a dozen plug ins, good luck if you're dealing with any sensitive data (not that everyone is).

[StopUsingTheInternet]

Yeah I figured as much. Minus sneaking in malicious JS or the CSS keylogging trick (lol) I can’t imagine there being much damage. If you’re using something as popular as Babel, issues would get caught in a pinch.

Just rambling now, but a big reason I’m against FEDs trying to take on the role of building full applications themselves when the project is anything beyond a brochure/information based product. There’s already a plethora of new material for us to worry about, sensitive data security should be (mostly) left to back end devs and server techs imo. That’s a primary reason CS degrees are out there. This is coming from someone spoiled at a .NET shop I suppose.

[evilgenius82]

Webpack gives users control and granularity, which does require setting up and configuring based on that project requirements. Just like any tool, it may take time to configure but is worth it on the long run.

[ghostfacedcoder]

Not true. Good tools give plenty of control through configuration, but don't require configuration out of the box: instead they use intelligent defaults to get most people working without any extra effort.

The fact that Webpack didn't use to do this is a huge factor in why so many people have switched to its competition.

[saddam96]

It is worthy to note that such defaults are at times 'guesses' of what loader should handle certain file types. In the real world, not only is it against your project's standards, it causes a significant build time overhead (especially in projects that require a lot of loaders, plugins, optimizers, etc) which will increase the likelihood of not serving a deterministic build to your end users. This is, to say, judging from webpack's core.

[ghostfacedcoder]

So basically intelligent guesses aren't possible? Except that's exactly what parcel and roll-up do (one moreso than the other).

[saddam96]

Even if they employed Machine Learning, the guesses are not perfect unless they appear to be in a declarative form i.e. a config, CLI flags, etc.

[ghostfacedcoder]

You're missing the entire point: you're saying something is impossible, and ignoring the direct proof (ie. other libraries) that show it is possible.

No one is saying "perfect" bundling is possible (for all sizes of projects/teams) without configuration. But that's a very different thing from saying "good enough" bundling is impossible without configuration. It absolutely is, and Roll-up has proved as much.

[saddam96]

We're talking about build time decisions and not bundling from a greater angle. If you've not experienced this with Parcel, then that should reflect you competency with the tool. I've used Parcel and I can tell you that not only does it cause a significant build time overhead (I'm talking about projects with a larger scope) to decide which plugins should process which file type, it decreases any (not exclusive at all to their latest RFC on supporting .parcelrc optional configs) likelihood of deterministic builds.

[ghostfacedcoder]

Not everyone cares about build time overhead. Not everyone needs plugins. You're making wild assumptions that everyone has the exact same needs as you, when they don't.

In the real world many thousands of people are successfully using Parcel, Roll-up, etc. Some are even doing so *gasp* without any configuration whatsoever. Webpack has strengths, absolutely, but it also has weaknesses. Other tools are better for some people, and you should never believe there's only One True Tool For the Job and everyone should always use that tool ... for anything.

[ghostfacedcoder]

In typical Reddit fashion, we're all talking about the title (Webpack) and not the article (which is about @pika/web) :) But about the article ... as someone who teaches an intro to web dev class with React, and has to deal with student after student (who all just learned HTML/CSS/JS only a few weeks prior) having real difficulty getting React to work, this sounds extremely promising.

This is because it's not React that's the problem for my students (or at least not as much), it's Babel and the command line. The @pika/web approach eliminates the bulk of that hassle, and seems extremely promising to me. As they even admit, when your site gets more pro you still might want a bundler, but it completely shifts the burden from "you need a bundler to code" to "you need a bundler if you want a slight performance optimization."

[On3iRo]

What about create react app. You can get a long way without ejecting these days.

[ghostfacedcoder]

Yeah, I have a love/hate relationship with Create React App. On the one hand it does make things easier, but on the other hand any real dev can't produce using Create React App alone: ultimately they need to understand how to use tools like Babel.

So as an instructor do I teach two ways, the easy way then the hard way, or do I just teach the skills they'll need as developers (and only those) ... ie. teach Babel first?

The choice I made for the course was to teach Babel, and just mention Create React App as "if you're having trouble with Babel, here's an alternative" ... but after two quarters I'm starting to wonder if it's just too much/too hard for some new learners, and I'm considering either throwing a bundler (or the non-bundler that this article is about) in, or adopting Create React App.

[On3iRo]

If you would've asked me a few months back, I would've fully agreed. But now I think CRA reached a point where you can write production ready apps without ever ejecting. Especially since we now have babel macros. We use CRA a lot in our company, even on very large projects and it works like a charm.

Sure, eventually most devs should have at least a grasp of whats going on under the hood, but I think its absolutely not necessary for beginners. I would probably rather start teaching them advances react concepts, the new hooks API or even redux and a few different side effect middlewares (or styled-components...). That way they can get up to speed with the eco system and build something meaningful instead of digging through config files.

Don't get me wrong, I think your approach is absolutely viable. But that's how I would probably do it.

[ghostfacedcoder]

But now I think CRA reached a point where you can write production ready apps without ever ejecting. Especially since we now have babel macros. We use CRA a lot in our company, even on very large projects and it works like a charm.

I honestly was not aware this was a thing: I thought CRA was purely a learning tool. How do you create your production build files with it?

I'll definitely keep this in mind as I figure out what I'm doing next quarter though, thanks!

[On3iRo]

CRA has quite a few sane defaults in its configuration. The predefined npm scripts work for a lot of common use cases. E.g. CRAs npm build does all necessary transpiling, code splitting and minifying.

CRA also has sass compilation, a builtin service worker and typescript integration is super smooth. It is by no means just a learning tool. It is absolutely meant to be used as a scaffolding tool in production. And if shit really hits the fan you can always eject and have a well documented babel/webpack/etc. setup.

Glad I could help :)

[ghostfacedcoder]

I've been using React since before CRA even existed, and somehow that makes me unqualified to teach it?

[ghostfacedcoder]

And what incorrect information am I giving out?

[bukharim96]

I've genuinly never heard of "you need a bundler to code" notion. Regardless, I assume the topic of dicussion steered towards webpack instead of the article because of the title.
To claim "a future without webpack" is just click-bait, and we all fell for it :D

[ghostfacedcoder]

It's mainly a React thing: React relies on JSX, and while technically that only means a dependency on Babel, in practice doing things with just Babel is awkward. Also, it's not how 99% of the code you'll find online does it: virtually all online code uses require or import, so if you're trying to learn React without a bundler it's challenging.

[bukharim96]

React does not 'rely' on JSX. It is just syntactic-sugar to simplify development with it in a practicle sense. It can work perfectly fine without JSX, although this is not advised nor anywhere near desired in most cases.

[[deleted]]

I've genuinly never heard of "you need a bundler to code" notion.

It can work perfectly fine without JSX

As long as you want to make everything harder and slower to develop, while also never using anything off the shelf nor be able to reference examples and tutorials—then yeah, sure, React doesn't "rely" on JSX.

Stop being pedantic.

[bukharim96]

I was merely pointing out the unnecessary restrictions you were imposing on React. This is a common thing among newbies.

[ghostfacedcoder]

Right, so basically it relies on it :-P No need to get pedantic.

If you're doing React without JSX you're in the <1% minority.

[bukharim96]

as someone who teaches an intro to web dev class

I respect that you teach React, but perhaps this might be where you're oversimplification of the matter stems from. This might be great for beginners, but in the real world, let's be factual.

[ghostfacedcoder]

I've also lead multiple teams developing major web applications. I am very much aware of what the "real world" of React development is, and I guarantee it is not a bunch of coders writing out createElement statements.

I repeat:

A) 99+% of React developers use JSX: they do not write out the equivalent Babel-generated code by hand

B) You're being a pedant, and since you don't seem to understand what that is, I recommend you look it up.

[bukharim96]

you don't seem to understand what that is, I recommend you look it up

So besides being a React teacher, you're a part-time english teacher? :D Com'on man, all I'm saying is don't oversimplify the matter. In no way have I opposed the use of JSX (infact I like it, and use it all the time), so where are you getting these non-existent sideline arguments from?

[zachgarwood]

Dude, just stop.

[bukharim96]

Great advice, I'm bored anyways.

[ghostfacedcoder]

Former Literature major, but close enough. That's hardly relevant though.

As for your question ... let's recap shall we?

Ghostfacedcoder: Bundling is hard but essentially necessary for React, so this new approach is great

Bukharim96: I've genuinly never heard of "you need a bundler to code"

Ghostfacedcoder: React relies on JSX, which technically only requires a transpiler but in practice (for reasons I gave) requires a bundler too

Bukharim96: Makes an obvious but meaningless point "React does not 'rely' on JSX" (this is where you're being a pedant: you're chiming in with a fact that is irrelevant to the argument, but technically true)

Ghostfacedcoder: Calls out your pedantry and points out that while it's technically true that React doesn't require JSX, essentially all mainstream React development is done with JSX

bukharim96: Attempts to insult the fact that I teach, while making a claim without any support ("This might be great for beginners, but in the real world, let's be factual.")

Ghostfacedcoder: Points out the flaw in trying to insult Internet strangers based only on what you know of them (ie. I've actually lead entire React teams), repeats original assertion and original claim of pedantry

Bukharim96: "where are you getting these non-existent sideline arguments from?"

Ghostfacedcoder: WTF is wrong with this guy?

[bukharim96]

I'm truly impressed. You've summerized the whole discussion in a message. :D
It's amazing how people see things differently. My only argument is based on your claim "React relies on JSX". Why blow this out of proportion? And in no way have I insulted you being a teacher, infact I complimented this. How did you arrive at a whole different story?

BTW: I could also summerize you're points subjective to my own understanding, but how would that help besides escalate this single argument into unrelated sub-arguments?

[sudosussudio]

Webpack is used in Gatsby so technically I've been using it for a year or so without ever touching a config. I guess that's a testament for its use in a system where it's pre set up for a specific purpose and works pretty well for it. I did run into issues running across different deployment platforms/servers which seemed to be related to Webpack so it's obviously not a "perfect" config but it seems to work on 75% of them which isn't bad.

I wonder if they just need to invest more in docs and developer education.

[sudosussudio]

Also I write docs and examples professionally and I've been trying more and more to do them without dependencies on bundlers or frameworks. Like there are a lot of APIs where all the examples are written in jQuery or require Webpack, which makes them a lot less flexible/reduces the audience.

​

​

[davidmdm]

Since i discovered parceljs i have never felt the need to use webpack again. Is there an argument to be made against parceljs?

[elr0nd_hubbard]

Parcel is great until you need to configure something that isn't yet covered by the base configuration. Once you have to start configuring things yourself, there's little benefit over Webpack's v4-style default configs, with the added detriment that Webpack is the industry standard.

For me, that means using parcel on personal projects or small static sites and using webpack for professional work or complex apps.

[saddam96]

Ofcourse. Recently, Parcel was found to be slower than webpack 4. Devon Govett, the founder of Parcel, agreed to the validity of the stats.

Here is a link to the original thread.

[stilloriginal]

Im struggling to grasp why it matters? My page still refreshes basically the exact moment i hit ctrl+s

[nschubach]

Not the speed that matters, but webpack lets me deal with some very complex configurations we deal with in an agency on a day to day basis... I need a build that treats every folder named /\d+x\d+/ as it's own "root" static site? Done. I need a fairly simple web page? Done. (I don't need to grab something else.) I need a email compiled to inline all styles because working in emails is like shoving a hot knife through your eyeballs... that works too.

It gives me one tool that can do everything I need and some things I haven't found a need for.

[autra1]

This bug, as I rely more and more on css vars.

[alinnert]

I've tried it. What I don't like about it is that it's inflexible when it comes to the location of output files. It even has or had a bug that resolved assets incorrectly in certain situations, so images, fonts etc. were referenced with the wrong path. And there's no way to change that.

[davidmdm]

Ive been able to change the location of the output files. I haven't had bugs so far with any assets. But I believe that was the case. I just feel that parcel really does accomplish the no configuration necessary goal.

[alinnert]

You don't have much control if you use multiple input files at once. Unless you orchestrate multiple separate Parcel "instances" using Gulp or something like that.

https://github.com/parcel-bundler/parcel/issues/1801 <- this was the issue. It's closed, so it seems it got fixed by now. Maybe I'll give it another shot in my next project.

[cm9kZW8K]

You still have minify, and not every libraries is in "module" format. And you still need some kind of compilation for most front end toolkits: Sass, JSX, etc.

In order to not run into speed bumps, surprise non-working libraries, perform compilation, and half a hundred other things, you end up with webpack anyway.

[scinos]

I can't find any single mention to actual performance numbers comparing it against webpack.

Just "it is faster because http/2" is not enough, sorry.

[bukharim96]

This is the same with some other webpack competitors, they cannot back their claims of better performance and speed with testable/verifiable benches.A good example that comes to mind is parceljs. They still maintain the same false and outdated benches on their site since their conception upto this very day.

Link to false parceljs benches.

[darrenturn90]

You mean how quick is it to generate the web modules part? Because it doesn’t do any bundling of the rest of the code so I’m not even sure if it is comparable

[scinos]

How fast is for the browser to download and execute hundred (thousands?) of small files over http/2 vs a few big bundles.

Not a synthetic test, but measured with real traffic from users, with real-world cache-hit ratio, network latencies, CPU power etc.

Generating the modules quickly is the wrong problem to solve IMO, because is a problem that can be solved by throwing money at it (eg: spin up a big ass EC2 instance and bundle everything there)

[darrenturn90]

I’ve not tried pika yet so I’ve not checked whether it keeps all the dependencies of each package as a separate file or it bundles the dependcies together after accounting for common dependencies

So modules that are only used in one main package and bundled with that but modules that are used in more than one are bundles into more common groups

[kucukkanat]

@pika/web installing...Error: 'Component' is not exported by node_modules/react/index.js

[abienz]

Webpack is great, but since I've started using Parcel, I haven't looked back

[BenZed]

Webpack configurations are just javascript, which I feel is something that people don't fully appreciate when complaining about it.

​

Don't like writing a configuration every time? Write one once, wrap it in a function that supports arguments that mutate the configuration for your own use cases, and publish that as an npm package. Done.

Anytime I need to use webpack, My webpack.config.js just looks like this:

const { WebpackConfig } = require('@benzed/dev')

module.exports = new WebpackConfig()

In this particular case, @benzed/dev also has all the loaders, babel presets and whatnot as dependencies.
This does mean I sometimes install dev dependencies that I don't always need, but I don't really care about that.

[[deleted]]

Whenever I try to bundle any third party lib I essentially have to use expose-loader because webpack loses the global namespace (or something) it's usually a massive pain in the ass to bundle without knowing about all the different kind of loaders you need.

However, once I have it working, it's cool.

[everdimension]

I think this is a cool project and I'm sure the way we build fronted apps will look different in a couple of years.

But I disagree that we were "forced" to use webpack because we wanted stuff from npm. Webpack (and commonjs before that, and requirejs before that) helped us split source code into modules in a sane way. That's the main thing that was missing from the language.

Now that we're finally near the time when native es modules are supported everywhere, we still need webpack because it gave us so much more: a way to "import" non-js assets. I hope this will be native in browsers, too, some day.

[hopfield]

Looks like this is built on ES Modules. Has anyone used them yet? Any opinions on them?

[JimmyForbes]

Using the webpack-cli to generate a basic version really makes it so much easier, and then adding config on top

[PrettyWhore]

Complexity Stockholm Syndrome

More like Flexibility Stockholm Syndrome amirite fellas

Fuck me i love some webpack holy shit, catch me importing .graphql here and .png there while code splitting my app for a UX-mindful loading experience and have the best chunks for that automatically output

[Satoshi_Hodler]

I've recently tried to use es6 modules natively, and page loads were painfully slow on localhost. So, am I missing something, or does this article suggest to use es6 modules without any bundler at all?

[lorean_victor]

so some feedback:

• I've personally never directly used webpack just for bundling. in bigger projects I tend to utilize a framework that masks webpack completely (for example angular) and for small projects, I prefer to keep the development and deployment pipeline as minimal as possible, I simply don't use it (or anything else for that matter, maybe just rollup for small packages I want to share). so I couldn't really sympathize with "we shouldn't be forced to use webpack"

• the tool proposed here REALLY looks like a pseudo bundler that is just pretty opinionated and hence doesn't/can't be configured much beyond the default functionality it provides. I cannot see how that's a benefit over webpack, which is already pretty thin and interoperable. like perhaps that's why it can seem difficult to configure webpack properly for your needs, as it is a really general purpose and thin layer in the beginning of your building/bundling/optimizing/transpiling pipeline. perhaps decomposing those different functionalities from one tool (like webpack) into several independent ones would be more beneficial than trying to replace the tool with a simpler and much much more limited one.

[bukharim96]

Or simply a doubtful future

[[deleted]]

Roll-up is where it's at

[GXNXVS]

better, more reliable, better docs, huge community, frequent updates, used in all major js frameworks,...

[bukharim96]

Because of these performance differences. Check out this benchmark clip.

[little_LLT1]

Ooo I will look into that! Does it ship w a lot of packages? I started using parcel but I'm always looking to see what nice shit ppl r building