Earlier quoted context omitted.
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 any…
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.
Show HN: Jetpack – Webpack made more convenient
31–40 of 79 posts
Re: Show HN: Jetpack – Webpack made more convenient
#32Earlier quoted context omitted.
It is also an Nvidia AI SDK: https://developer.nvidia.com/embedded/jetpack
It's also a rocket belt. :P
Re: Show HN: Jetpack – Webpack made more convenient
#33Haven'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?
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.
Re: Show HN: Jetpack – Webpack made more convenient
#34Haven'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?
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 any…
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)?
Re: Show HN: Jetpack – Webpack made more convenient
#35Run 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?
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.
Re: Show HN: Jetpack – Webpack made more convenient
#36Earlier quoted context omitted.
Just wrap it in an IndirectionManager and instantiate that via an IndirectionManagerFactory and you're good to go. :)
You forget the IndirectionPolicy interface...
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.
Re: Show HN: Jetpack – Webpack made more convenient
#37There are a lot of "configuration-free" Webpack solutions popping up. The one thing that they all have in common is optional configuration.
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.
Re: Show HN: Jetpack – Webpack made more convenient
#38Hey 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/
They should rename it to WebPackJetPack, or WPJetpack for short. That will reduce confusion, right?
Re: Show HN: Jetpack – Webpack made more convenient
#39Run 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?