Have the Angular Team lost their marbles? | Hacker News Reader

Have the Angular Team lost their marbles?

blog.dantup.com

66 pointsemeraldd32 comments

"Of everyone, Google should know how hard it is to maintain large web apps"

They do.

Google doesn't use Angular for Gmail, Docs, Sheets, Calendar, Maps, or Google+. They use Closure Tools (https://developers.google.com/closure/), which has a much longer history, and is geared towards truly large web apps.

As far as I know, only DoubleClick uses Angular.

I have no idea why Closure doesn't get more publicity. You never hear about it on Reddit/Slashdot/HN, but in the real world it's the foundation for virtually EVERYTHING Google does on the client-side, save for a handful of things still using GWT. Like GWT... Closure has been around awhile, has gentle-to-nonexistant migration issues, and will be around for at least a decade to come. Unlike GWT, and virtually everything else Google does... Closure is pure JavaScript, rather than a trans-compiling mess that tries (and fails) to replace JavaScript.

In client-side land, it's like there's inverse relationship between "blog chatter" and "real-world use in large projects". The tools that get all the attention are only used for personal tinkering, or by startups that mostly won't exist in a few years. Over the past several years, if something seems popular then that's a sign it's probably a children's toy for which you shouldn't stick your neck out within your company.

Having used Closure Tools for a couple years, I often wonder that.

But it lacks a lot of magic. It's based around reusability, maintainability, and performance, and not just features. Like you said, features get blogged, maintainability gets (silently) used.

The closure-compiler is written in java. Here is your problem.

It could be written in NodeJS, Haskell, or BF, but I doubt it would matter. I know a lot of JS developers that use Git, which is written in C.

> It could be written in NodeJS, Haskell, or BF, but I doubt it would matter. I know a lot of JS developers that use Git, which is written in C.

Well git isnt a javascript compiler and git doesnt need the JVM to run.

If you don't mind my asking, what do you mean by this? If you're doing non-trivial client-side development, then you are probably already managing the details of your building/minification/testing through Grunt or something like it anyway. Does the issue boil down to, "Needing a Node.js installation on my laptop to do client-side development is fine... but having a JVM installed on my laptop sucks because ermahgerd-old-people-enterprise-uncool"?

Dont shoot the messenger,i'm just explaining you why the js community doesnt give a damn about all these closure tools written in java.

Well, Rails was talked about plenty back in the day (with its fair share of expletives), and it's proved to be anything but a children's toy.

Regarding Closure and its libraries, my impressions are that it gives tremendous maintainability and structure when you have a large team and a long-term project, but there's still a lot of boilerplate when you need things like a simple data binding. Having searched around, I've found that Angular (1.2) provides a good balance between structured, easy-to-find-things code, and fewer keystrokes to iterate fast on features. I wish React were like that, but the lack of best practices in the Flux architecture makes it hard to know where to put things - I found I was constantly worrying about shooting myself in the foot when I made architectural decisions in React.

I do think that Angular's going to get a Python-like version split, and it's refreshing that plenty of people are still writing Python 2 libraries... because I'm not leaving Angular 1.2 any time soon!

I am also frustrated by the lack of broad interest in Closure. Partly because I am working in Clojure and ClojureScript, the latter of which relies on the Closure compiler for reasonably sized output and Closure libraries.

Keeping the various spellings of the name right is a challenge, but it seems to work very well. Yet it is so far from the rest of the ecosystem. When you roam across some interesting JavaScript library online, there is basically a 0% chance that it does things the Closure way.

Closure and Clojure...unfortunate naming conflict :P

Angular is actually used by a growing number of teams within Google, although most, if not all, use Angular with Closure.

Which ones?

I don't know exactly which groups, but I have been told by an ex-Googler that they are used quite extensively by Google, sometimes in the form of Angular Dart. I have seen some proclaimed stats that they are used by over 120 projects by Google (I believe it was a slide from ng-conf).

I have also seen Angular on some Google pages in the wild, including the older Google Nexus pages.

It's true they are not mutually exclusive. Closure is several related tools that can be used independently: a JS compiler (minifier + type-checker), templates, and very large JS library.

Some people use Angular in place of templates.

http://www.mircozeiss.com/a-radical-new-approach-to-developi... http://google-styleguide.googlecode.com/svn/trunk/angularjs-...

Quite different from Facebook, which claims to use React for all new UI code.

I like angular and I think some of the changes (better DI for one) are good.

AtScript makes sense in one way. I already tend to use browserify to pre-parse custom annotations. That way I can "macro-expand" injections and controllers and stuff like that to do some rails-esque magic. So what looks like commented coffeescript lets me have nearly empty files following CoC a la ember & rails.

This gives me enough benefits that I'm sold with invading the framework with a new language (or adopting those advantages within coffeescript etc.).

The changes to the view are a little disturbing though. I've found jade, slim and the like to be okay parsing my regular angular code. But adding these special characters to attribute names are probably going to break a lot of html preprocessors.

One of my friends had an interesting thought concerning the new syntax. He suggested the changes from the old syntax are based primarily around making it nearly impossible to work with jquery. E.G. how do you even make a jquery selector for something like "(click)="?

Not sure if this will work, but this is how you'd select based on an attribute: $("[(click)]")

It seems pretty crazy to me to want to do that. If you need to select that element, why not give it an id or a class? Angular attributes should be considered to be purely directions to the templating system.

Right, that's the way you're supposed to use angular, but some people are lazy/bad/whatever and do crazy things with jquery either out of ignorance or because that's the way they're used to doing it. The thought was that they made this change to explicitly try to break people of the habit of falling back on a quick jquery hack rather than taking the time to do it right. This is of course pure speculation, I don't know if that's the reason behind the change or not, I just thought it was an interesting concept if that was in fact the reasoning behind it.

My thoughts on 2.0 so far - most of 2.0 seems pretty good. I can deal with AtScript, since it seems like we are forced into transpiling from ES6 to ES5 anyway. It is dirty that this means we don't quite have clean standalone JS libraries that is as easy to use as an ES6 import. The gains of DI with something like di.js instead of repetitious annoying conventions that pollutes code design is worth it I think.

The one thing I don't like is the new HTML templating. I want valid HTML - the one thing that gave Angular a leg up over other frameworks in my eyes is that the templates were purely HTML. If I wanted to migrate to another framework, it would be much easier to do so from Angular since the templates were pure HTML, so the CSS would still be valid. It seems like we are forced into a sort of templating system similar to JSX (note: this is a guess on my part - I know the Angular team admires React for the performance of the virtual DOM). This type of complexity makes it harder for newer developers to get into frontend application development, and it makes me concerned from a management standpoint.

I think the main complaint in the article about enterprise support is bleh though. Very few frontend developers want to support enterprise these days due to how fast the frontend world is evolving. Due to this fast pace, it's important to modernize until the ecosystem is as mature as it needs to be. The complaint seems to ring hollow since it seems that the author doesn't want to have to devote the amount of resources as it takes to develop web applications. More of the complexity has shifted to the frontend, and so it takes more on the frontend to meet the same expectations (and less on the backend, or focused on more high level tasks)

The valid HTML that is where I have the hardest time swallowing the new stuff. From teaching classes to big-company teams in the process of adopting AngularJS, I can tell you, many of them really like the fact that AngularJS templates are HTML, look like HTML, are accepted by all manner of tools as HTML, etc.

Re: Enterprises, lots of big companies are adopting AngularJS. Front-end developers who work there are therefore using it, and will end up responsible for supporting angular-based systems for years to come.

I dont mind changes,frankly.That's that AtScript thing that bothers me,a lot.So basically they are developping angularjs 2.0 with a new language. But i'm not interested in AtScript, i wouldnt use angularjs if it was written in typescript/coffeescript/clojurescript whatever.Because i want to actually be able to read the source code,in js.

I think what happened is,the dev team saw React,they liked it,decided they wanted their own React,since React uses JSX which isnt javascript,and here we are.

But again,it's opensource, people will fork the framework if they feel Google is f*cking things up.

If we had to rewrite our largest angular app to be 2.0 it would be a considerable effort, but the way things go by 2017 it'll probably be rewritten anyway. It's gone from .NET controls, to jquery soup, and now angular. The service structure and the database remain only mildly altered in all that time.

I'm starting a new project soon and using angular. And it'll still be working for years to come.

When 2.0 comes out I'll treat it as a different brand new framework and make a judgement call on if we use that or pick a whole new architecture.

If anyone who does front end development can't accept the fact that the tools and technologies they use are going to change dramatically every few years then they should probably move further down the stack or onto native platforms. Don't choose frameworks like Angular or Ember because you want to "set it and forget it". Choose them because they make you productive now. If your angular app works now, it will likely work years from now. If it causes you a great deal of stress to keep up with the latest tech, then don't bother keeping up with the latest tech. Continue using angular 1.3 or jquery or whatever it is you're personally most productive with. The sky is not falling, and the only constant in web development is change.

That's fine if your app is a toy you can rewrite in 6 months.

If you have a huge number of products that span millions of lines of code and took over 10 years to write and you're trying to pick a tech stack you can use across them all; this isn't going to fly.

Moreover, many people who have been choosing AngularJS have been doing so because they believe that by coming from Google it stands a much better chance than numerous competing solutions of surviving and being updated for years to come. That is still probably true, but if it turns out to be true in the sense that you can keep using AngularJS but need to substantially rewrite your project every couple of years to keep up with radical changes, the value proposition is lessened considerably.

If you write code in Angular 1.3 today, I really see no reason why it wouldn't still run in ten years. As for the lack of bug fixes, if a front end bug doesn't break your app within the first three years, I don't see how it's going to suddenly become a show stopper.

That's fine if you're happy losing potential productivity gains from new features or community projects that tend to use the latest and greatest.

Browsers change a lot in three years. I'm sure there will be plenty of bugs introduced as they evolve.

Having had to fix many bugs in libraries that failed in newer browsers, I disagree. Things get deprecated; new browsers stop supporting them. My current project is full of abandoned JS libraries, and we spend a lot of time patching them up.

Reply on news.ycombinator.com