4 ms·

I’m a self taught Python programmer. I haven’t don’t much front end. Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen

I’m a self taught Python programmer. I haven’t don’t much front end. Why do some JS devs import tiny packages to do simple things? I don’t feel like I’ve seen this behavior in Python. Is it because browsers are an awful environment?

tehbeard 5y ago
stdlib of JS vs python or php is absolutely tiny. It's improving over time, but it's still playing catchup.
- Sebb767 5y ago
  And if you're optimizing for the browser, you can't count on the improvements being there. So you still want to use third-party libraries for their polyfills.
fault1 5y ago
npm (or yarn) for the most part works much better than python package managers
aaaaaaaaaaab 5y ago
They don’t know better.
gremlinsinc 5y ago
I prefer to look at the code, decide if A. it's worth it, B. it wouldn't be funner/better to just clone it as a 'plugin' in my own code, and C. it looks like it has a good team/support around it.
tjpnz 5y ago
They took the Unix philosophy of doing one thing well and drove it off a cliff.
- broknbottle 5y ago
  I literally lol’d. Thank you for the laugh
rk06 5y ago
In browser land, the less code you ship, the better. Removing dead js code is hard, because of its dynamic nature and using common js imports making it harder for treeshaking algorithms. So, people had incentive to write and use smaller packages. Now, the situation has improved. If you use esmodules all the way, and only import what you need, then your bundler can remove unused modules from final build
- herbst 5y ago
  > In browser land, the less code you ship, the better That's kinda funny. These node tools I run into these days usually take forever to install, waste a lot of space due to creating their own package mirror and generally are prone to break because of dependencies. There is usually nothing tiny about them, even thought they only have a few lines of code.
  - kavaruka 5y ago
    usually the "node_modules" folder (with tons of files) is not deployed on production, for front-end application that are going to run in the browser when we make a build for the browser we bundle all dependencies into fewer files that only contain the code that is used
hobofan 5y ago
I think it's more because dependencies are generally used less because all the tooling around it is much worse than in other languages.
sibit 5y ago
As someone who does front-end JS stuff and uses a bunch of packages here is why I do it: I got tired of copying and pasting the same classes between projects. The worse part was I'd add new features to the newer projects and when I would have to go back to work on something from a year or two ago I'd have to spend time backporting all the new code. I also don't like how bloated a bunch of the "popular" packages are. Why do something in 40kB of JS when you can do it in 3kB. Smaller is faster which is important to me because one of my main selling points is that I build modern-looking marketing websites that load and render under 5 seconds on a slow 3G connection.
- cmckn 5y ago
  > I got tired of copying and pasting the same classes between projects. The worse part was I'd add new features to the newer projects and when I would have to go back to work on something from a year or two ago I'd have to spend time backporting all the new code. Why not create your own common library and publish it to a private repo? There's a lot of options between using a stranger's package and what you're describing.
  - CRConrad 5y ago
    > Why not create your own common library and publish it to a private repo? There's a lot of options between using a stranger's package and what you're describing. Exactly what I thought. Fascinating how they can have missed this obvious solution.

tehbeard 5y ago

stdlib of JS vs python or php is absolutely tiny. It's improving over time, but it's still playing catchup.

Sebb767 5y ago
And if you're optimizing for the browser, you can't count on the improvements being there. So you still want to use third-party libraries for their polyfills.

fault1 5y ago

npm (or yarn) for the most part works much better than python package managers

aaaaaaaaaaab 5y ago

They don’t know better.

gremlinsinc 5y ago

I prefer to look at the code, decide if A. it's worth it, B. it wouldn't be funner/better to just clone it as a 'plugin' in my own code, and C. it looks like it has a good team/support around it.

tjpnz 5y ago

They took the Unix philosophy of doing one thing well and drove it off a cliff.

broknbottle 5y ago
I literally lol’d. Thank you for the laugh

rk06 5y ago

In browser land, the less code you ship, the better. Removing dead js code is hard, because of its dynamic nature and using common js imports making it harder for treeshaking algorithms. So, people had incentive to write and use smaller packages. Now, the situation has improved. If you use esmodules all the way, and only import what you need, then your bundler can remove unused modules from final build

herbst 5y ago
> In browser land, the less code you ship, the better That's kinda funny. These node tools I run into these days usually take forever to install, waste a lot of space due to creating their own package mirror and generally are prone to break because of dependencies. There is usually nothing tiny about them, even thought they only have a few lines of code.
- kavaruka 5y ago
  usually the "node_modules" folder (with tons of files) is not deployed on production, for front-end application that are going to run in the browser when we make a build for the browser we bundle all dependencies into fewer files that only contain the code that is used

hobofan 5y ago

I think it's more because dependencies are generally used less because all the tooling around it is much worse than in other languages.

sibit 5y ago

As someone who does front-end JS stuff and uses a bunch of packages here is why I do it: I got tired of copying and pasting the same classes between projects. The worse part was I'd add new features to the newer projects and when I would have to go back to work on something from a year or two ago I'd have to spend time backporting all the new code. I also don't like how bloated a bunch of the "popular" packages are. Why do something in 40kB of JS when you can do it in 3kB. Smaller is faster which is important to me because one of my main selling points is that I build modern-looking marketing websites that load and render under 5 seconds on a slow 3G connection.

cmckn 5y ago
> I got tired of copying and pasting the same classes between projects. The worse part was I'd add new features to the newer projects and when I would have to go back to work on something from a year or two ago I'd have to spend time backporting all the new code. Why not create your own common library and publish it to a private repo? There's a lot of options between using a stranger's package and what you're describing.
- CRConrad 5y ago
  > Why not create your own common library and publish it to a private repo? There's a lot of options between using a stranger's package and what you're describing. Exactly what I thought. Fascinating how they can have missed this obvious solution.