Cool. I wouldn't take the critics too harshly. As someone who has configured a lot of webpack configs across multiple version of webpack and various versions of the plugins necessary to enable these features, I know exactly what you had in mind when you put this together. This is a very saturated technology stack, so people can't help but react to it as noise.
To the critics, in front-end land there are some programmers who believe that building an SPA is always a mistake. I am of the opinion that there are some types of applications that live in the browser that benefit from the UX enhancements that scripting can provide. We all know some examples.
Everyone knows that front-end land is a crazy wild-west with a lot of moving and a lot of breaking along with a lot of hype, trends, wheel-reinventing and cavalier attitudes towards security. The criticisms are mostly fair.
However, if you're building an SPA, there is a combination of tools out there that can provide a very conceptually clean (from an architectural perspective), performant, reusable, and highly productive and fun development experience. Of course, this doesn't mean these tools make building an SPA the appropriate engineering decision, they are just tools, only the requirements can dictate whether or not an SPA should be built.
This project attempts to preconfigure via webpack, what is IMO, the best selection of tools available for working on an SPA today. For me, these tools include:
- react
- react SSR
- bundle code-splitting
- es6 (or ts/es6+flow)
- es6 modules
- hot code and css reloading
- module aliasing
- css modules
- postcss
- reusing business and validation logic modules on the front and back end
All of these tools solve very specific (former) problems that one encounters while working on an SPA. Anyway, nice work!
For a different definition of zero though. While webpack now does something useful with no configuration (which is great), you will most likely end up adding lots of configuration for any application. Whereas with jetpack there's a chance that you won't (at least in my experience).
The challenge of course is the diversity of the ecosystem. Different projects are trying to address it differently, e.g.
* CRA is opinionated and unconfigurable
* Neutrino/pwa-cli propose a higher level plugin approach (i.e. install a plugin, without needing to configure it, in webpack plugins take many lines of configuration to configure)
* Next/Gatsby use a plugin system as well but are also specialised tools which means a lot of decisions can be abstracted
* jetpack tries to be application/use case/framework agnostic and provide you with the most commonly used/useful foundation, you can optionally add extra (e.g. sass), but you don't have to recreate the foundation (i.e. es6, jsx, modern css, css modules, hot reloading, serving, producing html, etc)
It's also about the DX, jetpack lets you run a dev server with a single command, it lets you analyse the bundle with a sigle command, it builds an optimised, split chunk bundle with a single command.
Just pointing out some motivations behind the project, I'm a fan of webpack, been using it for many years.
I remember one of the main Goal of WebPack 5 was sane defaults. ( I cant find the post anymore ) So hopefully the WebPack team can learn a lot from JetPack.
I had very similar critic of "server js", but with enough backlinks and a bit of time it seems to be solved. Though it's not exactly the same, in my case it was because of "noise", in this case it'd because of a competing brand. I'd say keep jetpack to see how it turns out, they are vastly different projects.
That's the joke he's making, they chose a name that needs to be said in full to avoid confusion because all abbreviations will just lead to more confusion
It's also an equally tremendous and even older classic game for the ZX Spectrum and VIC-20 by the artists later known as Rare https://en.wikipedia.org/wiki/Jetpac
Haven't looked deeper in it, but why does it happen all the time that people think they can fix complexity by adding another layer of complexity too it?
That's a fair point. I don't know what the best solution to this problem is, but I do think there's a problem.
Requiring the users to install 20 or more dependencies (@babel/, @postcss/, webpack-*, etc.) and write dozens of lines of configuration every time just doesn't feel right (or maybe it is..).
And we know what the developers need, they need to bundle a web project in a way that's optimised for production, js and css compiled to run on N (configurable) most recent browsers (optionally). But that's not that trivial in webpack, if it was, perhaps we wouldn't have so many abstractions trying to improve upon status quo.
Perhaps that's just an inherently difficult problem. E.g. there are many many ways to handle CSS, people use variety of transpilations such as TypeScript or Flow, projects have different requirements.
Another data point is that Parcel this problem in a much more "everything works automatically" way and it's really resonating with people.
Despite its apparent complexity, webpack is much more suited for the common case than it is for use cases with more complex requirements. To make an analogy, webpack is the HighCharts of the js build system. If you just need a chart it’s fine for that, or if you need to configure the chart and they’ve thought to add that config option it’s fine for that too. But if you have something esoteric and instead need a set of composable pieces, you probably need d3. The closest thing to d3 in this analogy is probably Broccoli.js.
Ideally webpack would be a set of composable pieces and you could use a simpler API for common use cases and drop down to a more granular abstraction when needed, but unfortunately as with HighCharts/d3, going from “batteries included” to “build from scratch” can be pretty jarring.
That's an interesting perspective. I'd add that one option in those situations could be to utilise Webpack plugins. In one project we were bundling JavaScript with webpack in a service behind an online IDE. We used a couple hand rolled plugins to do custom resolving (find the packages in this memory-fs structured by name/version), caching (what is safe to reuse) and sandboxing (only allow safe requires and plugins).
There is a problem with 'critical path use cases' for complicated products.
AWS used to be easy, now it's hard, and you almost need an AWS 'devops' person for it.
There is 100% a use case for an AWS light: simpler security model, basic services etc. that was hopefully on the ramp/learning curve to 'real' aws.
Git. My god git. A random smattering of arbitrary commands from the daily nuances of Torvalds. It's barely a product, it's useful only because it's powerful, but Git should have a set of commands that encompass everything you normally need to do (and reversible i.e. 'safe'), no 'golden rules' needed. Git in 'full mode' is really an administrator level tool. The arbitrary complexity of Git is really expensive and costing everyone a lot of pain and money. As a 'product' Git could have a couple of different API layers, if it had a different history.
I don't know enough about Webpack to really be specific, but it's feasible there is a problem.
Also - the makers of Wepback should consider the fact that someone went out and did this, and there there is a 'need of some kind not being met' possibly, after all, that's why we do these things.
Completely agree with how ridiculously complex AWS is already, with new services and products added every month. To me digital ocean sort of is AWS light, also really hope it stays like this.
I'm not entirely sure but I see this pop up a lot with webpack. Webpack is not inherently difficult to configure, it just requires you to read the documentation. All these solutions are doing is adding what they feel are sane defaults to the webpack experience. I don't see how this would appeal to someone who knows webpack well. In my opinion these solutions are just intended for a minority of new developers. For anyone else they could roll out their own faster than they could learn how to use abstraction layers built around someone else's.
On the other side, comments like yours also pop up with the same frequency. 'Just read the documentation', which sits at 50+ pages, does not make for a good developer experience. Projects like this are a symptom of the pain developers, new and old, feel when faced with a mountain of complexity just to get a module system and ES6 working on any small project.
Thing is, in my experience, the configuration can get quickly very difficult when the plugins don't play nice. It's not just webpack's configuration, it's also babel and babel-loader and postcss and postcss-loader and so on. Next thing you know, you're spending hours tweaking the config to get it to work.
I wanted something that is a good fouondation for _any_ project. If it needs extending, sure. But there's not much to remove.
You could argue you don't need all those plugins, but.. I would like to use jsx, async/await, css autoprefixing, css imports, hot reloading, compile it all for older browsers, split chunks and generate html. Those seem to be expected features today (or maybe that's a wrong assumption I have)?
Generell agree with the sentiment and also the specific case here.
One thing to note though is that a lot of the complexity of setting up Webpack correctly for a standard user is the very high and contradicting amount of SO/Google advice. This is caused by the (relatively) long history of Webpack and the major version jumps.
A layer on top doesn't carry this baggage so may indeed reduce complexity.
Funny you mention that. I was considering amending my post to include IndirectionStrategy.
But I was worried about opening a Pandora's box of indirection design patterns.
I mean, who are we to assume that you want to invoke all this indirection now? Better to wrap it all in an IndirectionCommand so you can invoke it whenever you want.
And there's no need to keep too many copies of identical IndirectionCommand instances around, so you'll also want an IndirectionCommandCache class, which will of course need an IndirectionCommandCacheStrategy because you don't want to just assume you know how and for how long people will want to cache those commands.
Nah, I think installing locally is more common and often recommended. But I personally like the convenience of executing ad hoc bits of js on my laptop using `node` or `nodemon`. Why not the same for browser javascript?
E.g. you could do something like:
cd ~/Desktop/foo
npm i somepkg
echo console.log(require('somepkg')()) > index.js
jetpack
And now you're running some pkg in the browser, to try/test it out. That's what the use case for this feature really is. For real apps, I install it locally as well or else a breaking change in the future could cause issues.
No language has this down, but there's an environment manager (pip, rustup, rbenv..) that try to do all, and avoid the need to handle more than one "magic" session in your bashrc(etc): "asdf":
Now, a few new languages do come with pretty decent "virtual env" thingy-s , but most stumble for a few years.
So far (past year) I've been pretty happy with asdf. Mostly use it for ruby and node - but also rust and golang, lisp, Java and ocaml (mostly as a "consumer" of various cli tools, and/or toy projects.
Another way to do this is to install Nix and direnv (and/or Emacs direnv-mode), then include a `use nix` statement in the .envrc file inside your project root.
Then, when you `cd` into your project directory, your environment with all its dependencies appears.
However, there are some downsides to this magical future tech:
+ Nix is hard to learn.
+ Not compatible with the standard environment managers for each language.
asdf is fine for small cli tools, but it fails way too often when you need something that requires more configs and system level integration, so then you end up installing nvm, rvm etc anyway.
The only thing I install globally is yarn. It just helps make things more reproducible to install everything locally (except yarn because we don't use npm directly).
Modules that are part of your build, tests and npm scripts should be installed locally so that any contributor can run npm install/yarn and the develop your project without any other need and they will also get the correct version of the module.
Global installs are for modules that are outside your projects dev cycle. With that in mind, a module such as nodemon can be installed both globally and locally. It depends on the use case.
No, you are not. The disconnect between actual developers that know better than to rely on global pollution and the silly READMEs and blog posts that prescribe it is an interesting phenomena. It's also gone on long enough that I feel a little shouting is in order.
How does this fare against parcel-bundler (https://parceljs.org/)? It does pretty much the same thing in a slightly different manner, and I'd like to know before I actually consider giving it a try.
If you want something truly configuration-free you could try Meteor. It's mostly an advanced zero-configuration (not even optional) build tool these days that supports automatic code splitting via dynamic imports, full npm integration, multiple bundles (old/new browsers), ...
Typescript support could be better, but I believe they're working on that.
Of course being zero-config you loose some flexibility.
The problem is, it's configuration free until it's not. If you end up having to pass in a partial Webpack config anyway, how much time are you really saying?
The reality is, at this point, Webpack has become a powerful tool with a big ecosystem around it. Configuration is not that complicated. It used to be an absolute mess, but these days, the documentation is really good and there are many sensible defaults. It's worth learning without these wrapper solutions.
Yes, but it's a solid foundation that they all try to offer. Raising the bar for what you get from the tool by default, ideally without making assumptions that would exclude it from any use cases.
I'd argue one of the reasons Next.js is so popular is because you can get started with no configuration. It has optional configuration, but all the webpack config, css, hot reloading, route splitting, etc. all serves as a solid foundation.
Interestingly, the most common criticism of Create React App is that it doesn't allow configuration. I agree with you, though: it makes sense that they don't allow it. (Although they do have some sensible exceptions, as in: you can "configure" a CSS preprocessor like Sass by installing it.)
To the critics, in front-end land there are some programmers who believe that building an SPA is always a mistake. I am of the opinion that there are some types of applications that live in the browser that benefit from the UX enhancements that scripting can provide. We all know some examples.
Everyone knows that front-end land is a crazy wild-west with a lot of moving and a lot of breaking along with a lot of hype, trends, wheel-reinventing and cavalier attitudes towards security. The criticisms are mostly fair.
However, if you're building an SPA, there is a combination of tools out there that can provide a very conceptually clean (from an architectural perspective), performant, reusable, and highly productive and fun development experience. Of course, this doesn't mean these tools make building an SPA the appropriate engineering decision, they are just tools, only the requirements can dictate whether or not an SPA should be built.
This project attempts to preconfigure via webpack, what is IMO, the best selection of tools available for working on an SPA today. For me, these tools include:
All of these tools solve very specific (former) problems that one encounters while working on an SPA. Anyway, nice work!