The present/future of AngularJS | Hacker News Reader

The present/future of AngularJS

docs.google.com

36 pointstilt28 comments

I really dislike the trend of tech talks turning into stand-up comedy routines where 75% of slides must be a funny image that barely relates to the point the speaker is making at the time.

I really enjoy that trend. Tech is a dry topic with typically uninspiring presenters.

I agree, I went to a conference the other weeks where the talks where extremely informative but after a day of presentations it becomes very hard to listen even if you're passionate about the topic.

I enjoy the more casual approach than the dry textbook approach, I don't have an academic background however and that may be the difference.

Crowds love that stuff though. When you're sitting there in person, you don't have the luxury of switching to a different tab for entertainment :)

I know you're joking, but there is a kernel of truth; crowds do like it. It's sad that people choosing to attend a talk about Angular.js don't find Angular.js interesting enough on it's own. They must have a rattle to amuse them.

I agree, that serves no purpose. It's just distracting. The "introductory joke" in a talk is sufficient to relax the audience.

What I'd really like to see in AngularJS is some sort of asynchronous module system a la AMD. Doesn't have to be AMD, but some way to not have to load a whole app in memory at once. I thought I saw a design document that mentioned they were considering this for AngularJS 2.0, does anyone know more about it?

I do know that you can use requirejs, does anyone have any experience to share using requirejs and angularjs?

We use angular with RequireJS, though we don't (yet) load any Angular modules lazily because it is not supported by Angular. There are workarounds (like https://github.com/marcoslin/angularAMD) which I have no experience with. We do load external libs (like MathJax, which is comparatively huge) lazily where possible.

Our AMD modules are actually TypeScript modules that generate the AMD wrapper. Works great, and makes for a very clean and modular codebase. In the end, we use r.js to concat and minify most of it (everything except the lazily loaded libs) down to a single file. Including Angular templates, using https://www.npmjs.org/package/gulp-angular-templatecache which can output the templates as initialization scripts inside and AMD wrapper as well.

But you're not using async (angular)module loading.Angular modules cannot be loaded async in.You might be able to inject services after the app is bootstrapped but it involves using global variables,which totally defeat the purpose of dependency injection.

Indeed, that's what my first sentence implies. Note that this doesn't prevent you from lazily loading other JS libs when using them inside Angular modules.

AngularJS is terrible choice for a front-end framework. It's just bizarre from top to bottom. Not everything needs two-way binding. Not all SPA's use nesting to compose their user interface! Why does ng-if create a new scope? Using attributes as control structures is plain dumb. Component re-use is difficult because of nesting as a central paradigm.

Javascript is a wonderfully expressive language. Unlike AngularJS, ReactJS let's you use this wonderful language to compose your application, not the foolishness of Angular's "modules", "factory", and "service". Even Dependency Injection is a foolish concept in a language like Javascript. Composition and wiring can be orchestrated through code, it doesn't need an intervening layer!

Javascript already has well-establish design patterns - it doesn't need AngularJS.

As I may soon be maintaining some angular code and am new to it, I'm interested in your criticisms. Would be nice if you could expand them a bit.

I hate being linked to slide shows. When I saw the docs.google.com I was expecting some sort of design document or something.

Right! The presentation showed some of those design documents in a picture in a slide. Are those documents available? That's exactly what I thought when I saw that slide, that I'd love to read those documents.

The Angular 2 design docs can be found here: https://drive.google.com/folderview?id=0B7Ovm8bUYiUDR29iSkEy...

Awesome, thanks!

how does react.js compare? https://www.google.co.uk/trends/explore#q=angular.js%2C%20re...

TL;DR: Ember and Angular are more full-featured than React.js. And Angular gives you the most bang per byte downloaded.

angularjs is mvc (Model View Controller)

react is only the V(iew), so you can blend AngularJS with ReactJS.

The most popular post (about Angular vs React) is on http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-Angu... , but it's kinda subjective i suppose as he works on the React team.

(Note: I use AngularJS, but haven't used ReactJS. So if i'm wrong, please correct me).

Here is a nice comparison though http://www.reddit.com/r/javascript/comments/1v4glc/react_vs_...

That is correct, but I will say that React can enable a different application structure in a way that other view layers (i.e. more "normal" template engines) do not. React can be treated as a function (pass in input, out comes a UI based solely on that input) and I've found that this lets me simplify other aspects of my code.

Thanks for your comments both of you I am trying to figure out which I should learn being an ASP.Net developer

PS - FYI http://www.google.com/trends/explore#q=react.js%2C%20ember.j...

(React dev here)

I myself have been guilty of spreading this "React is just the view" mentality as an easy argument to convince people to try it. However, in reality, you can't really compare framework X's view with React view just because they're both called "view". React's whole architecture and paradigm makes it so that you don't need controllers or, very often, not even models.

In this regard, "bang per byte downloaded" is very misleading (it already kinda is?).

The Reddit link seems much less objective than Pete Hunt's overview (e.g. the last point about React not providing code modularity is flat out wrong)

I wrote a frontend framework comparison essay here ( http://lhorie.github.io/mithril/comparison.html ). It's focused heavily on Mithril.js, but might be useful for someone evaluating frameworks.

FWIW, I've used Angular extensively for the past few years and some of the reasons I wrote Mithril (which has a virtual-dom based engine like React) were because 1) Angular performance issues are really hard to fix, 2) I feel some of the design decisions in Angular are fundamentally flawed.

Thank you for writing Mithril; it's a breath of fresh air coming from the complexity of Angular. Not to mention the small size (5kb!) - that'll be especially useful when we build our JavaScript embed widget.

Think of react.js as a Directive alternative - it's not as full-featured as Angular but you could replace Angular Directives with it.

Angular is a monolithic framework, with all of the pros/cons that that brings.

Reactjs is simply the view layer, and plays nicely with other libraries.

I hope AngularJS implements a virtual DOM, but I'm keen to transition to reactjs anyways, as I prefer assembling a program from many libraries instead of a monolithic framework

TL;DR;

The presentation is about the community (it's large) and about AngularJS 2.0.

AngularJS will become more usable with mobile dev.(with Material Design and famo.us). It will also expand to AngularDart

The poem is fun though when you like Angular: The poem https://twitter.com/NicoJuicy/status/525295632882614272

In singing form:

https://www.youtube.com/watch?v=cSCpGAPWe_8#t=166

Really looking forward to the integration of Material design in a mobile browser with Angular.

Reply on news.ycombinator.com