Show HN: Jetpack – Webpack made more convenient(github.com)
github.com
Show HN: Jetpack – Webpack made more convenient
https://github.com/KidkArolis/jetpack
78 comments
Woof sometimes HN can be pretty unforgiving. Remember the human guys. Good job man. Keep it up. Thanks for contributing to open source.
Agreed. Webpack's configuration is so daunting that, well, this is so obviously needed.
Not anymore! Webpack 4 is ~"zero-config"!
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.
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.
Hey just fyi in case you don't know, jetpack[1] is the name of a very well known wordpress plugin by Automatic. Might cause some confusion.
[1] https://wordpress.org/plugins/jetpack/
[1] https://wordpress.org/plugins/jetpack/
It certainly confused me. I even read the title as "Jetpack - Wordpress made more convenient" simply because my expectation had been set.
It's also a tool for Android development.
It was also a Mozilla addons SDK: https://wiki.mozilla.org/Jetpack
It's also a set of Android components: https://developer.android.com/jetpack/
It is also an Nvidia AI SDK:
https://developer.nvidia.com/embedded/jetpack
It's also a rocket belt. :P
It's also a tremendous classic game for the Apple Macintosh https://www.macintoshrepository.org/3885-jetpack
It's also how militaries buy airplanes in bulk
It's also a musical duo who specializes in using "surf instruments". https://en.wikipedia.org/wiki/Jetpack_(musician)
Let's just end this here: https://en.wikipedia.org/wiki/Jetpack_(disambiguation)
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
Also a tool to compress WINS/DHCP databases: https://docs.microsoft.com/en-us/windows-server/administrati...
They should rename it to WebPackJetPack, or WPJetpack for short. That will reduce confusion, right?
Yes, my first thought was this post was WP related. (and then I actually read the link. ;) )
Searching for “jetpack” in a fresh —no cookies— browser session returns:
• https://jetpack.com/
• https://twitter.com/jetpack
• https://wordpress.org/plugins/jetpack/
Which are the canonical URLs for JetPack, by Automatic.
KidkArolis will have a hard time promoting his project.
---
My suggestion for KidkArolis is to rename his project to one fo these:
• “ConvePack” considering the slogan “Webpack made more convenient”
• “WrapPack” considering the description “Jetpack wraps webpack”
• “SimplePack” assuming his project is simpler than WebPack
• https://jetpack.com/
• https://twitter.com/jetpack
• https://wordpress.org/plugins/jetpack/
Which are the canonical URLs for JetPack, by Automatic.
KidkArolis will have a hard time promoting his project.
---
My suggestion for KidkArolis is to rename his project to one fo these:
• “ConvePack” considering the slogan “Webpack made more convenient”
• “WrapPack” considering the description “Jetpack wraps webpack”
• “SimplePack” assuming his project is simpler than WebPack
OR JustPack?
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 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.
What about rocketpack, to fit its current naming theme?
Or spiderpack?
Netpack?
Silkpack?
Or spiderpack?
Netpack?
Silkpack?
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?
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.
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.
>> To me digital ocean sort of is AWS light, also really hope it stays like this.
DO just added Kubernetes support. Despite being pretty darn technical I don’t even know what kubernetes is and never intend to know.
So no, Digital Ocean is not planning to stay simple.
DO just added Kubernetes support. Despite being pretty darn technical I don’t even know what kubernetes is and never intend to know.
So no, Digital Ocean is not planning to stay simple.
The eventual evolution of DO into an AWSesque service provider is how market becomes ripe for yet another 'lite' service :)
Perhaps because David J. Wheeler said "We can solve any problem by introducing an extra level of indirection."
Except too many levels of indirection...
Just wrap it in an IndirectionManager and instantiate that via an IndirectionManagerFactory and you're good to go. :)
You forget the IndirectionPolicy interface...
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.
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.
I guess that threshold is different for everybody, who's to say what works best in a certain situation?
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.
I'm sorry but you should have a basic understanding of something before using it, that is just common sense.
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)?
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)?
Isn't that what programmers do? Abstractions are great...
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.
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.
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.
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).
Excellent point, how many layers of accidental complexity are we on now? I have lost count.
Run anywhere without installing locally, just like nodemon.
I npm install everything locally, never globally, and use npm run script to easily execute (and chain) stuff.
Am I in the minority?
I npm install everything locally, never globally, and use npm run script to easily execute (and chain) stuff.
Am I in the minority?
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.
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.
I can count with one hand the number of things I install globally. Everything else is local.
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:
E.g. you could do something like:
cd ~/Desktop/foo
npm i somepkg
echo console.log(require('somepkg')()) > index.js
jetpack
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":
https://github.com/asdf-vm/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.
https://github.com/asdf-vm/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.
https://github.com/direnv/direnv https://nixos.org/nix/
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.
https://github.com/direnv/direnv https://nixos.org/nix/
Interesting. I've been considering nix, but wasn't aware of direnv. Should be a sensible combination.
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.
I do this with app specific stuff. Only general utilities do I install globally.
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).
Even better, use npx (bundled with npm): https://www.npmjs.com/package/npx
> Am I in the minority?
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.
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.
I always assume everybody uses pnpm, which is the best disk/bandwidth saver utility every written.
WebPack gives me errors when I npm run it. I need to directly run ./node_modules/.bin/webpack which leaves a bad taste in my mouth.
Add a script in your package json that just runs `webpack`. Then you can run e.x. `npm run webpack`
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.
Thanks!
[1]:
Thanks!
[1]:
And then weirdly you have also this alternative to webpack from the Elm community:
https://github.com/NoRedInk/jetpack
Also called Jetpack...
https://github.com/NoRedInk/jetpack
Also called Jetpack...
There are a lot of "configuration-free" Webpack solutions popping up. The one thing that they all have in common is optional configuration.
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.
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.
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.)
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.
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.
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.
Of course being zero-config you loose some flexibility.
We already have parcel.js which does all of this really well.
What was the motivation for this given existence of CRA? What are the main differences?
I'd say:
- meant to be not React only
- less opinionated in that it doesn't include jest
- smaller in scope/code, so easier to understand what it does by reading the code (?)
- allows extending configuration
- focus on SPA use case with jetpack/serve or proxy features
I should probably give CRA a proper spin though, it's popular and V2 seems pretty good.
- meant to be not React only
- less opinionated in that it doesn't include jest
- smaller in scope/code, so easier to understand what it does by reading the code (?)
- allows extending configuration
- focus on SPA use case with jetpack/serve or proxy features
I should probably give CRA a proper spin though, it's popular and V2 seems pretty good.
Isn’t that the name of a Wordpress plugin?
https://wordpress.org/plugins/jetpack/
https://wordpress.org/plugins/jetpack/
Do you know what else works almost without configuration, it's fast and produces small minifiable bundles? Browserify.
Yeah, I mention it in the Comparison[1] section of the docs ;)
[1] https://github.com/KidkArolis/jetpack/blob/master/docs/08-co...
[1] https://github.com/KidkArolis/jetpack/blob/master/docs/08-co...
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!