Hacker News Reader

Comment by jwells89 | Hacker News Reader

Love to see this, and hope that things like it become more practical as the HTML standard develops further. While there’s nothing wrong with JS in itself, the less that’s required the better from several angles — the big ones for me are less required dev work, less need for miles-long lists of dependencies, and better likelihood that the various components of the app are implemented consistently well since they’re the responsibility of web engine maintainers instead of random library devs.

For me personally web front end as a platform becomes progressively more interesting as HTML includes more robust widgets and functionality.

View on HN

Devil’s advocacy here (and I know this is overwrought and beaten to absolute death here and abroad daily) but is a large dependency tree really that bad?

Most modern backend development assumes a ton of dependency management, tech like Docker has proven for at least 10 years that it can be manageable in production at scale. While I get that browser compatibility can be a pain in a way that the backend doesn’t have to reckon with I don’t really see why dependency management for something like React should be a decision factor for front end.

That’s also not to insinuate that we should just do it (SPA + massive amounts of JS) because browsers can handle it or that there are zero downsides to JS dependency management, but rather that the positives and negatives of zero-JS solutions should be adjudicated on things like developer experience and speed of delivery.

I’m not an HTML purist, JS is fine, but I prefer to use it only where it’s necessary.

The main thing that’s bad about massive dependency trees in my mind is that it makes them difficult to keep a mental map of, which makes for pain when things go awry. Most of the work I do is on iOS apps which is a generally more “batteries included” environment, and there most dependencies only go a level or two deep, which is reasonable to reason about and makes it more practical to track down problems. iOS apps also just don’t need as many dependencies in the first place.

It’s not practical for web front end to require as few dependencies as e.g. iOS, but I think it’s a worthwhile endeavor to push that line as far as it can go so it’s more practical to develop a complex low-dependency web app.

Large dependency trees are usually not about using docker or not. That is rarely a dependency of the code itself. The complaint about large dependency trees is about hundreds or even thousands of dependencies of the code itself, where you could get away with maybe tens, if you write trivial code (left pad ...) yourself and avoided needlessly adding more stuff on top. Every time one adds a dependency, one should feel a little sting and make an uncomfortable face and remember, that this dependency might make things badly maintainable, difficult to upgrade, or vulnerable. Always ask oneself things like: "Did I read the code of that dependency and its dependencies? Do I really know what this code does?" and of course if one does now lock down that dependency to exactly one version, one would have to consider these things every time one upgrades dependencies.

Now for a throwaway web app maybe one does not need to care. But then one should also label it as such. A throwaway, nothing to be taken as a good example. Definitely not production ready code.

It is true that JS and the web + JS ecosystem is absolutely overloaded with “utility” dependencies like lodash or some weird fusion experiment in a way that Python or Java is not. I personally have implemented and removed a ton of dependencies in the latter two languages with little hassle - I’m aided by the fact that these languages support DI or hexagonal architecture and a good project layout can prevent something that I don’t need, care about, or understand from becoming ubiquitous and cumbersome as my codebase grows.

Reply on news.ycombinator.com