Angular vs. React ToDo Tutorials = Angular < LOC

21

That’s actually the trend that I see with web app development both in ReactJS and Angular2, but as you said AngularJS 1.0 already had this. The main diff between AngularJS 1.0 and ReactJS is all the manipulation happens on a virtual DOM in ReactJS whereas AngularJS happens on the real DOM. In the end it’s a visual speed increase on ReactJS land.

However, I actually never liked this feature. Ya it’s understandable what does what when you’re looking at it from an application developer point of view. However, once you leave who maintains those components, are they well documented enough that someone else can take over?

JQuery/HTML/Bootstrap/Material etc. are pretty well documented for designers to use at least in comparison to even AngularJS. For me it’s likely cheaper to get a template like SmartAdmin and work from there and build a prototype no data app to show screen flow. They have a beta version of ReactJS, but they have an AngularJS 1.x version.

At the very least if it was just HTML even if it was a bunch of copy and paste code, you can look and tell where to change it as long as the directive didn’t manipulate the DOM to the n-th degree. So I actually prefer to just decorate my HTML with a few limited (but well documented attributes) because it’s less explanations I have to do for the designer.

If I did write everything into components, and there’s a specific component tree structure, and there’s effects in between those components, I need to explain/document how those all work to the next guy.

As far as documentation goes, ReactJS is pretty well documented on its own, but as it is just primarily a view layer, it’s not enough as an application framework, you’d need one of many possible routers for ReactJS; mind you AngularJS comes with a very piss poor router implementation, but works for the common single view switch case, at least AngularJS have a relatively well documented UI-Router project as well.

Flux for two way binding, which AngularJS already provides. However, with angular-meteor we get 3-way binding, and I just loved it at that point.

CSS Animations are also built in with AngularJS, though because of React’s Virtual DOM they can theoretically get good enough speeds without it even on mobile.

22

My preference is still AngularJS 1.x, not because it is easier for me to work with. Heck it’s more troublesome at times, but it is less invasive compared to AngularJS 2.x.

The reason I prefer AngularJS over ReactJS is primarily of knowledge transfer. While it’s good if you can get a developer that has both skills in HTML design and advanced JavaScript, I tend to think of the people that need to take over when I leave. Even when I was developing meteor-boilerplate, I had to ensure that some semblance of API documentation can get created. I wish I could’ve used something more elaborate than JSDoc, but ESDoc didn’t work too well with AngularJS’s older constructs and dgeni is not well documented and easy to integrate without making too many changes. tsdoc - npm shows promise on Angular2 side. Personally what I am looking for is a standardized version like JavaDoc for both JavaScript AND HTML, but I haven’t found one yet.

AngularJS provides most of the tools within itself, I may use ui-router for some advanced routing and ui-bootstrap for bootstrap integration, but those two sub-projects are comparatively stable and well documented that I don’t need to do it myself.

The main problem with AngularJS is the backend data tier. How do you deal with getting data that is changing in the back? Well thankfully some people made Meteor and Angular-Meteor that allowed changes on the back to come forward, but the nifty part of the equation is that it pushes changes from UI back to server and towards other UIs. It’s like working with a shared Microsoft Excel workbook.

In addition, I have tried to do the custom component design but I found that that if there are changes to the way the application is supposed to look it was more difficult because people had to understand the custom component tree that was developed with a structure that was all well and good at one point in time, but business changed and now it’s not as flexible as say… HTML.

I found it was easier to just keep as much as possible on HTML with a few Angular embellishments to do loops, but with angular-meteor we can handle changes much better.

It was easier to explain and read things like ng-repeat vs *ngFor (like what’s the * for?). Or making reusable templates using ng-include which no longer works in Angular 2.0

Of course that mentality and AngularJS can only do so much, but it does it well enough for most of the enterprise applications

499×964 111 KB

I have noted that although “your company’s app” is ridiculously annoying to use compared to the Apple and Google product, “your company’s app” is helping your company take in the data you need and move it around.

And I’ve tried doing Angular2 on Meteor, I’m happy that you got further. Though my approach was different (I worked on an Angular1 app and tried to port to Angular2) and I stopped for the time being, because of a bug which is fixed and hopefully we get a release soon. and another one I just openned Personally, I wasn’t too impressed with it. Perhaps when we have a relatively error free transition to Angular 2 from Angular 1 I would really jump the band wagon.

Mind you, my opinion can change over time as technologies evolve or revolutionize. Of course it also depends on client needs, e.g. I won’t use ReactJS on an AngularJS shop or any interesting UI framework on a Curam application. I just support whatever technology they need and throw at me as long as there are people who can maintain it when I leave.