Angular 1.3, 1.4, 2.0 or React?

[Dawn Wolthuis]

TL;DR;

I am working with a client that is a software company about to begin rewriting a 1980's line-of-business app with the MEAN stack, or variation thereof. We have completed a relatively small proof of concept. After consulting with others regarding the future of Angular and the situation we would be in if we went forward with Angular 1, we are considering taking a look at React. However, we would really prefer to move forward with Angular and ignore the flight to React that seems to be taking place.

Resources to do this project are very tight (starting with a total of < 40 hours per week). It seems like a tragedy to the organization for us to begin working with a front-end framework that is on a known end-of-life path, likely quite soon (within 3 years) to be largely abandoned in favor of a completely different framework with the same name, new number. There simply are not the resources to do migrations of this magnitude over time. We are accustomed to working with frameworks and libraries that provide developers sufficient backward compatibility over decades (with some smaller amount of pain and suffering along the way, of course, but nothing resembling a rewrite). 

Would it be wiser to start working with a framework that at least today does not give us and our users an indication that it is dead even before we begin? What is your intuition regarding the best strategy for us to take?

The longer version:

If we upgrade from Angular 1.3 to Angular 1.4, perhaps some things will break in our POC code, but at least then we could start our development efforts with the new router. At first glance, however, the new router "feels" very little like ui-router. It looks like we would be back to the drawing board figuring out how our nested routes (states), resolves, parameters, and everything else translate from ui-router to the new router. That would delay us from starting the rewrite, but we will have much to figure out along the way as it is, and maybe we could get past this learning curve quickly. We are not all that fast -- or, to point only to myself, I work like a "seasoned" developer (mgmt, cough), from the "data processing" days, not like a heads-down coder.

If we go from 1.3 to 1.4 and from ui-router to the new router, then we should be in better shape to migrate to Angular 2.0, in theory. However, one of the reasons for choosing full-stack JavaScript is that we like migrating from "full-stack BASIC" to JS, a somewhat similar language (until you get to closures, not to mention the complexity of async CRUD...). 

It sounds like Angular 2.0 does not expect code to be written in JavaScript but in TypeScript, argh! Even if TypeScript is a superset of JS, so that it might work to stick to JS, examples are likely to be in TS, so there is not just a new language for members of the team to learn (JS) but a whole new TYPE of language (ie a more strongly typed language) to learn. Both the app and the people being converted are currently working with Data/BASIC (with perhaps a bit of Java or C# in their backgrounds but not in their fingertips). TypeScript solves a problem we don't have, or at least one we don't know we have, and has yet another learning curve! We would need to learn another language in order to then generate JavaScript, the language that both the browser and the developers understand and want to use. I sound ridiculous suggesting such a thing to a client!

From everything I have read and watched about Angular 2.0, it seems like a significant learning curve even if we were proficient at Angular 1 (we are not). It seems very complex and quite different from our POC and what we have been planning to do. 

We are working with Angular Formly to help mitigate some of that conversion, but Angular 2.0 really seems to have thrown the baby out with the bathwater so that even using some libraries like formly will not be enough to save us from a HUGE CONVERSION OF WHAT WE HAVE NOT YET WRITTEN! 

I would like the advice of those who favor Angular over React, since I do. Also, I have heard a lot from those now favoring React. Without any more information than this about our LOB app, does your intuition suggest that 

a. we should launch into our rewrite efforts now using 1.3, as we have in our POC; 

b. we should upgrade to 1.4 while continuing to use ui-router as this should not delay our work much; 

c. we should accept the cost of the delay and upgrade to 1.4, figuring out the new router;

d. we should start with the earliest parts of Angular 2.0 and try to figure that out, then start writing once it is in beta;

e. we should seriously consider React as there is no suggested path to death for the framework

It "feels like" the marketing for Angular ('we only have a dead framework ready for you now") is pushing us and a number of others in the direction of e. No one wants to start writing software in COBOL for the next nine months knowing it is already out of favor (and end-customers might very well know that), and that they will need to convert the system to FORTRAN or whatever else immediately thereafter (dating myself by mentioning all three of the first languages I learned).

Thanks in advance for your advice.  --dawn

[Mo Moadeli (CREDACIOUS)]

Dawn, you should also consider throwing these items into the mix as well:

- size of supporting communities
- integration w/test frameworks

Mo

[Alain Ekambi]

Well its not because the browser only understand JavaScript that one has to code in js. Otherwise we would all b programming in machine code because that's what the computer frilly understand.

JavaScript is a broken language. Specially at scale. There is nothing wrong to use a more suitable language to generate js. The sooner ur team embrasse that the better.

Cheers

Alain 

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Sander Elias]

Hi Dawn,

Short version: go for option B. But keep in mind that you might need to replace the router in the future. (or not, UI-router will probably get NG2 support too!).

Let me explain to you why this is your best option. As you said, you are on a tight budget/schedule. So converting to anything else is basically out of the question. React also has an learning curve, and is not as complete as Angular 1.x, so you also need to learn some complementary stuff. 

Angular 2 still has a long road ahead for release, and it is current state is barely alpha, so don't use this, as you need your app in production way before ng2 will become usable.

However, you don't need a huge conversion once 2.0 comes out. When 2.0 becomes available, you can can slowly mix in the new 2.0 features into your existing 1.x app. The componentRouter(and probably a future UI-router too) will support mixing angular 1.x and 2.x in the same app. This means, that whatever you build now, you can keep on using it. As long as it is needed. When a part need to be refactored, you can choose to rewrite it to an NG2 part, or, just leave it as is. 

Then there is the conversion part. I won't lie to you, there is work that needs to be done to convert between ng1 and ng2. However, if you now work following the John Papa's styleguide, the conversion will not be that hard. After all, it all stays JavaScript. You can keep on using the JavaScript you know.

Then there is this other thing. TypeScript. Typescript isn't another language. Everything you write now, is valid TS. However, you will get some extra features a bit sooner as they will arrive in native JS. But from the point of writing an app, you might keep on using JS as you do now. Nothing in Angular 2, or Typescript, will be unavailable in plain JS.
That NG2 will be build in TS does not mean you have to use it. Or that you even need to understand it for that matter. Consider this, you have a phone in your pocket right? You now how to operate that, right again?. Now do you fully understand the building process of that phone? Can you build your own? Does that make your phone less valuable/usable? Does that mean you can't build an app that does work on that phone?

Does this help you a bit?

Regards

Sander

[Sander Elias]

Hi Alain,

I'm not gonna convince you, but calling JS broken is telling more about you then it tells about JS. To date I have not seen a language that is without flaws (and I'm in for a long time. When I started goto wasn't considered bad practice!) Sure you can mess up in JS, just as easy as you can in every other language. Especially if you insist on using the parts that are considered shaky ground to begin with.

I do have a question for you, can you tell me the name of an other high-level language that still runs the same code, without refactoring, that was written in, hmm lets say 92?

And that has support for first-class functions? And that is (still) used widely?

Regards

Sander

[Anton Trapp]

Not created the thread, but thank you Sander!

After cooling down from the 2.0 announcement that were (almost) exactly my thoughts and that was my decision :)
Great if an AngularJS guru sees it the same way as I as AngularJS almost-noob.

Didn't knew about the 1.x/2.x mixing, if this will become true, it's even more easy to migrate after 1 or 2 years 2.x out.

The good thing: When you know that most things like router, views and controllers are going to change you put many things in services you wouldn't do normally. In that way Angular 2.0 encourages a good programming style :D

Regards,
Anton

[Dawn Wolthuis]

Very helpful, Sander!  And thanks to Mo and others as well. Any and all suggestions are helpful as I get my head around my opinions on this, which, in turn, will help me with the rationale for others. 

If you tell a seasoned DP-type today that you are working with Angular, my experience is that they are as likely to give condolences as to ask what it is. For the sake of folks making decisions today, I really wish the story regarding Angular 2 were different. Even if Angular 1 and 2 can work side-by-side, that is a migration strategy, not a long-term goal if 1 will be at EOL, replaced by completely different coding approaches and terminology before it even reaches version 2. To start writing code that will be even more obsolete once you write it than is typical, is a tough business case. The start-again strategy of Angular 2 does not bode well if desiring a trustee who respects their users (end-developers), nor does it make it sound like the current Angular is a good way to write software, given that it is being completely replaced. 

We would like to choose a strategy where over time the developers of libraries and frameworks have a good understanding that there are line-of-business developers and software companies too, where they need to have a good story about their architecture at the point of their deployment. If the tools they used to write their software are obsolete at the point they deploy, that's a really bad story for their customers, even if deployed as SaaS. 

I am sensing that with my question here, I also have a bit of a plea. It might include things like this: 

1. Write your libraries however you choose, but do not tell us nor even lead us into writing with TS given that it would make little sense for us to start doing that right now. I understand that TS is a superset, but it results in significantly different patterns for developers using it. Show us how to continue writing code with the language we are using and how we can make simple changes to get us to the new approach. Telling us that both the entire framework is changing and that the language is getting a big overhaul too, showing examples that look cryptic even to folks currently using Angular is just too much. In some cases, you are telling folks who are currently migrating from procedural-ish to functional-ish that they will then almost immediately need to migrate to oo-ish. It might even be the case that the reason they never moved to Java or C# is that those languages did not fit as well as full-stack JavaScript does for their shops. In other words, you are eliminating the "full-stack JavaScript" rationale for using Angular, at least from the way it is being marketed. 

2. Provide some videos to balance the current ones I've watched (e.g. from ng conferences) that my clients, seasoned software professionals, are unlikely to interpret this way: "Well, unless the current Angular version really sucks to the extent that we should not use it, it sounds like a bunch of technically-smart but otherwise overly-ignorant punks who decided to throw everything out and start new for their own sense of elegance and perfection rather than having any understanding of their user base. Why would we want to adopt a product line that acts like this?" How do I answer that question?!! The kicker was that the UI-router is so much better than ng-router that I can think of no reason that Angular 2.0 could not have adopted it. Why re-invent THAT wheel. Sheesh!

3. How do long-term software companies do such projects in a way that would attract "my kind" who are working with line-of-business apps? There are many strategies, no doubt, but one that has worked is to put new names on new products, even new product lines without having or giving a sense of the writing on the wall. A company can have Gap stores even if they have Old Navy too. They keep going with the existing product line as long as makes sense and they keep promoting their existing product line while the other is being developed and deployed under a completely different name. They encourage and invest in the community around their current product line and start a new community that anticipates their new product line without deflating existing customers. If the new, emerging framework were called Elephant 1.0, and Angular 2.0 were coming out as a more solid and faster version of Angular 1, what a hugely different story I would have for my clients! Not only would Angular 1 be seen as a good choice, but we could do a tiny upgrade to Angular 2 and get some significant added benefits. Maybe someday there would be terrific tools to migrate from Angular to Elephant should we see a need, but we would not have to think about that any time in the foreseeable future.

It would be terrific if the Angular folks would market Angular so that developers want to jump on the bandwagon NOW to do the same thing I'm likely to do (i.e. Angular 1), not just next year with 2.0. You were there! Developers were turning toward Angular in droves, in numbers far beyond Ember and others before it, but I sense little such excitement for it now, period. Did you blow it and turn the user base sour? If you don't think so, then give us a great story that we can share with our clients and their end-customers. I welcome stories from existing customers too. I have a bit of a difficult sell to do (to sell myself, for starters).

Apologies for grabbing a soap box, but we have some decisions to make, and it could be so much easier to present a rationale, so I thought I would do a little bit of begging for help with that just in case there are ears to hear here. Your comments here, Sander, are a helpful start. Thanks!  --dawn

[Sander Elias]

Hi Dawn,

You are welcome.
I'm not a core-team member, and I speak on personal terms. I do have regular contact with them tough, and like to keep myself up to date. 

I will answer your point inline, as far as my knowledge reaches. 

 

If you tell a seasoned DP-type today that you are working with Angular, my experience is that they are as likely to give condolences as to ask what it is. For the sake of folks making decisions today, I really wish the story regarding Angular 2 were different. Even if Angular 1 and 2 can work side-by-side, that is a migration strategy, not a long-term goal if 1 will be at EOL, replaced by completely different coding approaches and terminology before it even reaches version 2. To start writing code that will be even more obsolete once you write it than is typical, is a tough business case. The start-again strategy of Angular 2 does not bode well if desiring a trustee who respects their users (end-developers), nor does it make it sound like the current Angular is a good way to write software, given that it is being completely replaced. 

That's a bit shortsighted. The explanation of that will follow.

 

We would like to choose a strategy where over time the developers of libraries and frameworks have a good understanding that there are line-of-business developers and software companies too, where they need to have a good story about their architecture at the point of their deployment. If the tools they used to write their software are obsolete at the point they deploy, that's a really bad story for their customers, even if deployed as SaaS. 

I am sensing that with my question here, I also have a bit of a plea. It might include things like this: 

1. Write your libraries however you choose, but do not tell us nor even lead us into writing with TS given that it would make little sense for us to start doing that right now. I understand that TS is a superset, but it results in significantly different patterns for developers using it. Show us how to continue writing code with the language we are using and how we can make simple changes to get us to the new approach. Telling us that both the entire framework is changing and that the language is getting a big overhaul too, showing examples that look cryptic even to folks currently using Angular is just too much. In some cases, you are telling folks who are currently migrating from procedural-ish to functional-ish that they will then almost immediately need to migrate to oo-ish. It might even be the case that the reason they never moved to Java or C# is that those languages did not fit as well as full-stack JavaScript does for their shops. In other words, you are eliminating the "full-stack JavaScript" rationale for using Angular, at least from the way it is being marketed. 

 

We all like to talk about the new stuff, and the existing stuff, you know, where guys like you and me make their money become boring fast. That's not just an angular issue, but a problem for our whole tech. I have seen the first talks on how to do NG2 with the current JavaScript. There will come more and more, as the API becomes more stable, and the dust starts to settle. This may still take a while. Bottom line, you can use the full strength of NG2 with your current JS knowledge. Over time, you will gain knowledge off ES6/2015, and you will see that it enables you to become even more efficient as you are now. TS and ES2015 are an addition to what you already know. A lot of stuff in there isn't even new, just some new syntax sugar for things we already do for years. I like to play with the new stuff, and I see that it is very usable. You can use the ES2015 stuff now, if you use a transpiler(fancy word for a JavaScript to somewhat older JavaScript compiler) However, as usual, there is a penalty. You loose speed. Depending on what you are using, that might be acceptable or not. I decided to stick with current JS for my production work for now. I'll keep my eye on the progress, but I dont expect I can switch over to the new stuff for at least 1 to 2 years from now. (perhaps a little bit sooner, a guy might have hope right! ;) )

bottom line, samples will come, as soon as the dust starts to settle, both in ES5 as in 'future javascript'

 

2. Provide some videos to balance the current ones I've watched (e.g. from ng conferences) that my clients, seasoned software professionals, are unlikely to interpret this way: "Well, unless the current Angular version really sucks to the extent that we should not use it, it sounds like a bunch of technically-smart but otherwise overly-ignorant punks who decided to throw everything out and start new for their own sense of elegance and perfection rather than having any understanding of their user base. Why would we want to adopt a product line that acts like this?" How do I answer that question?!!

I partly answered this already, but I need to add a couple of remarks. Current angular is not a short-term product, It started in 2009, and will have official support until at least end 2016, probably longer. That's a life-span of minimum 7 years. It would have been longer, if the techniques powering angular where not outdated by the pace browsers and JS engines made in that same time span. To cut a long story short, current angular will do fine with current techniques, but it will never work well with the newer ones (web-components being the larges part of that!) As those where not even in the pen on the moment angular was created, it did not take in account what would be needed to support those. That means, that in a changing world, current angular will start falling behind more and more. That is the main reason NG2 is such a big break. Don't get me wrong, if you use the right approach, migrating won't be the nightmare some people seem inclined to make it. 

 

The kicker was that the UI-router is so much better than ng-router that I can think of no reason that Angular 2.0 could not have adopted it. Why re-invent THAT wheel. Sheesh!

There are some technical reasons that did not happen. Good ones too, but those are outside the scope of this thread!

3. How do long-term software companies do such projects in a way that would attract "my kind" who are working with line-of-business apps? There are many strategies, no doubt, but one that has worked is to put new names on new products, even new product lines without having or giving a sense of the writing on the wall. A company can have Gap stores even if they have Old Navy too. They keep going with the existing product line as long as makes sense and they keep promoting their existing product line while the other is being developed and deployed under a completely different name. They encourage and invest in the community around their current product line and start a new community that anticipates their new product line without deflating existing customers. If the new, emerging framework were called Elephant 1.0, and Angular 2.0 were coming out as a more solid and faster version of Angular 1, what a hugely different story I would have for my clients! Not only would Angular 1 be seen as a good choice, but we could do a tiny upgrade to Angular 2 and get some significant added benefits. Maybe someday there would be terrific tools to migrate from Angular to Elephant should we see a need, but we would not have to think about that any time in the foreseeable future.

Also, I addressed a number of those point already above. NG1 is already long-term supported, but to guarantee real long term support, there was this need for a new approach. So basically NG2 _is_ the long term! The vision the core team has, is correct in my eyes. But I give you that they really suck at marketing :-) The core team are real tech-heads, with their ideas, visions and hart in the right place. Somehow that seems to conflict with being able to market some things properly.

I tend to agree, it would have been a better marketing idea to give it a new name. Technically it would be not true, because at heart, it is the same deal, but executed so much better, and more future safe. But a new name would make it easier to sell. 

 

It would be terrific if the Angular folks would market Angular so that developers want to jump on the bandwagon NOW to do the same thing I'm likely to do (i.e. Angular 1), not just next year with 2.0. You were there! Developers were turning toward Angular in droves, in numbers far beyond Ember and others before it, but I sense little such excitement for it now, period. Did you blow it and turn the user base sour? If you don't think so, then give us a great story that we can share with our clients and their end-customers. I welcome stories from existing customers too. I have a bit of a difficult sell to do (to sell myself, for starters).

I still see lots off developers coming to angular. To date, it still is the most complete and tested framework that's available to front-end developers. The competition is getting closer, but are not there yet. React is just rendering pipeline, not a complete framework, you need a lot of additional stuff to make level the playing field with angular. a lot of people looking around are coming to this same conclusion. Our community still grows rapidly. Of coarse current angular is not without its issues. And it turns out that to solve those issues permanently, a full rewrite was indeed needed. It takes courage to admit that, and even more to actually go out and start just that. I can not give the team enough cudo's for that. What I'm seeing already from the 2.0 version, is that all those issues are indeed solved. And it is even barely an alpha version now. 
However, a painless migration will probably be a pipe-dream. A lot of stuff can be handled to write the old directives in new angular (most of them are not hard to reproduce in new Ng!) that well ease a lot of the pain. Also I think that it is possible to write a program that you can feed 'old' directives that then will spit out new ones. Not fully automatic and painless, but wit muss less pain then is predicted now. 

 

Apologies for grabbing a soap box, but we have some decisions to make, and it could be so much easier to present a rationale, so I thought I would do a little bit of begging for help with that just in case there are ears to hear here.

I happen to like soap boxes ;)  I seem able to climb one too occasionally. 

 

Your comments here, Sander, are a helpful start. Thanks!  --dawn

I'm glad for that. I hope my additions will help you some more, to sketch you a more complete picture!

with kind regards

Sander

 

[Dawn Wolthuis]

Thanks again, Sander. You seem to understand both the situation I am in (as a scout investigating options) and that my client would be in. Yes, we are in the "boring" line-of-business software business formerly known as data processing, moving to mobile and web-based subscription services for our customers and prospects. The bulk of our end-customers and prospects are likely to be considering whether to use our new product line somewhere around the end of 2016, around the time it might sound like the platform we used to develop it has been retired. Sigh. 

I am confident you have a lot more knowledge of AngularJS. My impression is that your voice is credible, so this is relatively encouraging. Thanks!  --dawn

[Alain Ekambi]

@Sanders,

You dont need to convince me. 

I still use JavaScript every day. 

The language is simply a nightmare. Yes I know most of JavaScripters dont wanna hear that. But that the reality. 

As soon as you have more than one person working on a JS project it becomes a mess.

That some of the smartest engineers in the world are trying to comeu p with a decent solution (be it TypeScript, Closure Compiler, Dart, GWT, etc ..) should be proof enough that there is something fundamentally wrong with the current state of the language. 

There is simply tooo many ways to shoot yourself in the foot.

And I m glad the standard is trying to fix some of the issues.

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

--

Alain Ekambi

Co-Founder

Ahomé Innovation Technologies

http://www.ahome-it.com/

[Gustavo Cruz]

The language is simply a nightmare. 

I stopped read here.....

[Alain Ekambi]

In a more funny way :)

https://www.youtube.com/watch?v=FqhZZNUyVFM

[Benjamin Gudehus]

On 1 Jun 2015 22:54, "Alain Ekambi" <jazzma...@gmail.com> wrote:
> As soon as you have more than one person working on a JS project it becomes a mess.

Don't stop writing here. This is interesting. How does this mess actually look like? Any examples? Are there example projects, where it actually works? Can it be solved with software engineering?

> That some of the smartest engineers in the world are trying to comeu p with a decent solution (be it TypeScript, Closure Compiler, Dart, GWT, etc ..) should be proof enough that there is something fundamentally wrong with the current state of the language.

There are also other languages in the JVM (Scala, Groovy, Clojure, Kotlin) and CLR (F#, ...). Does this mean Java and C# are fundamentally wrong, too?

Regards,
Benjamin

[Anton Trapp]

Language wars. How funny. Hated JavaScript (came from Ruby and this is still my favorite), with CoffeeScript I can look at it because it does not look to ugly :)
Yes, some concepts (or the lack of them) show that not the most clever people invented it yesterday and used all the experience from other languages to do that.

But to say a language is bad because people try to make it better over the years as the intended purpose changes and it gets used by much more people is silly. Every language that is used and after every new pattern that proves worthy (DRY, ...) gets it's updates, otherwise it vanishes.

And I am in the software business for almost 30 years. Saw many languages and projects. Not a single one failed because of the used language. Some failed because of people not able to understand how do deal with the weaknesses of the languages and frameworks.

And bashing around on something without any proof is just wasting my time. JavaScript is definitively one of the most important and most used languages today. Likely because it is unusable and all people who use it are idiots.

Really have better things to do. Out of this thread - have fun bashing ;)

[Alain Ekambi]

Well I did not come here to bash a language.

I m just sharing my experience. Like I said I use JavaScript everyday. I wrote dozen of tools on top of the most popular JS libraries.

I know what I m tallking about.

Sure each language has flows and there is not such a thing a the perfect language. But It s simply easier to shoot yourself in the foot with JavaScript than  any other language.

Sure with  given time and effort people can get stuff done in JS. That does not mean that the language is pleasant and suitable for the things people are using it today.

There is a reason why Google, Facebook, Microsoft, most of the time use something on top of JS. And I m sure when it comes to big scale web apps they know their stuff.

My main problem with JS has been that there is simply no way to ensure that a given dev will work in a given way because in JS anything is possible. I cant simply give you an object and be sure that  I will get the same object back(Prototype highjacking I m looking at you).

How many time did we spend chasing errors that end up beeing typos errors ? Like the code below.

function findMin(arr){

      // Can I even ensure that one can only pass arrays here ? If yes can I ensure that it s an array of numbers ?

     // Still we have a problem is this code.

      var minimum = arr[0];

      for(var i = 0; i < arr.length; i++){

             if(arr[i] < minimum){

               mininum = arr[i];

          }

     }

    return minimum;

}

How about refactoring ? Ever tried to refactor a big scale JS code ? 

Yes IntelliJ helps a bit with that. But even that awesome IDE has its limit.

So lots of enterprise apps end up beeing huge black boxes.

No this is not a bashing.

JS has flows. Really fundamental flows. 

And I m glad to see that lots of effort are beeing made to atleast fix some of those.

--

You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Tony pee]

To add to the mix, http://aurelia.io/ also seems a good option

Tony Polinelli

[Dawn Wolthuis]

As much as I enjoy a good chat about languages, that was not the purpose of this thread, although I know I mentioned that JS fit a project better than TS right now. If someone wants to start a new thread regarding languages that meet Grace Hopper's criteria of sounding close to English (perhaps we have apps like Siri for that as the programming industry went a far different direction!), or languages that give you enough rope to hang yourself (basic, js, cobol, ...) compared to languages that hang you themselves or cause you to want to hang yourself, or whatever else there might be, I might even chime in. Right now I would be happier to accept any more comments in this thread that are more directly related to the original post.

I now have advice from several sources and am leaning toward Sander's advice of choosing option b, upgrading to 1.4 before we dive into the rewrite, continuing to use ui-router. The second most popular response from folks I have chatted with is to bite the bullet and convert to the new router before we begin. The folks with that suggestion are far better than I am at coding and can just "toss things in and deal with it" better than I. With what I have seen so far, given I have been happy with ui-router, I am pleased not to have to start thinking like the new router, but that might be overly short-sighted of me. It seems to be yet another paradigm shift for no apparent reason (so I'm glad others are aware of the reasons and trust that they are good ones). I'm hopeful that ui-router will stick around for the conversion to Angular 2, so it might even help with that effort in the future.  

Is there anyone who can speak in favor of choosing option c and converting to the new router now rather than diving into a significant re-write without learning the new router first?

--dawn

[Sander Elias]

Hi Dawn,

Well said, I had to sit on my hands on the JS stuff ;) I was considering opening a new thread for that.

I have done quite a fair amount of work with the new router. It is not ready yet, but will be soon. If you need something now, stay with UI-router. If you have a few months to spare, go with the ngComponenRouter. However, those have a slightly different feature set. On the moment UI-router wins on amount of features. Still I prefer ngComponentRouter, as the api is very clean and easy to work with. But it isn't available yet, and we expect it soon, but the team isn't exactly known for hitting there release targets ;)
Can't really advise you there, as I don't know when you need to deliver. (or when the ngComponentRouter is really ready..)

Regards

Sander

[Mo Moadeli (CREDACIOUS)]

Dawn, I've been swamped at work so apologies for delayed response. If I may, I want to perhaps add a different perspective that contains elements that indirectly relate to your concerns but might also be of more direct importance to the LOB decisions makers you originally alluded to.

Speaking of 'decision makers', there is someone, a senior IT manager or senior technical business manager, who (hopefully) should be thinking less about the technical nuances of the options discussed), and more along BUSINESS elements (even if the LOB is a cost center), and would be very grateful if you can help them translate the technical SWOT (discussed rigorously above) to a BUSINESS SWOT.  If I were them, in addition to the high-level technicalities mentioned, I would be considering the following (very broad-brush) inter-related items:

- risk mitigation:  i.e.: Regardless of the final technical solution, how can I reduce the impact on the business if something goes wrong (eg: AngularJS x.x support ends unexpectedly or React.js never achieves maturity/stability)? How does that compare with what I have today?

- constant or/added productivity:  i.e. For each solution what is the turn-around time and complexity to service the requirements of my stakeholders and/or to carryout standard maintenance for a given lifespan T? (eg: Angular x.x's inherently complex but robust vs React.js easier to use but only-part-of-the-stack solution)

- (Human) resources:  i.e. What is the level of expertise available and support, how often, and for how long? (large AngularJS community and support environment vs active and growing React community)

- And of course (opportunity) costs:  i.e. What is the cost of implementing my solution that covers items above and how does it compare to the opportunity cost of not choosing the alternative?

With the technical content you already have from your own research and thoughts provided here, you need to sit with this person and jointly build that case for each solution, openly and credibly.  They will be very grateful that you can couch the problem in these terms and/or help them construct the business case in their own language.

I hope this helps!

Mo

PS:  In the main body I intentionally left out my thoughts on which way to go because, frankly, I am biased! :))  However, for whatever it's worth, and not knowing the specifics of your LOB, I believe staying on the AngularJS track will more or less satisfy the business criteria above.  That said, in this day and age of rapid innovation (especially in software infrastructure) a business (or LOB) can ill-afford a fire-and-forget strategy, and must revisit their choices far more often than before and be prepared to shake things up if stakeholders AND business requirements demand it. The opportunity costs of inaction will out-weight the costs of action more often than not. Regardless, the final decision is heavily dependent--not only on technical merit--but business criteria as well. Good luck!

[Dawn Wolthuis]

My musings below are all largely off-topic.

Thanks Mo -- you are speaking my language. I've been sitting in mgmt roles since 1988. I'm stretching myself a bit with some hands-on coding right now, although I have kept my fingers in that too, off and on, over the past few decades. 

A lament for the software industry: Even when I have a team of developers now, I am hard-pressed to put as much functionality into production as reliably and as quickly as I did in the summer of 1977. I don't know if the software development industry can ever be that productive again from the standpoint of the organizations we are serving as when we were automating business workflows for the first time. Armed with a server (mini-computer, at the time) running on a token-ring network, a "green screen" terminal, a 3GL, and indexed-sequential files, along with runoff for doc, I could run circles around the developer I am today, although I know a LOT more now, so go figure.

Anyway, yes, it is definitely important to consider risks and the overall business case. I'm coming into this project to address a business goal, rather than a specific technical goal, and I definitely learned a lot making a variety of both business and architectural choices and suggestions to date and doing a little POC with the MEAN stack. It is so much more complex to program today than it was in the 70's! I met Grace Hopper in the 80's and sometimes wonder what she would think if she saw how cryptic our software development is today. This is NOT the direction I was hoping our industry would go. 

cheers!  --dawn

[Sher Hurlburt]

Dawn,

My first programming was also on a mini.  I think our vision was clearer in those days because there was less NOISE.  We didn't care about font style or size, no one discussed animation or transitions and our 'themes' were amber or green.  Less choice meant a simpler world and that naturally lead to clarity.  We could focus on solving The Business Problem.  But today...look at all these shiny things!  No wonder our vision is corrupted.

Setting aside the off-topic musings, I think it is insightful that responses to your posting have been detailed and forthright and involved persons clearly seasoned in this world.  This is your Google community and that resource is a consideration as you go forward with your project.

Sher