#dependency hell

[dragoni]

ME-OUCHHHHHHH!

npm dependency hell. I have a project that has 3,061 modules of which only 40 or so are either dependencies or devDependencies. All of this chews up 180MB!

With the new generation of JS libraries and frameworks, it’s the wild wild west. So choose your 3rd party libraries with the same due diligence as you chose React. 

Ember announced yesterday that Ember 2.4 will be the first LTS release of the core framework

In fact, React itself is farily well documented, with changelog and all, and with small articles detailing breaking changes. That’s not the case for most libraries out there. The real painful part of the process is caused by everything around React, including the build tools.

Welcome to the brave new world

meshko 38 minutes ago

I am not a JavaScript developer but was asked to help the JS team just the other week with an npm build issue. The npm modules built fine on OS X dev boxes, but CI server running Linux was failing because older version of gcc was installed. While troubleshooting this, I came to learn a bit about node.js and npm ecosystem and I surprised slightly more than I expected. Apparently, it is considered normal now to have build process download dozens of these npm modules. Many of them are build time dependencies. Things that are good old native binaries (e.g. for changing compression levels of graphics files) are downloaded by npm and built from source. Then when module runs, it tries to execute them by pulling in one of half a dozen possible modules for executing native binaries. There is no logging. All code is written in crazy continuation style, because the framework is inherently asynchronous -- nevermind that it only matters in a handful of hot IO cases requiring optimization -- all code is like that, undecipherable. There is no logging or error handling. A 3 months old project setup by smart consultants who do this kind of thing 24x7 already has a significant number of deprecated dependencies.

These days things seem to have changed. I’ve been more or less in constant touch with Javascript and its ecosystem for a solid 8 years now and yet things don’t seem to get easier, to the contrary. So I don’t know, maybe it’s just me getting more conservative / impatient / you name it or maybe, just maybe, it’s the ecosystem that gets harder to work with, especially in the recent 2-3 years.

I think that for someone who just gets started on the job an upgrade task of this kind of task might feel a lot more frustrating. Perhaps so frustrating that they might flip the table, throw everything away and rewrite it from scratch.

One thing seems increasingly clear to me: this way of building software is not sustainable. What can we do?

[evadnelt]

Kitchen Sinks suck

Taken from my Twitter stream earlier in the evening:

Admittedly, the most important lesson among those I learned from putting all work into one kitchen sink project: don’t.

It simply makes way for dependency hell, and reduces friction against coupling. More, the commit history gets messy over time.

Ideally, only the critical parts of business logic, and some parts of UX, is [sic] proprietary.

I would say it’s best to build your product in a profitable way, that your client apps are simply reference implementations.

Guess my next point of concentration will be on how not to use blocks… ;)

[ragnarokkrr-blog]

Trautman: Pressure? Let me just say that Rambo is the best combat vet I've ever seen. A pure fighting machine with only a desire - to win a war that someone else lost. And if winning means he has to die - he'll die. No fear, no regrets. And one more thing, what you choose to call LINUX OR JAVA DEPENDENCY HELL, he calls home.

Col. Samuel Trautman (Character) - Quotes

[realityfragments]

Spaghetti Source, Spaghetti Dependencies...

There’s one thing that consistently showed up in my work as a software engineer over the decades. Spaghetti. Spaghetti code is easier to write than maintain, and in doing software archaeology (yes, it’s a thing), I’ve encountered numerous reasons for it. Requirements creep is one of the largest reasons. In fact, the first real software archaeology I did was explained, proudly, as being a…

[intern-lessons-blog]

Intern Lesson #25

Corollary to #24: if things with kafka still don’t work, kafka_2.11 might be hiding in your maven dependency graph

[dragoni]

lol, welcome to frontend development

“2015: JavaScript tool X was useful 2016: Make X easier to install/setup/use for all new users. Minimize dependency & configuration hell.”, @addyosmani

pick your poison knowing in 3-5 years you’ll have to choose all over ;)

The Present

It’s really really complicated. First, there’s a variety of module formats out there in use:

CommonJS

AMD

UMD

ES6 Modules

Tools for bundling assets come in a variety of shapes and sizes:

Browserify

jspm

Webpack

Rollup

Brunch / Brocolli

Sprockets

Build your own with Gulp / Grunt

Then there’s transpilers that you may want to use:

Babel for ES6

CoffeeScript

Typescript

In addition, there are various libraries that allow dynamic loading of modules:

Require.js

System.js

These are shortened lists of popular tools currently in use—it’s a minefield for beginners and experts alike. The cost of transpiling also highlights that you can mix and match a lot of these tools and get different results.