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/
Show HN: Jetpack – Webpack made more convenient
61–70 of 79 posts
Re: Show HN: Jetpack – Webpack made more convenient
#62There are a lot of "configuration-free" Webpack solutions popping up. The one thing that they all have in common is optional configuration.
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.
Re: Show HN: Jetpack – Webpack made more convenient
#63Earlier quoted context omitted.
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
Re: Show HN: Jetpack – Webpack made more convenient
#64Hey 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/
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…
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.
Re: Show HN: Jetpack – Webpack made more convenient
#65Hey 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/
Re: Show HN: Jetpack – Webpack made more convenient
#66Haven'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?
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.
Re: Show HN: Jetpack – Webpack made more convenient
#67Haven'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…
Re: Show HN: Jetpack – Webpack made more convenient
#68Earlier quoted context omitted.
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…
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.
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.
Re: Show HN: Jetpack – Webpack made more convenient
#69Earlier quoted context omitted.
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.
Re: Show HN: Jetpack – Webpack made more convenient
#70Haven'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…
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.