3 ms·
Of npm (the online database of packages) I hate the fact they never forced a clear distinction between package meant to be used only in the backend with node, p
by yulaow 4y ago
Of npm (the online database of packages) I hate the fact they never forced a clear distinction between package meant to be used only in the backend with node, package meant to be used only on the fe inside a browser, and package which can be used in both. I mean just having a flag for that would be useful, simple and solve a lot of headaches
- andrew_ 4y agoThe beauty is that those distinctions don't exist. There are no limitations. There are also no guardrails or training wheels.
- wizofaus 4y agoIn what case would an npm package for talking to an external database be actually useful for a frontend project? I mean, yes, if you're only ever running the tool inside a LAN where that access exists, I suppose it's conceivable... And plenty of frontend packages that rely on storing state in the browser's window object (Redux etc.) would presumably be a bad idea to use for most backend projects, but no doubt somebody's found a way to make it work. I suppose I'm not disagreeing with you, but the GP kinda has a point too.
- andrew_ 4y agoA couchDB package perhaps, for which the db supports access via http. Or look at any of over 1000 of sindresorhus' packages - a majority of which are meant to be used in both environments. I've seen plenty of backend services using state trees and mobX style packages.