HN Explorer

8 comments

[ 0.17 ms ] story [ 29.6 ms ] thread
jypepin
> But of course, you can continue to use whatever other tools you like: Beef up your dev experience (Babel, TypeScript) or optimize how you ship in production (Webpack, Rollup).

So I assume what one would end up with if they decided to us pika for their dependencies is a project that still uses webpack, but in addition uses pika instead of webpack for dependencies, ending up making pika 1 more build tool in the chain instead of a replacement.

Is that a right assumption?

CharlesW
> Is that a right assumption?

I believe so, assuming that you're using Webpack for more than just bundling. In other words, it removes the need for a bundler but not other processes you might want in your build system.

r-cid
Depends on your browser targets-- but, yes, most likely. Personally I'm using pika with some of my electron apps-- and I love it for that.
ramon
No, the idea is that the dependencies are cached in js in the frontend and not loaded all dynamically by routers and SSR. Basically routers are gone, no need for rebuild all the time. I think it’s a more optimized approach it’s less overhead inicial loading and we can load css in a more native way it makes more sense then the current build env we have.
k__
Routers?
y4mi
That's how js devs call the logic matching urls to views
catchmeifyoucan
I didn't really understand here. So am I not supposed to use npm install anymore? Or does pika read node_modules and make them web compatible. Cool stuff nonetheless.

Would also be great if there was a way/tutorial that says here's how you move from web pack to Pika - and how long that might take.