Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Angular Services

You're reading from   Angular Services -

Arrow left icon
Product type Paperback
Published in Feb 2017
Publisher Packt
ISBN-13 9781785882616
Length 294 pages
Edition 1st Edition
Languages
Tools
Arrow right icon
Toc

Table of Contents (9) Chapters Close

Preface 1. Setting Up the Environment 2. Introducing Wire-Frames FREE CHAPTER 3. The Collector Service - Using Controllers to Collect Data 4. The Rating Service - Data Management 5. The Notifier Service - Creating Cron Jobs in Angular 6. The Evidence Tree Builder Service - Implementing the Business Logic 7. The Report Generator Service - Creating Controllers to Set Report Template 8. The Accuracy Manager Service - Putting It All Together

Frontend developers versus backend developers

Recently, I had an interesting conversation with a couple of colleagues of mine, which is worth sharing here in this chapter. One of them is an avid frontend developer and the other is a seasoned backend developer. You guessed what I'm going to talk about--the debate between backend/frontend developers and who is better. We saw these kind of debates between backend and frontend people in development communities long enough.

However, the interesting thing, which, in my opinion, will show up more often in the next few months (years), is a fading border between the ends (frontend/backend).

It feels like the reason that some traditional frontend developers are holding up their guard against new changes in Angular is not just because the syntax has changed, thus causing a steep learning curve, but mostly because they now have to deal with concepts that have existed natively in backend development for many years. Hence, the reason that backend developers are becoming more open to the changes introduced in Angular is that these changes seem natural to them.

Annotations or child dependency injections, for example, is not a big deal to backenders as much as it bothers the frontenders. I won't be surprised to see a noticeable shift in both the camps in the years to come. Probably, we will see more backenders who are willing to use Angular as a good candidate for some, if not all, of their backend projects and probably we will see more frontenders taking object-oriented concepts and best practices more seriously. Given that JavaScript was originally a functional scripting language, they will probably try to catch up with the other camp as fast as they can.

There is no comparison here and I am not saying which camp has an advantage over the other one. My point is, before modern frontend frameworks, JavaScript was open to be used in a quick and dirty inline script to solve problems quickly.

While this is a very convenient approach, it causes serious problems when you want to scale a web application. Imagine the time and effort you might have to make finding all of those dependent codes and refactoring them to reflect the required changes.

When it comes to scalability, we need a full separation between layers and that requires developers to move away from traditional JavaScript and embrace more OOP best practices in their day-to-day development tasks.

That's what has been practiced in all modern frontend frameworks and Angular takes it to the next level by completely restructuring the model-view-* concept and opening doors to the future features, which will eventually be a native part of any web browser.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €18.99/month. Cancel anytime