Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Jetpack – Webpack made more convenient

github.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: Show HN: Jetpack – Webpack made more convenient

#51

Post by e12e »

kn8 wrote: post #6
ronilan wrote: post #3

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?

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 wh…

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.

Re: Show HN: Jetpack – Webpack made more convenient

#53

Post by hiccuphippo »

ronilan wrote: post #3

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?

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.

Re: Show HN: Jetpack – Webpack made more convenient

#55

Post by type0 »

e12e wrote: post #51
kn8 wrote: post #6

Earlier quoted context omitted.

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 wh…

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…

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.

Re: Show HN: Jetpack – Webpack made more convenient

#56

Post by Jarwain »

guessmyname wrote: post #44
fimdomeio wrote: post #2

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/

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…

What about rocketpack, to fit its current naming theme?

Or spiderpack?

Netpack?

Silkpack?

Re: Show HN: Jetpack – Webpack made more convenient

#57

Post by turdnagel »

hiccuphippo wrote: post #53
ronilan wrote: post #3

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?

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`

Re: Show HN: Jetpack – Webpack made more convenient

#59

Post by GlennS »

e12e wrote: post #51
kn8 wrote: post #6

Earlier quoted context omitted.

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 wh…

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…

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/

Re: Show HN: Jetpack – Webpack made more convenient

#60

Post by root_axis »

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!
Post reply on HN