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

WMR – Tiny all-in-one development tool for modern web apps

github.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: WMR – Tiny all-in-one development tool for modern web apps

#21

Post by BadInformatics »

developit wrote: post #10
brundolf wrote: post #6

For those like me who missed it in the title: this is only for Preact, which is part of what allows it to be so comprehensive. Preact is cool, but "all-in-one development tool for modern web apps" may be overselling the scope a little bit

Hmm - it's not actually specific to Preact, it's just built by the Preact team and we use Preact in the docs. We are missing a bunch of documentation that would have made this clearer though, which I apologize for. While there are some optimizations for Preact in WMR, it can be used for vanilla JavaScript / Lit / Vue / Svelte / etc just fine.

Can you talk more about how WMR fits into the morass of Snowpack, Vite, Rome, Parcel etc.? The self-contained aspect looks great, but I'm at a loss as to how this doesn't also add more entropy into the pool of "next-gen" JS build tools (and thus more analysis paralysis for webdevs)...

Re: WMR – Tiny all-in-one development tool for modern web apps

#23

Post by chrisweekly »

eyelidlessness wrote: post #12
corytheboyd wrote: post #2

Looks neat, but why is this a thing? > import "packages" from npm without installation IIRC rollup does the same thing by default. This project mentions it uses rollup so maybe that’s where it’s coming from. Using npx to run executables also does this IIRC. And I never want it, especially if I have to opt-out. I want there to be friction to adding dependencies, it should be a carefully considered process. Otherwise,…

I’m honestly astonished that this is a selling point. Sure, fewer steps sounds nice... but in addition to your (correct) point about friction when adding dependencies, it’s also a security and compatibility nightmare. And it likely makes using tools like typescript an exercise in frustration if it’s even possible. Edit: I’d also add that npx has all of the same problems multiplied by being even less frictionful.

Yeah, pnpm helps fix a related issue wherein flat node_modules (ie, npm or yarn) can lead to the existence of undeclared dependencies. Check it out if you care about proper dependency mgmt.

Re: WMR – Tiny all-in-one development tool for modern web apps

#24

Post by eyelidlessness »

chrisweekly wrote: post #23
eyelidlessness wrote: post #12

Earlier quoted context omitted.

I’m honestly astonished that this is a selling point. Sure, fewer steps sounds nice... but in addition to your (correct) point about friction when adding dependencies, it’s also a security and compatibility nightmare. And it likely makes using tools like typescript an exercise in frustration if it’s even possible. Edit: I’d also add that npx has all of the same problems multiplied by being even less frictionful.

Yeah, pnpm helps fix a related issue wherein flat node_modules (ie, npm or yarn) can lead to the existence of undeclared dependencies. Check it out if you care about proper dependency mgmt.

It’s very much on my list. I was really gunning for yarn 2 for some greenfield projects but after finding its awful rough edges I looked more at pnpm and it feels much more in line with what I want.

Re: WMR – Tiny all-in-one development tool for modern web apps

#25

Post by franga2000 »

developit wrote: post #9
Xenograph wrote: post #4

> If you'd like ESLint to be set up for you, add --eslint to the command. Note: this will use 150mb of disk space. This is insane. No wonder they were motivated to create a minimal development tool. How could a CLI linter require 150 MB of disk?

tbh I think a good chunk of that size is babel-parser, which we're looking into removing from the preact ESLint preset. Still quite a difference though.

Still, that's just a parser, right? An entire Python installation can fit in that space - parser, interpreter, stdlib and package manager. (and I'm sure many others too, python is just what I'm familiar with)

Re: WMR – Tiny all-in-one development tool for modern web apps

#26

Post by developit »

franga2000 wrote: post #25
developit wrote: post #9

Earlier quoted context omitted.

tbh I think a good chunk of that size is babel-parser, which we're looking into removing from the preact ESLint preset. Still quite a difference though.

Still, that's just a parser, right? An entire Python installation can fit in that space - parser, interpreter, stdlib and package manager. (and I'm sure many others too, python is just what I'm familiar with)

Oh I totally agree it's strange, haha. The cost tends to be magnified in Node land since everything is a million files.

Re: WMR – Tiny all-in-one development tool for modern web apps

#27

Post by developit »

BadInformatics wrote: post #21
developit wrote: post #10

Earlier quoted context omitted.

Hmm - it's not actually specific to Preact, it's just built by the Preact team and we use Preact in the docs. We are missing a bunch of documentation that would have made this clearer though, which I apologize for. While there are some optimizations for Preact in WMR, it can be used for vanilla JavaScript / Lit / Vue / Svelte / etc just fine.

Can you talk more about how WMR fits into the morass of Snowpack, Vite, Rome, Parcel etc.? The self-contained aspect looks great, but I'm at a loss as to how this doesn't also add more entropy into the pool of "next-gen" JS build tools (and thus more analysis paralysis for webdevs)...

The tooling space isn't broad enough to allow for differentiation across the board, so we have a number of tools that are working to validate/popularize a subset of functionality on top of the basics.

WMR's unique take is basically to be instant in every possible way, and to provide an ideal substrate for us to build and show Preact features that rely on bundler semantics. We have maintained a Webpack-based build tool for Preact for a while, and wanted to explore what a total re-think would look like. We also spent a while building out new pieces of the bundler that fit this model better than repurposing existing generalized tooling. This is one of the reasons WMR builds as fast as it does despite doing so much optimization work - it's designed around a singular goal and we allowed for very limited compromise.

I think that after a few years we will see a corresponding consolidation of the tools you mentioned, as the dust settles on this newer dev/prod split paradigm and it's effect on the bundler plugin ecosystem.

Post reply on HN