It seems it’s impossible to make a website these days without using some kind of package manager, whether its npm for your frontend dependencies or something like composer for your php dependencies. If you need to do something a bit tricky then, chances are, someone else had the same problem and created a package to solve that problem so you can just add it to your dependencies, install it and away you go. But does this mean web development is just copying and pasting other people’s work into your website?
Some people don’t like packages at all and would rather write everything from scratch so they know what everything does and they know that only the code that is needed is in their finished product. I don’t have a problem with that. I kind of admire the determination and control they have.
I used to be a bit like this, as I had the idea that using other peoples packages was kind of like cheating, just copying someone else’s work into yours.
If you can’t beat them, join them…
But eventually it seemed like everyone was doing it. Every blog, forum and tutorial would start along similar lines of, pull in this package to do X, this library to do Y, so it seemed like there was no choice but to learn about packages.
Once I started learning about composer and npm I realised how powerful they were. Rather than spending hours of my own time solving a problem I could use a package that would do something I needed. I could build upon what someone else had done and keep on developing faster solutions.
Once I was used to the idea of pulling packages into my project there was no stopping me. Why should I spend time writing a function to do what I needed when I can pull in a library to do that for me? Feature Z sounds a bit tricky to develop, I can just pull in package A and all would be good.
Dependency Hell
But the end result was not as I expected. Rather than being in developer heaven, I was in dependency hell.
My vendor folder was huge and my node modules folder was a black hole of recursive dependencies and my project had so many packages included it was bloated beyond belief, with a huge JavaScript file, despite many attempts at minification.
I had been greedy, lazy and irresponsible, trying to take as many shortcuts as I possibly could to make my life easier, but only resulting in making it more difficult.
Finding the middle ground
So I realised that there must be a middle ground. Somewhere where I pull in essential packages and really think hard about what else I include. I learnt a lot about JavaScript and realised many package developers work very hard to allow you to only pull in the bits of their packages that you want to.
You don’t need to pull in the entire package if you only want one feature. Just import the feature you need into your compiled JavaScript file so you are not forcing your visitors to download code that will never run.
I used to use Foundation by Zurb and my habit was to include their compiled JavaScript library just in case I needed every feature at some point in the future, but then I realised that if the project I was working on just needed an accordion then I only needed the core package and the accordion JavaScript modules. You could then add additional modules as and when you needed them.
Package managers like composer and npm also offer the facility of saving dependencies as either production or development, meaning you can specify which should be pulled down for your local development only and which are only needed for production. An example of this is phpunit. You don’t want this on your production server, only on your local development environment where you run the tests, so just add it to the require-dev section of your composer.json.
I think everyone needs to learn how useful package and dependency managers, but also to spend some time learning about the best ways of using them, and whether you really need to include the whole package or spend a little bit of time cherry picking just the features you need to include.
Top comments (11)
I think we must copy and paste every single line of code that is out of our business core logic.
The only important part of the code for your company is the one which solves the solution to the problem that your company has found. The part that makes it valuable for an user.
The rest of things that a product does like i/o, http, logs, sort a list, render a title, etc... are just accidental complexity of your current solution to the problem.
Of course, we have to learn how to take advantage of this tools and not overuse them.
Is using a package really the same thing as copy/paste?
Technically yes, you might as well paste react.js into your index.js and it would almost be the same..
🤨 Interesting, never thought about it that way.
But then, any kind of development is mostly copy-pasting, if you use non-self-made abstractions. Fine with me (▀̿Ĺ̯▀̿ ̿)
When it comes to packages for the client-side, I'm very picky and will go to great lengths trying to avoid the usage if I can. It's code we pipe to our users unchecked, so everything that is not super-popular and battle-tested (like Angular, React, jQuery, Lodash, you get it..) is carefully evaluated for necessity.
& a lot of those dependencies come with nice security holes that may or may not be found and may or may not force you to upgrade to a new version that is now incompatible with some other package that is dependent on it and there may be no way to know until it crashes since JavaScript won't tell you about changes to any prototype definition!
Node is great for spinning up quick and dirty apps or microservices that are never going to be exposed to the public internet but, it's a joke for anything serious that's going to allow hackers to hammer on it 24/7. There's a reason why most backend languages are statically typed, or require you to follow very strict coding standards for not changing interfaces that you have no control over in someone else's package. TypeScript helps but it's like putting a band aid on an arterial wound.
I've seen that happening far too many times and I've only joined the JavaScript bandwagon about 3 years ago...
Yep most of front and backend development these days means thorough understanding and usage of package managers (npm, composer, yarn etc). Knowing how to use them right and not overuse them only comes with experience (actually using them) and avoiding past mistakes.
In my opinion web development is only necessary for writing (quick and dirty) user interfaces. The essential part, the logic and the algorithms will be behind these interfaces and packages are almost non existent in that domain. The best you can get is for example an XML parser to parse the file to get the essential information to start building your data structures and implement the logic,which is the hardest part for computer scientist the actual math! I can see why one could state that web development is just copying/pasting, as most of the web developers are something between a ui designer/dev-ops specialist which on occasion add some lines of code which they have to think about for 10 minutes tops. Most of the web development does not include hard math, data structures or complicated logic. In essence what you are doing is just moving around stuff others have written, which most of the time involves normalizing user input from fields or styling the interface... So yes, it is just copying and pasting.
If the guy building my house buys mortar and bricks, instead of harvesting Earth and burning the bricks on-site, I don't consider this cheating or bad. He will finish faster, and focus on assembling the pieces rather than inventing them. I guess it is the same with software development, not only necessarily web development. Anyway, nowadays if you build a complex web app, that is far from a website as it used to be when you smashed together some HTML+basic PHP to launch your little homepage 15 years ago.
Of course you should read through the source code of your packages, understand what it is doing, and only pull it in, if the code looks clean, is tested, and coheres with your coding standards.
And you can always clone the package, enhance it, throw out stuff you don't need, host it on your private repo and use that version. Still saves you a ton of work, plus you have more controll over the code running your app. Don't think of a package as a Magic Blackbox :-)
I like that bricks and mortar analogy. You can use a framework as the scaffolding!
I’m sorry but I totally disagree with this title. If you don’t understand the code your building then how can you trust it and call yourself a professional developer. I personally investigate he integrity and suitability of all packages I knowingly use otherwise how can I trust them? Furthermore, open source projects are not copy paste, as a community of developers it is what drives the industry forward. We should all also attempt to give back in some way not just constantly consume the hard work of others and fob it off as our own. Getting used to doing this will also impair you eventually when you have to think outside the box for your company to solve a problem you can’t find a package for.
The way the market is you can't really code everything from scratch to make a different website. I like what some people have said about being careful about it and checking it. If you make websites for small businesses then you can't code for weeks because they want certain features. You would never make any money. But at the same time you do have to be careful with what you use and how you use it.
Same reason I stopped using bootstrap and libraries like it. I took things I liked about bulma and bootstrap and wrote a light css library.