Roswell Studios

139 Fulton Street, Ste 132
New York, NY 10038

Javascript Review: Angular 2

— May 15, 2016

the j2ee of javascript. So many classes.

Very brittle:

survey: {{}}

produces 100s of lines of stacktraces (there’s the j2ee again) and kills the program if survey is defined in a promise in onInit.

survey: {{}}

works. Hoped you enjoyed adding “isset($a[‘x’]) &&” in every if($a[‘x’]) in PHP, because it’s back.

“TypeError: Cannot set property ‘endSourceSpan’ of null” – unclosed or malformed html in the template.
“Error: SyntaxError: Unexpected token *(…)”, from the browser, or “Unterminated regular expression literal.” from Jasmine: missed a comment ‘*/’, which points out a new key value of testing: it can provide actual file:line. By the time the browser gets it, it can only dump a 100 line polyfill stacktrace.
“Failed: Uncaught (in promise): Template parse errors: More than one component: “: the listed components have the same selector.

Speaking of J2EE: the massive polyfills remind me a lot of applets and Swing. For you youngsters, back in the day, Java applets and browsers underwent convulsive growth. New versions appeared monthly. Then Sun introduced Swing, a multi-megabyte (gasp! huge!) gui. It was pretty nice. [I hacked it have NeXT-style double-headed scrollbars.] I wrote a new app against it, expecting that the version of Java shipped with the browser would include it and I wouldn’t have to ship a gui library bigger than my app, but Swing was never included, in what was ultimately the beginning of the decline of browser support for Java applets as the core method of page interactivity. Coincidentally, that app and what I’m writing now are the same concept, survey editor and manager. Also, the concept of click targets for special menus is more valuable than ever in the force-touch, multi-touch world.

I noticed that the horrible multi-level controller thing that was the first thing I did with Angular is now the official demo. So I was right all along? It is much less horrible in 2.

I may just be missing something, but I don’t see how having explicit hardcoded paths in every import will let you do a mock object. The ng2 demo and starter kit does not include complex testing examples. [turns out the TestComponentBuilder ignores all that and necessitates a manual setup. So if you have to manually set up all the dependencies before you manually inject them, injecting mocks instead is not any more or less complex.]

The official demo and docs are not done. Still beta, so, yeah, but something to consider. Much of my headache could have been prevented with an example that was just a little more complicated.

If you have gotten used to using the Controller As syntax, it is much easier to throw all the code in a service, inject that service into the controller scope via the constructor, then call all the functions/variables directly out of the service. We have finally achieved the Angular goal of having no code at all in the controllers. (almost, you still have @input and constructor().) Sharing random crap between controllers is really easy because you can just make them share a $scope service. Because a service is (almost) just an object (POJsO, I suppose), now any 3rd party library that produces an object can be used directly in Angular with a wrapper that does whatever “@Injectable export class” is doing.

I saw something that says Angular can call native Javascript objects directly, but I have my doubts about that, given that (click)=”console.log(‘hey’)” produces “TypeError: Cannot read property ‘log’ of undefined”. What brought that on was an attempt to call a function in the model it was looking at. If you wade through the transpiled code, the object is just an object. I might just be totally missing what it is doing with typed models. I know type checks the data going in, because it was giving me grief about that, but never uses it again? [Typescript does not typecast, only checks at compile time, which, with this example, is also the run time. You can do it yourself manually, and it will work as expected.]

Angular seems to have achieved its goal of becoming the MS Access VBA of web development. All the programming you need to do can be done in element attributes in the UI editor. All the actual heavy lifting is done in compiled libraries, written in a different programming language, and included in one of a number of ever increasingly arcane systems.

At this basic level, almost everything being done with Typescript in the examples (except, obviously, the :type) could be done as easily with javascript and some sort of rails like system. Less @, more JSON config. Less compile-time, more run-time validation, debugging, and comprehensible error messages. I’m assuming there’s some actual trade off for giving up being able to edit code in the browser.

I tried adding an ng2-dragula drag and drop library, but had to abandon it. Even its own demo is weird. One of the demos is exactly what I want, but it is obvious that the code running is not the supplied source, and there’s no way to check, given typescript. There’s also a lot of weirdness involved in adding ng2 libraries.

Despite the complaints, it is still so much better than Angular 1. Hopefully throwing out their cherished world view will deliver a much needed smackdown to the jerkiest of the ng-fanatics. One could extend the basic example into a relatively useful mini-app, in a weekend, without knowing NG2 or Typescript. However, compared to basically the same app in NG1, I could not get drag and drop to work with 2 different libraries, I gave up on testing, I didn’t connect it to the api partly because the demo didn’t get that far, a lot of things looked obvious but didn’t work, and everything that didn’t work produced a cascade of random errors.

Back to all