New post
Question
· Feb 4, 2017

Angular 1 or Angular 2 for new web project using Caché/Ensemble ?

#Angular #Frontend #Caché

If you had to choose Angular 1 or 2 for a new web project using Caché/Ensemble as a backend, Which one would you choose?
I'm trying to figure this out with a short pros/cons list:

 
 
Angular 1
 
Pros
- easier to hook to cache (can be used by calling the library from a csp and calling services cache rest)
- flatter learning curve if jquery is already known
- not needed for really small projects
- documentation is stabilized
- easier to maintain, perhaps, for someone who knows web, html and jquery
- is more proven than angular 2

Cons
- being so similar to jquery suffers from similar problems (it can become messy, lots of junk code, etc.)
- dated?

Angular 2
 
Pros
- Is it more futureproof?
- the development paradigm is more attractive to learn
- better suited for large projects that require lots of maintaining?
 
Cons
- requires learning a bit of node.js and a lot of typescript
- does not work in browsers older than IE9
- steeper learning curve
- keeps changing, it is not completely stable yet?
- documentation is not accurate, it is changing and is way less than angular 1
 
Discussion (14)0
Log in or sign up to continue
Eduard Lebedyuk · Feb 4, 2017

I'd like to add some commentary to Angular 1/2 comparison.

Angular 1:

- easier to hook to cache (can be used by calling the library from a csp and calling services cache rest)

That's same as with Angular 2.

- flatter learning curve if jquery is already known

- being so similar to jquery

jQuery has little in common with Angular. Angular (1 or 2) is an MVC framework and jQuery is the utilities library.

- not needed for really small projects

Yes, for both Angular 1 and 2.

- easier to maintain, perhaps, for someone who knows web, html and jquery

Highly debatable. Learning curve for Angular 1 is fairly steep.

Angular 2.

- does not work in browsers older than IE9

Angular 1 also does not work in browsers older than IE9

- keeps changing, it is not completely stable yet?

It has a stable version for a few months already.

Now, with that said, I'd like to recommend Angular 2. The main advantage in my opinion is that many fundamental problems present in Angular 1 were solved in Angular 2. Here's some links elaborating on differences between Angular 1 and 2:

  • Short comparison of differences between Angular 1 and 2 is available here.
  • More detailed comparison is available here.
4 0
Gery Gerena · Feb 5, 2017

Thank you very much Eduard!

I've been reading w3c's angular tutorial and also from angular site itself, and from them I got the perception that Angular 1 is similar to using jquery. Also the video on angular 1's page seems to point that way:

Video: https://www.youtube.com/watch?v=uFTFsKmkQnQ

W3C's angular tutorials: http://www.w3schools.com/angular/angular_intro.asp

Angular 1 webpage: https://angularjs.org/

0 0
Eduard Lebedyuk · Feb 5, 2017

jQuery is a library - a big collection of "classes" and methods you can use anywhere. It makes no assumptions about how your application is built, has no internal DOM tree representation, etc.

Angular JS is an MVC framework - it forces your application to be structured in a very specific way, it manipulates DOM tree of the page according to specified rules. And well, it also provides a big collection of "classes" and methods you can use in your the code, but only the in parts you wrote in compliance with Angular architecture (scopes/controllers/services).

3 0
Sergei Sarkisian · Feb 7, 2017

So, in typical AngularJS approach, you usually create views (aka states) of your app. One state — one controller. You need to define one big markup for this state which will contain all the elements of the state. And whole content of this state is controlled by its controller (hah). Which can be very complicated in big states with a lot of elements and logic. It's hard to maintain, it's hard to test and it's hard to change and refactor.

In component approach introduced in Angular 1.5, you usually create components instead of states. One component — one controller. In this approach each state is component, which contains other components.

<body>

    <app>

    </app>

</body>

Where <app> is component. And <app> itself is like

<header>

</header>

<form>

</form>

<footer>

</footer>

Where <header>, <form> and <footer> are also components.

And <form> could be like

<search>

<form-input>

<form-input>

<form-button>

Where <search>, <form-input>'s and <form-button> are also components.

So you will end up with a tree of components, where each component will have own logic and markup and it's rather small and isolated. Small components with isolated logic is basis of component approach. It's much easier to test, to exchange components when you need, to reuse them and to remove them.

Usually, each component stores in its own directory, with separated logic, markup and styles.

For instance:

–app (main directory of app)

––components (directory to store all the components)

–––app (directory for root app component)

––––app.component.js (app component controller)

––––app.component.html (markup)

––––app.component.css (styles)

–––header (directory for header component)

––––header.component.js (controller)

––––header.component.html (markup)

––––header.component.css (styles)

This approach is becoming standard now in frontend development. WebComponents itself, Angular, React, Vue are following this approach.

I didn't use it with AngularJS (1), at some point I just desided to move to Angular (2). 

But if you try to search something like "Angular 1.5 component", you will find a lot of information about such approach in AnglularJS.

For example, here is a pretty fine introduction in components in AngularJS 1.5:
https://www.sitepoint.com/building-angular-1-5-components/

3 0
Sergei Sarkisian · Feb 6, 2017

I can add something from myself.

Let's begin with AngularJS (aka Angular 1).

If you're using AngularJS, you don't really need jQuery at all. And it's absolutely different from way jQuery is usually used. You should manipulate the DOM in "Angular way", inside $digest cycle, for Angular to be aware about your DOM changes. You can call digest by yourself, but in big applications such usage will quickly lead to very poor application performance. But if you need to do something specific (for example, adapt some external component for using with angular app), there is jQuery Lite inside AngularJS, which you can use inside "link" or "compile" functions of directive (http://www.ng-newsletter.com/posts/directives.html).

There are also two approaches of building apps in AngularJS:
1) Initial "view-controller" approach

2) New "component" approach which was created for easier migration to Angular 2.

The second approach a way modular and better in terms of encapsulation and maintainability.

The first approach is hard to maintain in big applications, because you will have very big scope graph which can lead to memory leaks. You will need good JS skills to prevent wrong usage of anonymous functions (especially as callbacks), circle linking, closures. You also will need a good knowledge of Angular internal design and lifecycle, to optimize such things as event bindings and watchers.

The learning curve of Angular is steep. A lot of things that can be accidentally messed up, a lot of problems will come from two-way binding and digest loops.

This is a very good example of how big (and good) angular application looks like:

https://github.com/ProtonMail/WebClient

Angular 2 (now it calls just Angular and will have major updates every half a year)

You don't need to know nodejs to use Angular 2. You will need some tools to use it (for example: transpiler, testing tool, moduler bundler, moduler resolver), which actually works in nodejs environment, but they are usually pretty simple, handy and well-documented.

TypeScript is not a different language, it's just a super-set of JavaScript, which has a syntax, similar to new EcmaScript 6/7/8 specifications. It also has some typing enhancements such as types support, interfaces, generics etc. (which Microsoft brought from their C# experience). It can be learned in couple of days (of course, if you know JavaScript and new ES6 features) and it will eventually transpiled to the EcmaScript 5 for cross-browser support.

The first challenging thing which can probably confuse somebody is how Dependency Injection works in Angular. But after you get and research it, you will able to switch dependencies for different environments (such as Development, Testing or Production) changing only 1 line of code. For example, you can switch all the data services from HTTP-services to your own mock services to test your app with syntethic data.

Angular is pretty well designed, much better than AngularJS. It's absolutely modular out-of-the-box, has no 2-way binding by default anymore and it's not so much MVC(MVVW), but as much as component framework now, similar to React stack, but all-in-one. 

It's much faster than AngularJS. It's also much maintainable and way easier to test.

It also does not bound you to just HTML/CSS, you can write multiple views for different platforms and assemble them from one business-logic code. It supports Native components for compiling in Native apps for iOS and Android.

Angular supports Shadow DOM by default (and it can emulate Shadow DOM in browsers which don't support it), which lead to incredible level of components encapsulation and re-usage.

The API of Angular is locked, so it's pretty safe to use now in real projects. 

In the end.
I am developing small and average Angular apps with Caché backend for almost two years and AngularJS still seems complicated for me. It requires a lot of design and planning for just avoid huge problems in the future.

With new Angular things seem much orderly and maintainable. So, for new project I would recommend to use Angular 2 or, if you need or want to stay with AngularJS, use it with component approach implemented in latest versions.

I also can recommend you to at least look on React stack (and maybe Vue.js) as it has a lot of positive feedbacks. It uses more functional way than Angular (which obviously much more OOP), it's more lightweight. But I'd like to note, that React is not all-in-one framework, it just a View library, so you will also need to pick some "Model" and "Controller" framefork(s) to build an app.

Perhaps my answer may seem too confusing and unstructured. Sorry for this. If you have any questions about it, I will try to give accurate answer.

4 0
Gery Gerena · Feb 21, 2017

A new problem..

In my country we speak in spanish. My developing machine uses windows 8.1

I made a nice looking html mock-up using angular material (in Atom, writing in UTF-8). I just moved that mock-up to the CSP folder inside Ensemble and it shows the typical weird characters of character encoding problems.

Have you had an issue like this before?

My temporal solution for the html files: I just configured Atom to read the files in Windows 1252 encoding
However I still see weird characters on a query to the DB (I made a rest service that returns a json than in turn I use to fill a select input in the html)

0 0