AngularJS application starter comparison | Hacker News Reader

AngularJS application starter comparison

dancancro.com

43 pointsdcancro20 comments

A side-by-side comparison of things you can use to get started making an app with AngularJS

Open articleView on HN

Am I the only one around here who prefers starting from scratch in a blank vim session?

Well that depends. HTML + JS need a lot of boilerplate by definition, so generators are OK.

HTML + JS need a lot of boilerplate by definition

If you accept that as axiomatic, I think you've already lost.

Almost all of the boilerplate I see people assuming a new project needs is either not actually necessary at all or something widely used but needing specific customisation for each project, i.e., it's not really boilerplate in the sense that templates/generators/scaffolding tools reduce the overhead significantly.

I do like generators for one reason - setting up a Gruntfile with all the details you want can be tedious (in addition to all the dependencies in your package.json), not to mention setting up stuff like Bower.

That's a bunch of wasted time setting up boilerplate. Generators tend to not be perfect, since we as developers can get opinionated, but I'm fine with tweaking from the boilerplate to get the results I want, which takes less time than setting everything up from scratch.

Dude setting up an angular project can be a huge headache. We use a hand built generator just for our needs, but npm in so insanely unstable that we have to get in and end up doing a lot of configuring of the gulp / gruntfile and packages etc.

I don't recognize your problems at all. Do you mind elaborating on what headaches setting up an Angular project gives you?

I guess I'm complaining about npm more than Angular per se. Most of our issues stem from the myriad package dependencies "in the wild" of npm itself. It's like tilling a field in the wind. Often one has to `npm install` >3 times to install all of your modules. I guess that's what happens when you have ten billion cooks in the kitchen.

Is using npm worth it? Would it be simpler to download the dependencies yourself and put them into a vendor directory?

You know that's a good question.

I've spent about half of my work day today working out npm dependency conflicts... The Einstein quote about insanity comes to mind.

The web development industry, and particularly the front-end side, currently seems to be obsessed with (or maybe plagued by) tools that sort of do half the job you sometimes want but feel like you have to always use anyway because everyone else is or appears to be or at least says you should on their TwitBookBlogFeed.

I wanted to do exactly what you describe yesterday -- just download the latest stable version of a one-JS-file library to include on one page of a web app where its functionality is relevant. We used to do this by downloading example-1.0.8.min.js from the obvious Download link on www.example.com.

As it turns out, the project from yesterday lives in a GitHub repository with a dozen files scattered across a root and four subdirectories. I honestly have no idea how to build it; it's written in a compiled-to-JS language, the build instructions are a one-liner that refer to a build tool I've heard of but never used, and there are at least half a dozen other files in the project that seem to be there only for some sort of compatibility with various other tools I've heard of but never used/don't use on this project/don't have installed on this workstation.

I find myself reminded almost daily of this now-infamous XKCD: http://xkcd.com/927/

This is not progress. :-(

Here's our generator we build just to suit our needs: https://github.com/lynndylanhurley/generator-gulp-of-drano it's come in pretty handy as we have to roll out several apps at a time with (in general) the same dependencies.

Isn't a generator a code smell? - if you need one then your framework abstracting the right things.

I am the same. I don't want to delegate my stuff to a generator which adds a lot of bloat and where I have no control.

On the other hand, there are things like cookiecutter[1] that allow you to basically create generator 'templates' that are your own. This way you don't have to get upset about the generator making a choice that you didn't like.

[1] https://github.com/audreyr/cookiecutter

If you're like that, then you probably shouldn't be using Angular. That thing is a mess.

I think Closure Compiler integration is really important for Angular, since it has built-in support for the framework (it allows automatic injection based on parameter names). It also does really good minification and dead code elimination. Sadly, it's still pretty hard to get started with, I think https://github.com/zemirco/nghellostyle is the best example I've seen.

Isnt the compiler written in java? I think that's the heart of the problem, you aint gona get the javascript community behind that tool if it's not written in js,or at least something that cant be easily packaged with npm.Time to write a Java2Js transpiler,in javascript...

Seems odd to make a decision on framework by watching a couple of videos, but then compare dozens of application starters along hundreds of dimensions. I would think the choice of starter would be much less important.

Between the choice of framework, package manager, task runner, test framework, test runner, CI service, seed project, and a million plugins for each of the above, I have no fucking clue how anyone keeps up or writes a line of code anymore. And that's just the front end.

This is a pretty good run-down. I'm somewhat in the same boat, so it's nice to see this breakdown.

Thanks for your work, interesting information.

Reply on news.ycombinator.com