Hacker News new | comments | show | ask | jobs | submit login

AngularJS has a J2EE mindset. Where libraries grow to become as hard to learn as programming languages themselves. It does not make semantic sense to me anymore.

Here is an example from the site:

  <div>
      Length (float):
      <input type="text" ng-model="length" name="length" smart-float />
      {{length}}<br />
      <span ng-show="form.length.$error.float">
        This is not a valid float number!</span>
    </div>
How semantic is ng-show="form.length.$error.float? smart-float sounds like C++. If programming languages worked like this, we wouldn't have built many apps. The problem is that some frameworks assume that everything should be done with using configuration. What ends up happening is that the configuration (and conventions) becomes its own language. This is a waste of time in the long term; library conventions are not a portable skill set.

Some things are just better off with plain JS and simple HTML. FB/Instagram's React is a much better approach to building HTML UIs; you get readable JS and HTML instead of configuration mess.




This is a critique of the example, more than the framework itself. The "smart-float" directive is not a native angular directive, but rather a directive made for the example.

As for the "form.length.$error.float", it probably could be a bit more concise, but is it really that bad? What would be a "more semantic" way?

The main strength of angular, is that you are able to point your DOM elements to environment variables in your JavaScript code -- eliminating the need for traversing the DOM to find a mount node. If you are opposed to this functionality and insisting on traversing the DOM from the JS side, I'd love to hear why.

You can find small things you dislike in any framework, but rarely are they valid criticisms of the general concept. Often, these details are there for a reason, and just as often, they are flaws waiting to be fixed by an open source developer.


I'll keep this high level; that's where I have issues with Angular.

Angular wants you to learn its vocabulary, and encourages users to expand it further. Like you point out, smart-float is a directive specific to the example. To me, it is a foreign object I don't recognize in html. In fact, directives, scopes?

The big one. Dependency Injection, factories, modules. In JS, this is a solution looking for a problem. There are simpler alternatives to DI. They have issues, but only in theory.

Clarity matters a lot. ng-show="form.length.$error.float". Is there a more simpler way of doing it? There should be; I can't even tell what that means.

I think there are distinctly two camps. I'm in the one which wants frameworks to make me productive with the languages, specs and standards I already know. React (+ router) does this. Backbone does this too, depending on what you're building.

(Edit: replaced semantic with clarity)


I'll agree it's not pretty to view source and see an inordinate amount of fluff in what was once your beautifully handcrafted semantic HTML. Much of this can be alleviated with templating (ng-view).

Have you taken the time to play around with angular before airing your grievances? My hunch is yes and that you may just be simplifying things for others who haven't used it yet.

For those of you who haven't had the pleasure of working with angular: Once you've familiarized yourself with the verbiage, most of jeswin's concerns here come second nature just by glancing in one's source code. Let's take the example:

    form.length.$error.float
The name form, albeit horribly chosen in this case, represents the parent form's identifier in angular (the form's name attribute). It would've made more sense to use <form name="formLengthValidationDemo"> or something more insightful so you could more easily see the name matching from HTML to JS.

$error is simply the representation of any form validation errors that may have occurred. It's standard in angular, and there's plenty of documentation. Just google for "angularjs form validation" and you'll find a million resources at your disposal.

form.length.$error.float is checking if an error exists for the validation rule float. Given the limited amount of code in the sample, we'd have to arbitrarily assume that the "smart-float" directive is implicitly setting a custom validation rule via:

    ngModel.$setValidity('float')
I'll have to agree to disagree regarding pattern usage and dependency injection. They do have a place, and it tends to be in larger applications which become a burden to maintain as your application grows. To be quite honest, I believe angular brought a simplicity to DI that has yet to be seen in many other frameworks. It entirely lowered the barrier to entry for writing testable code and heavily promoted unit testing at the same time.


Agree 100% with your post - some of these complaints are misrepresenting the aspects that are not as desired in Angular. I've used Angular quite extensively for the past 1 1/2 years, and most of the complaints I have with it are more nuanced, such as having to dynamically inject some custom directives via $compile in a service method provided to a controller due to the complexity of being able to alter the attributes present dynamically in a template.

The declarative style that Angular coaxes you into makes things incredibly easy to understand - you can write code like

    <header>
      <navbar></navbar>
    </header>
    <main>
      <sidebar></sidebar>
      <content></content>
    </main>
    <footer>
      <company-info></company-info>
      <credits></credits>
    </footer>
And instantly understand what the purpose of these elements are - they're easy to read, they're descriptive, and they're clearly custom elements not part of the normal HTML5 spec, so you can instantly recognize that they must be directives.

I can also do simple directives like <loading-spinner></loading-spinner> and create a nice template for CSS to hook into by using the loading-spinner element tag without having to distract from the rest of my DOM with a nesting of 8 divs that can easily be tucked away in a reusable template.


I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something?

The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That might muck things up a bit. At least visually, as I would imagine the directives would likely continue working the same as before. It's just that the "they must be directives" logic would fail in that instance.


Good point. I, too, enjoyed using custom tags like <zoomer> or such, but I'm going to think twice in future.

Interestingly, out of the box Angular provides directives as a, input, or form—meaning that when you write <input> you are, in fact, invoking a directive that provides extra features along with native tag's functionality. While using Angular, you may as well consider every HTML element a directive.

Nevertheless, Angular uses ng- prefix with their built-in directives that don't replicate some existing tag's functionality closely.


You can make your custom directives HTML5 compliant, see [1], you can use the HTML5 data- prefix. For instance:

  <sidebar></sidebar>
can instead be coded as:

  <span data-sidebar></span>
or something similar.

[1] -- http://docs.angularjs.org/guide/directive


Custom elements are part of the HTML5 spec too:

http://w3c.github.io/webcomponents/spec/custom/

The only requirement is that they have a dash in the name. So while <sidebar> is not a valid HTML5 element, <a-sidebar> would be.


That's my usual way, or the class-based way for older IE.


Maybe prepend them with "an-" or something?

Yes, this is actually the recommended practice from the documentation. Built-in Angular directives are typically prefixed with `ng-`, and they suggest that other projects/developers use their own prefixes to avoid conflict.


That seems like a poor reimplementation of XML namespaces.

Why not use XHTML at that point? If XHTML ever had a clear mission statement in life it was that.

I mean I thought XHTML was a curse a few years ago when it was The Thing Every Good Designer Uses™ since it couldn't be rendered as XML in the most popular browser. But hopefully that's not as much an issue anymore. Or maybe it is. I haven't kept up with IE.


>That seems like a poor reimplementation of XML namespaces

Or you know, an adoption of only the needed part, instead of all the BS junk that comes with XML namespaces.

>Why not use XHTML at that point?

Because of all the other junk that comes with it. And because it comes from W3C.


XHTML is on the way out, I'm afraid. Angular is designed for HTML5.


Actually, it's a little more complicated than this even. Not only might HTML add more tags, but a non-standard tag might be a W3C custom element: http://www.w3.org/TR/custom-elements/

When users gain the ability to define their own tags, you might not know which ones are driven by directives, the custom element, or both even.


The philosopher David Lewis had a lot of critics, and they would often cite the fact that they couldn't possibly see how modal realism could be true, to which Lewis would reply, "I don't know how to refute an incredulous stare."

Arguments from personal incredulity don't engage substantively with what they ostensibly claim to refute because they import a variable- the argument-maker's conception of what seems plausible- that really should do no work in a logical analysis.

The arguments adumbrated in the parent comment seem to have similar failure modes, adorned as they are with premises such as "to me, [the directive] is a foreign object I don't recognize," and "I can't even tell what that means." Someone who has never programmed before could look at some vanilla javascript and plead perplexity, but obviously this isn't an indictment of javascript itself. To really make the point, the parent comment would have to show that the learning curve is disproportionately arduous for the payoff at the summit, but reiterations of personal unfamiliarity were offered instead.

Jeswin gives no evidence of having made a reasonable attempt to understand Angular ("directives, scopes?"), but more crucially, displays little understanding of the benefits of Angular. DI is criticised as "a solution looking for a problem" in the context of javascript, as if dependency injection were a bandaid for not being a dynamic language. DI enables testability, and not even mentioning this advantage, let alone not providing a cogent argument for why the learning curve of DI doesn't justify the gains in testability, is to refuse to participate in the discussion entirely. Directives are similarly dismissed as "foreign objects," which they might be to some, but they're hugely powerful foreign objects that allow arbitrary behaviour to be written declaratively. Not knowing the benefits of Angular obviously contributes greatly to a reluctance to learn it, and perhaps a subsequent rationalisation of this reluctance as being provoked by something intrinsic to the framework.

Fittingly, after expressing bewilderment regarding Angular scoping, Jeswin goes on to divide the world into two camps, declaring membership in "the one which makes me productive with the languages, specs, and standards I already know", which is about the closest thing to a natural language scoping bug I've come across.


> DI enables testability, ..... the learning curve of DI doesn't justify the gains in testability

Dependency Injection is a redundant, useless pattern in dynamic languages; especially when it comes to testability.

In test.js:

  //paymentService may be an instance or a class
  services.paymentService = mockPaymentService;  
  ....
  //use paymentService in your tests here.
The above over-simplified example satisfies most test cases. You can convince me with some use-cases.

(Edit: You weren't misrepresenting what I said. Removed that claim. I misread, apology.)


With DI you can ensure you're not accessing anything that's globally defined. While you can mock out global objects and methods on global objects, it becomes far less clear what the ramifications of doing so becomes when your app becomes large and complicated. With DI, you have all the dependencies clearly defined for the function you're concerned about.

Beyond testing, DI makes it much easier to swap in different implementations of a dependency than simply throwing things into the global scope lets you do. Suppose I want to switch my model from one that communicates with Parse to one that communicates with Firebase. Supposing I adhere to the same interface, I should be able to simply drop it in place without affecting other functions or objects that still rely on the Parse version of the model.


Your first point cannot be debated, since we are speculating. In practice, I'vent seen a problem. It works, it's clean, and it is the right amount of engineering needed to solve the problem.

Parse and Firebase example:

  //someservice.js
  ...
  //works as long as both retain the same interface.
  provider = new FirebaseProvider; //new ParseProvider()

  //add: just using an if condition, the old fashioned way.
  getProvider: function() {
    if (config.provider === 'parse')
      return ParseProvider()
    else
      return FirebaseProvider()
  
Why is writing configuration cleaner than doing the above? That thought process is carried over from projects with lengthy build time.


Whether or not Angular's implementation of its provider is cleaner is irrelevant to your original point that DI is a "problem looking for a solution" in dynamic languages.


My interpertation of the AngularJS DI implementation is that it exists primarily to make it easy to swap items out for testing purposes. I believe it solves that problem very well.

What alternatives do you recommend to DI?


Nothing, for swapping things out. :)

In my test initialization, I'd probably just replace the value of "ns.someService" worldwide with a mock.


> just replace the value of "ns.someService" worldwide with a mock.

Having a window-wide namespace might make sense in the test, but it is pretty risky/limiting if you are writing a component that should be reused in contexts you don't fully control. There are other ways around that besides DI, but they will probably have similar trade-offs in safety EOU, etc.


Totally agree and also recommend to look at React. While Angular is just way too much of everything React is pretty much thought-out:

Here a quick comparison of both: http://versus.com/en/angularjs-vs-react

Here a pretty good video of React's founder pointing on some weakness of Angular: http://www.youtube.com/watch?v=x7cQ3mrcKaY


This is true. AngularJS is much better than what we had before, it is kind of large and monolithic.

The cycle probably goes thusly:

Large monolithic framework comes and shows everyone a new way of doing things (Angular/Django).

People think it is too large and monolithic, so make microframeworks (Flask/Whatever comes after Angular).

The next step will be a kind of happy medium.


Except that Backbone.js, a micro-framework if there ever was one, exploded in popularity long before most people had even heard of AngularJS.


Backbone was the start of the cycle. It came around at a time when front-end apps were largely jQuery soup and put polish on best practices that good JS developers were already doing. Then a lot of other frameworks were developed which largely started from the same code-first premise that Backbone had/has, and Angular "won" by introducing a new paradigm built on declarative binding.

I predict that the next winner will leverage web components and do the one thing that makes that paradigm better.


Backbone doesn't do data binding; it's a completely different thing.

(That's why things like rivet and epoxy exist; because backbone doesn't do it right)


Correction: Backbone doesn't try to be the kitchen sink like Angular. Its source code is about 500 lines, and its docs say as much:

"Two way data-binding" is avoided. While it certainly makes for a nifty demo, and works for the most basic CRUD, it doesn't tend to be terribly useful in your real-world app. Sometimes you want to update on every keypress, sometimes on blur, sometimes when the panel is closed, and sometimes when the "save" button is clicked. In almost all cases, simply serializing the form to JSON is faster and easier. All that aside, if your heart is set, go for it.


This. I would add angular is good for teams requiring extensive structure. The cost is control. If you're building a corporate webapp, angular is great to keep everybody neat. If you're doing something unprecedented such as 3D rendering or a new UI element, angular will hinder more than backbone.


I never understood how JQuery and JS were just dumped the past 3-4 years in favor of all thse complex frameworks like AngularJS, Ember, etc... is there something these frameworks can do that JQuery can't? Can they make fancy single page apps and JQuery can't? I need to be enlightened.

Or is it simply ppl need to exercise their mental creativity?


Among other things that Angular, Ember & others bring, what you should understand here is that JQuery does not help you to structure your code. Those frameworks offer the type of structure that makes it easier to reason about how an app should be built, and it helps a lot when you're working in a team.

JQuery and JS were certainly not dumped, it is just that people writing single page apps moved on and are now using tools that help them.


"I never understood how JQuery and JS were just dumped the past 3-4 years in favor of all thse complex frameworks like AngularJS, Ember, etc..."

Well, you can't have Angular without JS so we'll focus on the point of jQuery here.

jQuery does a few things really well – so well that Angular itself uses jQuery (or jqLite by default). angular.element(selector) returns a jQuery object.

Angular also does a few things well. Code reusability and testability are much easier to achieve with Angular, in my opinion. Features like data-binding also help to reduce boilerplate code.


> Well, you can't have Angular without JS

Well you certainly can use it without writing any JS:

https://github.com/angular/angular.dart

However, you're going to compile it to JS when you're done.


Ok, cool. if Angular returns a jQuery object then its proof that it uses jQuery quite extensively. So does Ember.


There was a similar discussion last week. What I said then was that a lot of the things you would use jQuery for have a different solution in Angular: https://news.ycombinator.com/item?id=7396016.


jQlite is a pretty small subset of jQuery. Many things are left out to keep it lean. For example $(el).offset()/height()/width() etc. Mostly only the DOM methods are left as they do still need a bit of normalization across browsers.


Personally, the two big draws to me of Angular were "free" (as in, I don't have to write much code) DOM<->data binding, and the explicit goal of testability.

As a learning exercise, I wrote a page using just jquery, rewrote it in backbone, and then rewrote it in angular. Backbone helped me separate concerns; Angular helped me do that while writing _way_ less code, since I didn't have to manage keeping the DOM and the JS model in sync.


I had the same experience as well.

I redid a relatively trivial CRUD interface from backbone to Angular. The amount of code that I didn't need in Angular was ridiculous. Most of the code in backbone was moving stuff from the DOM into JS. Like var x = $('#elem').val(); kind of things over and over just did not need to be there in Angular.

I think that these kinds of interfaces hit a really good sweet spot with Angular and other databinding frameworks.


Agreed - data-binding and "magic" automatic updates to the view when the model changes are key to what make Angular attractive. The focus on testing is nice too, though.


Yes, there are a tons of things that jQuery cant do out of the box, like handle state in your application or keeping your client and server data reliably in sync, list goes on. Also, lots of frameworks haven't ditched jQuery, for instance, Ember.$ is a reference to Embers copy of jQuery.


>* is there something these frameworks can do that JQuery can't? Can they make fancy single page apps and JQuery can't? I need to be enlightened.*

jQuery has nothing to do with whether the app is single page or not.

Those frameworks make writing single page apps very easy.


It is strange to see Angular labeled "large" and "monolithic" here, when it was blasted for being too small and simple by one of the Ember guys (http://eviltrout.com/2013/06/15/ember-vs-angular.html).

I have suffered trough JEE which is/was really humungous, and Angular is really tiny in comparison.


imo AngularJS can be pretty micro and scales nicely. Its one of its major strengths, as you can use it to just build a tiny widget inside an existing page or all in and build a huge application.


Micro in the code you write, not the code that's loaded, so it doesn't seem practical to me.


It's worth noting that one of the goals listed for 2.0 in this post is increased modularity, which they imply will let you only load the pieces you're actually using.


What's after Flask? I don't see any Python framework after Flask.


such as vuejs?


React solves all the problems in the world with their nestable but still autonomous components approach. It dispenses controllers -- and automatically give control to the component which deserves it --, it dispenses templates, and automatically gives the power to make the entire app in modular small pieces of HTML, it dispenses models, because models are already embedded in the components in which data is rendered.

React is the Holy Grail of JS frameworks.


When I investigated React in detail, I found that there is a lot to like about it, but it's certainly no "holy grail." Specific downsides: you have to go back to manually writing event handlers (instead of getting automatic two-way data binding) and the virtual DOM is a leaky abstraction.

Here's my article where I analyze this in much more detail: http://blog.reverberate.org/2014/02/react-demystified.html

Also React does not "solve all the problems in the world" -- it says nothing about routing, validation, testability, and many of the other problems that Angular has solutions for.


Until tomorrow when someone else on HN tells me "______ is the Holy Grail of JS frameworks."


I'm curious what happens when you want to share models across components. In angular.js you would use services to do this, but what's the analog in React?


React encourages you to use a parent component that controls the state and passes it down to it's children via props.

Passing data to separate components without a shared parent is outside of what React is trying to accomplish but I've handled it before by passing a Backbone model to the separate components as props.


If you're passing it to child components you pass it through attributes. If you're passing up to parents, however, you have to create a function on the parent that will get called to accept the child's new data. This can get really messy if you have deeply nested components and need to get data from one branch to another branch.


I have been successful by instantiating separate services to perform REST operations and a global event emitter to establish communication between all the services and all the components that relate to these services in any way.


I cringe when I hear the words "global" and "event" together in the same sentence. Projects I've worked on in the past that relied heavily on global events often became a maintainability nightmare.


Why? Please share your experiences. I don't understand what's the utility of event emitters if not for serving as glue to all the separate components of an app. Am I wrong?


You're not wrong. It's definitely one way to solve it. I just find it harder to jump into a project with heavy reliance on global events and be able to quickly understand what's going on. It gets even harder if you have events firing other events.


> I just find it harder to jump into a project with heavy reliance on global events

Harder than what?


Harder than the way that it is done in Angular, via services.


This is extremely picky. "Smart-float" is the name of a custom directive that is used as an example. The term "smart float" can be used as a React component name just as easily. In that case, your React component would "sound like C++".

Also, the "we wouldn't have built many apps" part is a stretch. It's actually the opposite, AngularJS is extremely popular and the most successful current JS framework.


I don't see the problem. `<span ng-show="form.length.$error.float">` makes total sense to me. You show the content of that span when form.length.$error.float is truthy. Probably when it exists.

And yes, AngularJS absolutely defines its own language. The directives create an enhanced HTML (that you can enhance even further), and it has its own expression language where you can ask the value of `form.length.$error.float` without fearing null pointers.

This is basically what Angular is about, and why it works as nicely and cleanly as it does. And it's true; learning a new framework is absolutely comparable to learning a new language. Rails is not simply standard Ruby; it defines loads of new stuff that automatically handles things for you below the surface. Spring completely changes the way you work with Java. Grails has its own DSLs for various tasks.

Every framework has a learning curve. And a framework that doesn't change how you think is as useless to learn as a language that doesn't change how you think. But if you don't like learning, you can always simply stick to what you're familiar with.


I only looked superficially at React, so maybe I got something wrong, but the HTML/XML intermingled with Javascript seems extremely off-putting to me, akin to ASP/JSP/PHP.


'JSX' is also what made me avoid React at first. But once I started using it, it made perfect sense. The 'JSX' is just compiled to Javascript anyway, it's just more convenient for deep nesting of html elements within a component.

In more recent talks the React devs have avoided using JSX in examples and instead use the compiled form as JSX goes far enough from what people expect that it turns people away before they've given it a chance.

The most important idea to take from React is that UI components are much simpler when they are state machines.


The thing that sold me on React was this statement: "Most people make the mistake that the DOM is a place you put things."

The DOM is what the user sees. That's all. With React, you have a virtual DOM that can hold everything, not just what the user sees. It's a pure data structure, and can be manipulated as such.

Because that DOM is a pure data structure, React can figure out for you what parts have changed, and re-render those bits as needed.


I agree with you that React's virtual DOM is a real breakthrough. However, that doesn't make all of React worthwhile. Other frameworks can (and should) integrate a virtual DOM.


>Most people make the mistake that the DOM is a place you put things.

I guess this is why Angular keeps the model separate from the DOM.

That said, the virtual DOM strikes me as a really good idea I'd like to see in Angular.


It's just the first impression. React view code is not HTML in pure sense—it's a DSL for describing virtual DOM tree (that happens to look a lot like HTML for obvious reasons).

You won't regret taking a couple of hours to try to build something simple with it.


But then again, is the comparison between Angular and React even a valid one? After all, Angular is more or less MVC with a lot of functionality for resource routing, component building whereas React seems like a view templating library. So if I am not wrong, we are comparing a framework with a targeted library.

The weakness with Angular is not the view imo, but the $apply-cycle which can bog down even a modern browser with moderately sized data.


React basically eliminates the need for something like the apply cycle, because you just re-render from the top whenever something changes. React is the view layer, but its approach is different enough that you may restructure (and simplify) the rest of your app as a result.


That puts me off too, it's too PHP, as you said, but I love React because I use it with Coffeescript, which eliminates the need for a JSX compilator: http://blog.vjeux.com/2013/javascript/react-coffeescript.htm...

(You can do the same thing with pure JS, there are some forms of simplifying the React.DOM.div() calls, but coffeescript makes it beautiful.)


You know, I disagreed at first, but then I looked at React's semantics and couldn't agree more afterwards.


> How semantic is ng-show="form.length.$error.float?

I agree with your conclusion, but I think you're misusing semantics. This isn't semantic, but neither would anything else be. As soon as we get to using logic, we don't have semantics.

That line is unclear and not easy to understand. That is why I object to it.


Thanks; I will read up on the proper definition. I had been using it to imply 'meaning' (more or less), from Semantics which wiki says is the 'study of meaning'.

'unclear' is a better choice. And less pretentious too, than 'semantic'.


>How semantic is ng-show="form.length.$error.float?

I could not care less. I find that talk about web programming has been polluted by non-terms like "semantic" that doesn't mean anything specific (in the context).

Especially the whole hoopla with regard to "semantic HTML", with designers (who don't know much if anything about programming, and just heard this "semantic" term from a few industry fad gurus) using it to insist developers should treat HTML as a format for reuse (as if the reason we write HTML is to enable better screen scrapping).

Endless discussions about whether it's ok to a DIV if it's purely for display purposes of not, as if HTML/CSS dont already make a clusterfuck of separating markup from presentation.

Fuck "semantic HTML" -- it's a presentation format, that also happens to have a not-that-functional styling component. If you wan't reuse and semantics, get those from the data level (the db, the REST endpoint, etc), not from code meant for browsers.


That's not necessarily semantic, but that's declarative and it's what I like with Angular. No need to think cinematic such as "when this change, update that", but just declare links.


Angular is starting to remind me more and more of JSF + CDI which immediately triggers a negative visceral reaction for me. But, if I step back and think for a moment, most of what I despised about working with JSF was related to the amount of state it needs to maintain between the browser and server. If that state is completely contained on the client and the client maintains a stateless connection to the server, it may actually work out well.


smart-float is an HTML attribute. It does not "sound" like C++. Maybe you should learn HTML5 first?

Why this is the top comment is beyond me. This is whining.


Except that it appears to be an angular directive...?

http://docs.angularjs.org/guide/forms


What do you think an Angular directive is?

It is a DOM marker (HTML attribute, element, class or comment) with behavior (JavaScript) tied to it.

Angular lets you create your own HTML attributes. That's what a directive is.


Please don't insult JEE by comparing it with Angular.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: