Comment by Jason Knight on "Which tool you use for tree-shaking?"

Ah tree shaking, the latest sick buzzword for pathetically trying to clean up crappy code created by sloppy coding habits like blindly trusting other people's libraries when you don't know enough about the underlying language to know if those libraries, packages, or frameworks are worth a damned in the first place.

Aka a problem that used to not even EXIST back when we had optimizing compilers that would remove dead code for you anyways, and didn't mindlessly rely on dynamic modules and interpreted scripting for EVERYTHING.

Whilst dead code removal can be important, if you get to the point of needing some tool to handle it, you've got a shoddy codebase slopped together by too many cooks who didn't actually give a flying purple fish what it was gonna taste like.

There's a reason a friend of mine likes to refer to most such codebases as "shantytown sausages filled with mystery meat".

Summed up pretty well. I can't understand the fast pace development these days, which hardly care about all these stuffs and regret later on, when things went out of control. After that, they try all this but once it is dead, it cannot be brought back. I prefer to have clean code base which take time, rather than sloppy code which finished swiftly!

I don't believe you know what you're talking about. Libraries are out there to make the job of coding simpler and faster whilst producing more legible code that is easier to maintain months to years down the road.

Tree shaking is necessary, because you don't necessarily need every function these libraries provide, so there's no point in shipping them to every client.

Raging against the usage of libraries is honestly a toxic attitude.

Rajkumar I attribute it to the "credit mentality" -- pay more later for something you can't afford now. Everyone is in such a rush for results today they are willing to throw their own future under the bus to do it.

Projects -- even security is king stuff like banking -- are now expected in months or even weeks out of greenhorns when it's the job for experts to take a year on FOR GOOD REASON. There is no future planning on ANY of this and at best the lame excuse used over and over is:

"Well we'll cross that bridge when we get to it"

Failing to notice there is no bridge, the river is half a klic deep, moving swiftly enough to topple a barge, and they didn't set themselves up with anything to build that bridge.

That eagerness and instant gratification mentality making it SO easy for scam artists predators to peddle their wares, and people not qualified to do their jobs to squeak by on no effort.

THEN people wonder why most startups fail!

Joe Gaspar We aren't talking about usage of libraries. But we are talking about cleaning up of the shitty code in those libraries. We have all the time to do it while developing, but we choose to ignore it today so we can shake the tree in future, when things were not so in control! There is a reason why we have standards and software development life cycles. And that is not how you do it.

Libraries are out there to make the job of coding simpler and faster whilst producing more legible code that is easier to maintain months to years down the road.

That's the ideal, but these days delivery on that promise is... lacking. MAYBE I've been dealing with HTML/CSS/JS/PHP too much lately, but these are the types of issues that just didn't happen "back in the day". Even the crappiest compilers from the '80's wouldn't link code into the executable you weren't using. These are the types of problems that only showed up in interpreted languages, and back then you couldn't even build a useful program with those -- at least on microcomputer technology. Despite decades of trying.

It's only really the past ~20 years that interpreted languages -- or near interpreted -- have returned to prominence and these types of problems show up again.

But there's more to it than that -- people are now diving for frameworks and packages before they even know enough about the underlying language TO EVEN KNOW IF THEY NEED ONE! See the mind-numbing asshattery that is bootcrap for the pinnacle of this stupidity -- where somehow an entire generation of programmers have been suckered into believing that writing two to ten times the markup and as much CSS as you'd have without the framework (not even counting the size of that framework in the total) is somehow "easier", "more productive", or "better for collaboration".

You know what's easier, more productive, and better for collaboration? Clean simple code without endless pointless bloated dependencies!

In that way with full stack JavaScript and the concept of "packages" we're getting code out of places that's so poorly slopped together from other people's work, the people who "wrote" it don't even understand how it works!

A stunning example of this is the "package that broke half the web" from the steaming pile of developer ineptitude that was kik. Not that I personally was aware of any websites or programs it actually broke -- half the web being a clickbait headline for it. The function when his package came down that most commonly broke things was a "simple' left pad.

Except it wasn't simple. It was a poorly written convoluted mess that looked more like somebody who didn't know JavaScript just blindly ported with no changes the code from the legendary K&R C book.

People are using these packages blindly but nobody is poking their head into them to understand how they work, why they work, where they could go wrong, how to maintain them if the original maintainer says "screw it I'm done", or any other sane and rational practice that USED to be the core of dealing with any situation where you were at the hands of someone else's coding whims.

THEN they magically expect automated tools to do it for them? DERP! That's just going full Pakled.

You never go full Pakled.

Even the simplest projects now require endless pointless packages to do things that you shouldn't even be wasting a package to do, all to cover up for the fact that nobody seems to know how to do anything for themselves anymore. It then tacks on that to fix ANYTHING you have to worry about forking the existing package or upstream submitting a change -- NEITHER is all that desirable a situation since the former BREAKS that easy collaboration notion, and the latter more often than not is either too much of a pain in the ass to bother with, or throws you into direct conflict with its creator.

Which is why instead of classic interpreted language spaghetti code, we now have spaghetti dependencies tossed together by people who are usually too green around the gills to be coding unsupervised in the first place.

But of course by perpetuating the "nobody working on it REALLY knows what they are doing" it lets certain types of employers continue to treat their line programmers like toilet tissue. If the job can be done by a scrub fresh out of college, why would you ever keep an employee around long enough to risk having to give them a raise when colleges churn out a new class of naive young hopefuls every year?

Similar to the businessman's joke -- if women get paid less for the same job in fields where the result is equal, why would you ever hire a man? (pokes head into accounting, marketing, development, and graphics departments) ... Oh.

Search Hashnode