Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to justify the bloat of modern JavaScript frameworks?
5 points by guessmyname on Sept 15, 2016 | hide | past | favorite | 2 comments
I've been doing back-end development for several years, and recently decided to update my skillset learning one of the popular JavaScript frameworks. But my paranoia for the security holes and/or bloat of the code kicks in every time I see a "npm install [insert-js-framework-here]".

The "Angular 2.x — Quick Start" tutorial [1] walks you through the process to setup your project and before you write your first component you already have ~83MB of files via NPM (or ~112MB if you choose the TypeScript tutorial). Same with React.JS which requires a bunch of dependencies mostly related to the Babel project. Why is this? Wasn't Angular just a single minified file that you could include in your website and then start writing your custom code? Why are there 264 directories in the "node_modules" folder?

Sure disk space is cheap nowadays, the problem is that I feel my project is bloated from the beginning. How can I justify the inclusion of 10,170 files (JavaScript or not) from the normal installation of the latest version of Angular.JS? The "releases" page on GitHub points to an archive with 1,321 files [2]. Is the minified-JS-file era dead? Is NPM the future that front-end developers want?

I would prefer to stay in the back-end development side and leave this JavaScript madness to the masochist front-end developers that seem to enjoy over-complicated solutions, but many companies nowadays expect you to know at least one JavaScript framework. Maybe I should forget about React, Angular, etc and learn something like Vue.JS which seems simpler, and if it is not — because I haven't used it in production yet — it at least has a single-file installation [3].

[1] https://angular.io/docs/js/latest/quickstart.html

[2] https://github.com/angular/angular/releases

[3] https://vuejs.org/js/vue.min.js




VueJS also has a stack of devDependencies, look at the package.json file.

* Why are there dependencies on the Babel project? Because most people aren't that excited about writing in ES5 any more, for better or worse.

* Why are there 264 directories in node_modules? Because there's functionality there somebody didn't want to re-write.

* Single minified deploy files are the norm. Along with culling artifacts that aren't actually being used.

* I'd rather use NPM than figure out all the dependencies myself, same reason I use Maven for Java projects.

* Nobody "enjoys over-complicated solutions". Just like nobody "enjoys rewriting stuff that smarter people already wrote".

* Your back-end work is dependency-free?! I haven't written a back-end system in years that hasn't relied on the work of others.

The bottom line is that if you're not writing anything complicated, back- or front-end, then you might have the time and resources to write (and test and maintain) simplistic solutions. I haven't had that luxury for years. Front-end frameworks are just like back-end frameworks: they solve certain kinds of problems that are repeated across projects.


As a back-end guy, whatever they use that lets me use a clean, well-defined API is fine in my book. They can bloat it up as much as they like as long as I don't have to see a single line of HTML, CSS or JavaScript. JSON is bad enough.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: