Hacker News new | ask | show | jobs
by davidholmesnyc 4252 days ago
I feel that Angular changes too much in HTML to be considered useful for long term projects.The new syntax is also disturbing. My ideal MVC for front end utilizes regular javascript and html tags. At most just add data-ang-click="" something like that instead of "(click)" the latter isn't even valid HTML. Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these drastic changes in HTML with non valid tags and attributes people would not be happy with that project.

I know Angular has a lot of community support and I have built some side projects in Angular but I feel now too bloated with having their own standards instead of following normal HTML standards. That's just my 2 cents on it and i'm sure there are a ton of reason to use Angular but I just don't know if I can continue supporting a project that makes so many drastic changes to a standard. I don't want to make it sound like I have Angular hate here but i'm a big vanilla fan and it seems in order to build anything useful in Angular you have to throw out vanilla and use Angular's way even if vanilla is better. On most projects handlebars and correct proper design patterns in code is enough to keep HTML out of javascript and keep basic organization.

9 comments

> Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these drastic changes in HTML with non valid tags and attributes people would not be happy with that project.

This is a pretty interesting statement and I want to give it more thought. I've used Angular on plenty of projects and admittedly, It's felt a bit dirty to go back to spaghetti DOM that we worked for years to get rid of. All the books were saying to separate logic from our views. Now we're calling it declarative and it's acceptable again. I've been yelled at by other developers as if I should just forget the past few years and just get in line with what's currently the new hotness. Fine, I'm totally okay with embracing whatever is new and hot. But not just because it came from the same people that gave us Wave, Gears, GWT, etc. Let's not get involved in hero worship. All of those technologies had great ideas, yet were (overall) marked as failures. I'd love to have seen this same proposal come from some random Susan/Joe on their GitHub and see if it had been laughed off the stage for the same reasons I mentioned earlier.

> All the books were saying to separate logic from our views

It doesn't matter what the books say. Or rather - you've got to understand the reason for the advice - not just learn to follow the advice.

Programming abounds with maxims. However you can't capture a complex truth with a glib catchphrase. Everyone is trying to achieve the same ends - ease of development without sacrificing maintainability (to give a very simple example).

Catch-phrases such as "separate your logic from your views" was meant in a specific context. If you etch it in granite and pass it on to future generations it won't always embody the practical truth it was meant to convey.

So - we should remember the catch phrases but understand their context - and therefore we might hope to understand the more subtle and less easily stated truth behind the one-liners.

Exactly. There is almost no advice in programming which applies to all situations. The trick is knowing when not to follow the advice, and that cannot be explained in a one-liner.

Or, as the tao of programming says:

There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure."

It is also a very productive solution to front-end development. Regarding the mix of logic and views there seems to be more and more projects that thinks this is ok. React also mixes the two, maybe even harder than Angular. If you want to create component you have to have a component-view and component-logic as one pair and they will probably always be depending on each other. That said you can say that all single page applications can put a lot of their logic on the server, very clearly separated from the views.
> Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these drastic changes in HTML with non valid tags and attributes people would not be happy with that project.

Yes, the Google Cargo cult is frightening. Things that previously where scorned at is now raised to the skies.

But we have to remember that is also a completely new generation of developers out there who have not lived thru the entire painful history of web development, so therefore the same mistakes will repeat it selves.

It should be obvious now by most rational people that Angular 1.x is a dead end and if you build your own architecture around it you will continue to dig yourselves a deeper and deeper hole that will become harder and harder to get up from.

Angular 2 looks more promising with it's modularity and that should be the lessoned learned.

The web is just a way too fast moving target that any framework can keep up with, because the idea of a framework is the opposite for fast moving progress, i.e. stabilization of risks. And thats why so many javascript frameworks have already died even thou the web is really young.

The road ahead must be modularity and not the the way of the monolithic frameworks. Interoperability and interchangeability. Things we ought to have learned after the Prototype.js years. Or after the Dojo years. Or after the ExtJS years. Or ...

Angular is meant for complex application development.

For example, say you want to create an online assessment player for taking exams. You need a service that can maintain state for the whole application (example: time elapsed, which questions the person got right/wrong, etc.), and then you need highly modular question components that can plug into a common question model to generate common answer objects for answer submission, display of common question elements such as the question #, etc.

Say you were then handed requirements that you needed to support taking some assessments while offline and submit the answers as soon as the user goes back online (say for a self-study assessment and not a high stakes exam). All of this then has to be completed in two months, and from scratch since it would be impossible with the previous code.

From my experience, Angular has facilitated meeting these deadlines with each team I have been on (my example is a real world experience of mine) & allowed companies I have worked at to maintain a high level of quality - the clients have raved about the quality of the applications. Part of this is because Angular has allowed the companies I have been at to think about high level architecture, but the other half has been with the ease of unit testing with Angular. I have no doubt that other companies can tout similar experiences with [insert framework here], which only serves to emphasize that team work is more important than developer opinions - if most of your team prefers doing something [insert different way] & it doesn't have huge technical ramifications, then it's worth deviating from your opinions to the different way in order to keep things moving.

> On most projects handlebars and correct proper design patterns in code is enough to keep HTML out of javascript and keep basic organization.

Yes, but as a team you have to come up with a correct proper design pattern like that, and get everyone to follow that. I've done that in a Backbone project (which we're moving to Angular atm), and it's a lot of work - not to mention you feel like you're re-inventing the wheel there. AngularJS is a lot more opinionated about how your application should be built, which for new team members is very useful - they don't have to learn Backbone + your own application design, but just AngularJS.

And in large projects / large teams, this is important.

I see Angular 2 as more of going native, conforming with the Web Components API as well as adopting modern ES6 (since it's being finalized this year and being implemented almost everywhere).

I like that they've modernized their API, because of how it is designed currently it would be hard to take it to the next level using ES6, Angular 2 is a good call.

I've been using Vue.js recently, it's a lot like Angular (inspired by?), without all the crazy nonsense: http://vuejs.org/api/
Is it really comparable? The two-way binding is just a small part of Angular and not something you use that often in most applications.
Well, one-way binding is pretty important for most frameworks. The reason I say it is inspired by Angular is that it has a similar separation of concerns with directives etc.
Terrible name.

Edit: Other framework name ideas ~ Modil.js, Controllr.js, Framework.js, Class.js, js.js

Vue is French, you know, right?
I think you're missing the point there.
You might want to have a look at Mithril, it's extremely minimalistic and fast: lhorie.github.io/mithril/mithril.html
Would you be able to embrace Angular if it became a de facto standard? Because it seems pretty close to doing that. Interesting stuff.
No way. And I very much doubt it is anywhere close to becoming any kind of standard.
If Angular would become standard then the fast paced progress in browser technologies will definitely grind to a halt. It will be Pax Microsoft all over again.
This was my thought, as well. On the one hand, I want to position myself where the jobs are plentiful. It's not a choice, but a necessity.

On the other hand, I lived through Pax Microsoft and it was often not pretty.

It's interesting living through times of viciously fast change in one's field of endeavor.

I've been using Knockout.js and it's wonderful. Way better than Angular, which is too opinionated for me. I can read the entire source code and understand it.
I'm a fan of Knockout too, but it only handles part of Angular's functionality. It doesn't do routing, DI, resources... and you have to build all that from other libraries.
There is a library called "Durandal" that is built on top of knockout, and pulls in routing, DI, etc. : http://durandaljs.com/

Unfortunately, the developer has joined the Angular team and has basically said the next version of durandal is angular.

I used knockout in a previous project, and it was really good, but (going from memory of using knockout), Angular has quite a bit with respect to managing your entire app and modularizing it. Knockout seems more like react to me, and I suspect it just didn't get as much support because it was from Microsoft.
Knockout didn't come from Microsoft, it's not a Microsoft product, but it did come from a Microsoft employee. I suppose for the Silicon Valley crowd that's enough of a "black mark" to avoid it. Meh. I don't care if tons of people use it because it's just one simple piece of the puzzle (that I can maintain myself if needed). Also Knockout added a feature called "Components" to version 3.2 which enables modularization similar to Angular.

That Angular wants to manage the whole app is exactly why I probably won't use it for my own projects. I don't want to build "Angular apps" I want to build web apps. Angular seems unstable too, with regards to backward compatibility - barely supporting IE8 in 1.2, dropping it in 1.3 and then introducing all sorts of major breaking changes in 2.0 - no, this kit is not for people like me who want stability. Meanwhile, even Knockout's newest features work all the way back to IE6.