top | item 10817541

Show HN: Angular Starter Kit – Typescript, WebPack, Karma

50 points| nerazzuri | 10 years ago |github.com | reply

16 comments

order
[+] programminggeek|10 years ago|reply
That's a lot of pieces just to build web apps with JS.

It wasn't that long that we didn't need any of this stuff and I'm not sure that anything people are building with Angular/Ember/etc. is sufficiently more advanced than what came before it.

[+] ralmidani|10 years ago|reply
Feature-wise, you're partially right.

But using a modern framework (I prefer Ember) allows a team--large or small--to build advanced apps without losing their sanity. UI-based routing, declarative data-binding, and a REST abstraction layer save you a lot of hair pulling.

[+] grumblestumble|10 years ago|reply
Actually, when 'we didn't need any of this stuff', most of the heavy lifting was with server-side frameworks(Struts, Razor, Rails, etc). The rise of web applications, and in particular single page applications, which are expected to behave very much like desktop apps, initially led to insanely complicated jQuery monstrosities that quickly became unmaintainable. This created the need for front-end frameworks, which led to a lot of churn as people tried to figure out the right approach. Something like Dojo is not all that different from Angular/Ember in concept, it's just an order of magnitude more difficult to work with, or scale an application with.

There's nothing here that seems superfluous when creating a web application. If you want to take advantage of advances to the Javascript language, you're going to have to go either with Babel/Traceur or some other kind of ES6 transpiler, or Typescript, which while ostensibly is it's own language, seems more and more headed to becoming defacto ES7.

If you work with a team of developers and want a modular structure for developing components as opposed to 10,000 line js files, you're going to need some kind of module system / bundler. This is hardly new, it's baked into .Net web projects (forget the name), and stuff like require.js has been around for ages. Webpack is just the latest iteration of that concept.

If you're building an app of any complexity, you're probably going to want to do some unit testing. For that, you'll need a test runner. Karma's a decent choice.

[+] antoaravinth|10 years ago|reply
Your absolutely right. When I started learning about Angular / React these starter kits are scary! I used to checkout and run `npm install`, it does install say at least 50MB of modules, which I don't even have clue on them.

Then myself slowly started with damn simple project only with Angular dep and then slowly move upwards as required. That was indeed gave a good learning.

The above statement does hold true for starter kits, not only Angular.

[+] apalmer|10 years ago|reply
really these tools tend to be most beneficial for large teams... or medium sized and small sized teams where folks come and go... I come from a server side static language background so it all 'makes sense' to me, these are the kinds of tools we expect to be 'baked in'... i find associates who have been doing a lot of front side development for a long time tend to be more negative of on the amount of tooling that are considered 'bare minimum' to get a project going at this point in time

I am amazed by the churn rate though... require, browserify, systemjs, to webpack in like 4 years... grunt to gulp... backbone->angular->react in like 5 years... its a very fast paced world... doesnt bother me, but I have applications i support that have been in existence almost 20 years...

[+] pheroden|10 years ago|reply
It's easier to write, test, debug, and maintain. I have apps now that a few dozen files, all <= 100loc replacing systems where the number of files is many more and the file sizes were 2000loc per file.
[+] dimgl|10 years ago|reply
I've had a lot of success using System.js and JSPM to transpile and bundle my Javascript code. I've dropped Karma altogether and I am just using the Mocha CLI for testing. Testing Angular 1.x was such a nightmare that I kind of just gave up. I'm having a lot more success with other frameworks that are a bit smaller and do less.
[+] EvanPlaice|10 years ago|reply
I was going to suggest the same.

JSPM has a lot of really useful characteristics.

It includes System.js which is a polyfill for the future ES6-Module-Loader spec. It also supports importing AMD/CommonJS modules.

JSPM installs modules from the CLI the same way NPM does, except it's specifically geared for the client-side. Every module that gets downloaded (incl dependencies) is automatically mapped in a config.js file.

JSPM has its own registry but, unlike NPM, the registry is not a requirement. It's trivial to install modules directly from GitHub and NPM.

The module/dependency is flat (NPM is changing to this in V3) so there isn't any duplication of dependencies. It also supports multiple versions of a dependency if necessary so there's no 'dll hell' esque issues.

JSPM comes built-in with transpiler support for Babel, Traceur, and Typescript. Using them is as simple selecting one of the three during the 'jspm init' script.

It can also be used to build bundles and self-executing bundles (incl minify).

The best part is, it aims to directly support the future ES standards while also providing a bridge to use older packaging formats.

Browserify and Webpack are extremely popular at the moment but both will inevitably be replaced when the new module standards solidify.

[+] 1971genocide|10 years ago|reply
I have been seeing a lot of talk about JSPM.

How is it different from NPM ? since I just use it to do everything.