Angular 2+: A High Level Analysis
This post was written back in December of 2016, so itâs a bit out of date. It is cross-posted from my LinkedIn page.
This is not meant as a primer to get you learning Angular 2, although it could partially serve that purpose. This is meant to provide a high-level overview of the technology, compare it architecturally to Angular 1, and hopefully provide some help to people who need to present it as a possible tool for future projects. Furthermore, as with everything I post on LinkedIn, I will tie this knowledge into the recruiting and hiring process, and offer recommendations to those looking for jobs.
Should you use Angular 2?
Should you learn Angular 2?
How should you hire for Angular 2?
Angular 2 is called a JavaScript Framework. I donât like this term, because it implies that it is something different from JavaScript. It is not. It is JavaScript. It is better to describe it as a pre-written piece of application where you decide what the application specifically does. It is the cake mix of the programming world.
Angular provides easy-to-use connections to servers for getting and sending data, and makes it very easy to display that data and capture user interactions on the screen. It provides a variety of safety features that prevent common errors in application development and allows lower-level developers to produce higher-level work.
As you can imagine, since all Angular provides is the routes for the data, you need to decide where the data will go and what the data will represent. Your data could be a map, it could be an e-commerce website, it could be an online puzzle game.
Angular is one of many JavaScript frameworks and libraries. In general, all of them are very similar in intent. They are pre-written pieces of JavaScript intended to make getting an application running quicker and easier. Other frameworks are Knockout, Backbone, Ember, Aurelia, Meteor, and the new 800 pound gorilla, React.
You may hear people say that frameworks and libraries are different, and that is true. But from a high-level perspective, the difference is unimportant. All you need to know is that Angular, along with its ilk, are all implemented for the sake of achieving the same thing. And they all will achieve the same thing. Thatâs why knowing the details of each framework is pointless. All you need to know is that Angular and React are your only two choices for large scale applications because those are the only two with significant corporate backing. Google backs Angular, and Facebook backs React.
Before we cover Angular 2 and why it is important, letâs look back on Angular 1.
Angular 1 and Angular 2 share a name, but nothing else. They are completely different. Angular 1 worked by taking HTML, the most basic part of a web page, running the JavaScript, then populating the HTML with the data and making any changes to the user interface that were dictated by the JavaScript. Angularâs basic philosophy was to be an extension of HTML so it essentially started with HTML. This allowed HTML/CSS developers to populate their designs with dynamic data without having to worry about any of the data transportation or wiring.
Since the HTML loaded separately, users could sometimes see unloaded Angular references in places where data should be, such as seeing {{ users.kmitnick.address }} in the space where the userâs address should have appeared. If the user created custom HTML elements, just like a <div> or <span> but with a different name like <kevins-element>, and the HTML used them, nothing would appear there at all until the JavaScript loaded.
Broadly speaking, this sort of structure is actually a very, very old idea known as MVC, or Model, View, Controller. MVC is a programming pattern, and a pattern is any structure for a program that is used to determine how the programmer will organize her code.
MVC, MVVM, MVVC, OMGWTFLOL, these are all patterns. As an initialism, MVC has been around since the 70âs, and even longer as an idea being implemented. Thatâs probably why itâs one of those programming concepts that no matter your level of expertise, you may have heard it. For the modern web, the View is the user interface built from HTML, which sends things to the Controller, which is just some JavaScript that decides how to change the applicationâs state, and the applicationâs state is stored in the Model, which is just data stored somewhere.
In early web apps, the View was what the browser, Internet Explorer or Netscape, received and displayed. JavaScript interactions were limited. Requests would come from the View, go to a server, and the Controller there would communicate with a Model, change data, and send back completely built HTML Views to the client. This design still has more merit than many people think, but thatâs for another post.
By and large, this form of MVC structure has been superseded by AJAX. AJAX, which is another term you may have heard, was the idea that the Controller and Model could, to a great degree, happen on the userâs computer, limiting the amount of server communication to the initial application code and then just streams of data. This is where Angular 1 entered the picture.
A good comparison of the old web and the new web are map websites. The earliest map websites, like MapQuest, would display a map with buttons for zoom in, zoom out, and moving north, south, east, and west. Each button would send a request to the server, the server would then decide what to display, and send the entire page back to the user, with the map represented as nothing more than an image. It was a slow and clunky process to move around a map.
New, AJAX-powered maps were brought center stage with Google Maps. This allowed the user to move around and dynamically zoom in and out, and all that ever loaded were new pieces of the map which automatically stitched themselves together. In this scenario, everything in the MVC was on the client, with the server only concerned with sending back raw data and new map images. Basically, this technology introduced the sort of map interface that absolutely everyone now uses.
One of the problems with the old MVC structure is that the controller is forced to do two things. It must update both the model and the view. As such, if something goes wrong, the application can have a data misalignment. The model can have one piece of data and the view can have another. If the controller is not adequately prepared to handle errors between the two, massive misalignments could happen. For example, youâre moving around Google Maps and suddenly pieces of map from the wrong place start loading because the controller thinks you are somewhere other than what you are looking at.
To solve this problem, we have Angularâs party piece, two-way data binding, that essentially does away with the controller. Controller functions are integrated into the view and the model. That is why I said that Angular 1 was, broadly speaking, MVC, but is more accurately described as a model-view-view-model, MVVM. This is a broad simplification of the structure, but I think it works for a high level.
The problem with this is that while it mitigates the possibility of a data misalignment, each change can cause another change. For example, the user changes something on the screen, which causes a change in the model, which causes a change on the screen, which changes the model, and on and on. This was called the Digest Cycle, aka Dirty Checking. It was dirty because it was unintelligent. It simply checked everything for changes.
The digest cycle would run ten times by default. Why ten? Completely arbitrary! If changes are still happening after ten cycles, they wouldnât appear. Angular fans would say that if your application runs into this problem, itâs badly designed. I counter that since your framework allows this problem, itâs badly designed. I win. Angular 2 gets rid of the digest cycle.
Angular 2 also does away with the separate HTML. The HTML and CSS are usually still contained in separate files, so they can be edited by HTML/CSS developers, but the code from those files is then brought into the JavaScript as it runs. The JavaScript engine then produces the user interface. There is no more two-way data binding, and changes are determined with a difference checker and the interface is updated only as needed.
The end result of this is that, since what the user sees is produced based on the available data, there is never a data misalignment. The view no longer exists as a separate entity. It is a product. The ramifications of this mass realignment of perspective are significant for all of software development, but I wonât go into that here.
You will probably hear a lot about how Angular 2 steals many of its ideas from React, and this is how. React is a JavaScript-first perspective. The user interface is produced by the JavaScript. It is not a separate thing that is populated by the JavaScript. Because of this, React was wildly faster than Angular 1 which was an HTML-first design. Its popularity immediately exploded and the Angular team followed it. As such, Angular 2 and React have similar levels of performance.
So, now we know how Angular 2 is different from Angular 1, but what is it, and how does it relate to other frameworks? First, although Angular steals a lot from React, it is not React. The developer experience is very different and how it achieves what it achieves is very different. React follows a paradigm that is proving popular called a virtual DOM. Basically, the entire state of the application is stored in an ordinary object. It's basically just a huge list of values that, when put through React, outputs the page. When a change happens, React compares the old version of the app to the new one, then only renders what changed. Every time something changes, the entire application state is compared.
Angular 2 tries to avoid a complete comparison through the use of various types of mojo, but ultimately, the optimizations seem to be a wash. Speed tests show React and Angular 2 trading blows. The ultimate point of this is that by choosing Angular, you aren't sacrificing speed.
The biggest thing you gain from using Angular is an interface that is similar to Angular 1, so it can make transitioning from old A1 apps easier for the developers. There are concepts to learn, but the layout of everything is similar. And while behind the scenes, things are completely different, the developer still has a CSS file, and HTML file, and a JavaScript file.
Angular 2 is a huge upgrade over Angular 1. Not only is there a demonstrable speed increase, it is also better from a theoretical standpoint. There were many people who called Angular 1âs MVVM an anti-pattern, because calling something a pattern implies overcoming potential complexity with the structure. A program that just stupidly checks, over and over and over, for changes is not overcoming any complexity! That is a dumb, brute-force application design. Angular 2 is much more elegant, faster, more powerful, and also easier to use!
Angular 2, being backed by Google, is stable. Itâs not going anywhere anytime soon. If anything, with the rise of competition like React, Google is dumping even more resources into Angular, meaning it will move more quickly, and have even more attention lavished on it.
Angular 2 has a great deal of tightly integrated tooling that developers accustomed to Microsoftâs or IBMâs rich ecosystems have had for years. These testing and design tools can make rapid development and setup much easier and make adoption by Microsoft developers less painful.
Angular 2 is very strongly structured. This means that in Angular, there is one way to do something and only one way. This is actually good, since it means you can hire tool developers. By that, I mean the aforementioned developers that donât understand code very well, but can nonetheless produce functional applications when given education in their particular tool, whether that is Angular or another framework. These tool developers are cheaper and more plentiful. Furthermore, documentation for Angular is better than for most other frameworks, meaning that low-level developers can more easily stumble their way through making something work by using Stack Overflow and Googleâs own documentation. Both of these situations make an Angular app cheaper to produce, although not necessarily faster to complete, since your cheap developers are stumbling through their work.
Angular is very declarative. Looking at the code, Angular declares what data is where. If you see {{ user.postalAddress }}, you know that their postal address goes there. That makes it very easy to determine how a page will look when rendered.
Angular 2 is very opinionated. This is the flip side of the structured coin. Opinionated software is software that expects you to do something in a particular way. For example, letâs say all of the data from your database comes out in one way, XML, but your framework can only accept JSON data. That is an opinion. And this example is actually somewhat true. Angular more easily accepts JSON than it does XML.
Since Angular is a rigid structure of data flows, file trees, and formatting, it makes things less flexible. If you are trying to integrate a new framework into an old system, Angular can prove very difficult. For example, integrating Angular 1 into a Microsoft MVC web application was easy, since Angular worked on whatever web page was there. Microsoftâs system would produce the web page, then Angular would work with it. But in Angular 2, the JavaScript is producing the web page, meaning that much of what the previous Microsoft structure did is obviated.
This also means that in Angular 2 there is a correct way to do things. If you instead discover some novel way to achieve some end, perhaps leveraging your skills in Vanilla JavaScript (normal JS with no frameworks), that way may end up being not correct in the future. The rectitude of your designs and implementations are at the mercy of another development team over which you have no control.
Angular 2 is not rigid in the right ways. Angular 2 allows a bad developer to create an absolute thicket of dependencies. Basically, an Angular app is broken into components, and each component has its own HTML, CSS, and functionality. One component can import another component, which can import other components. They depend on each other. This is power, but remember, one of the great advantages of Angular is allowing bad developers to produce functional stuff. You donât want to give them power.
Angular 2âs external HTML and CSS allows large, monolithic components to be easily created, because thatâs much faster than taking a design, creating lots of individual components, then combining them, testing them, and making sure theyâre created with reusability in mind. Moreover, the HTML is declarative in nature, meaning that each set of {{ }} specifies the data to be contained therein. You can pass in the information externally, but what do you call it in the component? You canât call it something like {{ accountNumber }}, because you may want to use the component somewhere where the account number is never used. So here, Angularâs declarative nature actually becomes a problem.
The end result is components that are either very large, meaning they are used rarely or even only once. Or the developer will try to create components so tiny that all of the declarative and easy-to-read code is completely gone. We have now severely limited the goal of rapid development with cheap developers.
Angular 2 is lacking critical documentation. Angular 2 has more documentation than the smaller frameworks, such as Ember or Knockout, but much of it is from Angular 2âs early period where answers no longer apply, and the breadth of accurate documentation is being rapidly superseded by React. And with many questions online being about migrating from Angular 1 to Angular 2, companies starting afresh will find little insight for their particular problems. Instead, this information becomes noise that must be filtered out. Since our goal is to use cheap developers, robust documentation is critical and noise is crippling.
The problem is exacerbated by the opinions of Angular and its team. As I said, there is a right and a wrong way to do everything in Angular 2, and that includes learn it. Everything produced by the Angular team online is in TypeScript, and as a result, most of the community writers thus write in TypeScript. What if you donât want to use that? Too bad.
This is especially frustrating because even within Google, many of the teams use Angular with Vanilla JS. It makes sense! But they have the benefit of direct access to the Angular developers when a question arises. For us, we have to rely on what is published.
Further frustrations can be found in the nature of the online documentation. By that I mean how demos of every framework always show simple, easy-to-understand forms and applications. "Isn't this easy!" an article will exclaim. There's a problem, though.
You will never encounter these in the real world unless you are creating cookie-cutter websites!
The problems of an actually-existing application are very complex. You will have different APIs, different languages, different platforms, and on and on. The easy-to-understand, high-level examples provided by dev teams are almost universally so simple as to be basically useless in any real project. Once a developer actually gets down into the weeds of a framework, she is on her own. As such, community support written by people facing those same complex problems is critical. If the community is small, and the associated documentation not there, your cheap developers are suddenly taking a very long time to solve a problem and costing a lot of money. Angular 1.x has the benefit of five years worth of community documentation online. Angular 2 has less than six months.
I have personally encountered this problem in spades, where official Angular 2 documentation is woefully lacking, and questions answered as late as November of 2016 can be out of date. That is a very difficult environment in which to become educated about a tool. The best that can be said is that, hopefully, this problem will lessen as time goes on.
Angular 2 is large. Angular 2 by default comes with RxJS for handling what are called streams. A stream is just that, a stream of data of theoretically endless length. As data comes in, Angular 2 initiates events that affect the user. This makes interactive web sites very easy, since your server can constantly dispense new data to the user and the user can see those updates immediately. So, thatâs good! But RxJS and Angular 2 are over 800KB and can take half a second to start up. Thatâs not good.
Angular offers the ability to only use the parts of the application that you need, and you can compile your application server-side, but a complex application will rapidly reach Angularâs maximum size. For an application of any significance, it is safe to assume that you will eventually reach the 800KB mark. And if you decide to throw any more JavaScript on your site, you could exceed 1MB of just JS. Any way you slice it, that is a lot of JS.
Learning what's what in Angular 2 is difficult. The previous two problems can combine to give you double the fun. By that I mean how Angular 2, TypeScript, and RxJS all combine to make it difficult to figure out what question to ask. If you are trying to implement observables, is your problem associated with Angular 2 or RxJS? Is the problem with how you are using a TypeScript decorator, or Angular's Injectable? This can grind progress to a halt, because even if you manage to make something work, you cannot go forward until you understand why it worked.
Should you use Angular 2?
First, what is our goal with using a framework or library? Speed and price. That is always the answer. Because otherwise, pure JavaScript is the better direction since, well written, it will always be faster. We are using a framework to speed up development, since we donât have to write our own connections. And we are using a framework because it is cheaper, both because it takes less time and also because we can use cheaper developers. That is an important point. A great deal of software development is being done by what I call blue collar coders. These are not coding ninjas. They need help.
So with that in mind, you may be surprised to learn that my recommendation is no, you should not use Angular 2. But let me explain.
Angular 2 is a half-step from Angular 1 and where I think the web is going, which is a pure, JavaScript-first perspective on application development. HTML and CSS are output from the JavaScript logic. Obviously, you should have specialists for HTML and CSS as well, because any specialist in JS has their hands full with that, but once the HTML/CSS people hand it over, the userâs computer should only get it after it has been built from within the JS.
I am not advocating pages that do not load without JavaScript. In my opinion, no website should appear as nothing without JS, which is painfully common. This is again why I like React. Setting up server-side rendering is easier in React than in Angular 2 and it is the best way to bring together the ideas of JS-first UI while also delivering static HTML/CSS to clients who either donât have or are blocking JS.
That JS focus is the reason why I am advocating React over Angular. Angular is, as I mentioned, a very opinionated framework. Once you bring in Redux and Flux, React becomes more framework-like, but fundamentally, it is a library of tools that you can choose to use or not use. That means that you are less learning a tool and more learning a piece of a puzzle that is primarily Vanilla JavaScript.
Why is that good? Because of Angular 1.x!
And, interestingly, also Microsoft .NET. This is perhaps a bit of a tangent, but they say that those who do not learn from the past are doomed to repeat it, and Angular is repeating the past. So if youâll allow me to go back in time for a couple of paragraphs, Iâll explain how Angular and .NET are quite similar.
When Microsoft released its .NET framework in beta in late 2000, it was a complete paradigm shift, and as a result very upsetting for a great many developers. Literally up to the week of .NETâs announcement, Microsoft had been selling its DNA (Distributed Network Applications) platform and Visual C++ hard. After, it was .NET all the time. .NET was the future. .NET was the alpha and omega. .NET was the new hotness. DNA was not. DNA was dead.
That means that every single business and developer who bought into DNA was left behind. Every penny, while not wasted, was more wasted than it otherwise would have been. Every work-hour, less efficient. Developers had been averse to using Microsoft for years - just look at Javaâs rise - but anger over the .NET switch really pushed the open source movement into high gear. Python, JavaScript, PHP, and Java all exploded. In 1996, Java was the 16th most popular language, by 2001, it was 2nd. In the coding world, the early 2000âs were seismic. Why would Microsoft do something so insane? Because they were afraid of competition that was going in another direction. Specifically, they were afraid of Java.
Angular 1 is a very similar situation. Fearing the meteoric rise of React, Angular 2 has been built entirely differently from Angular 1, and Angular 2 is the future. That means every app running Angular 1 is fundamentally dead, and since Angular 1 is a framework, there is no such thing as piece-meal migrating away from it. Itâs all or nothing. And every penny you now spend on Angular 1 going forward is more wasted than it would be on a newer technology. Your desire to save money has ended up costing money.
To come back to Microsoft, just as Angular 1 was implemented to let bad developers produce functional code, Microsoft .NET developers are cheaper than other types of developers. That is arguably the only reason why the .NET framework continues to be successful in large scale enterprise environments. Major corporations like GE, Ford, or Bank of America are using cheap, commodity developers for almost all of their software development. Good .NET developers can cost half as much as a good developer in another language like Python. But if Microsoft ever does away with the current formulation of .NET, then you have an application that is destined to die and developers whose skills now have a best-by date.
Compounding this problem is how, as I mentioned earlier, there is a correct way to do something in Angular. That was true in Angular 1.x and it is true in Angular 2. You might be given a requirement, your team comes up with a novel solution, but since it is not the âofficialâ solution to that problem, changes that are later implemented are very likely to either break or at least deprecate your novel solution. This yet again means going back and re-solving problems you have already solved. So not only do you run the risk of your developers going stale in the long term, you run the risk of your solutions going stale, or even completely non-functional, in the short term.
This significant risk of dead developers, solutions, and tools is why I think that Angular crosses a line of viability. Beyond the line, the risk of wasted work is too great for the time saved, at the line is no money wasted or saved, and before the line is money saved.
Admittedly, I donât know where that line specifically is. Iâm basing my assessment on nothing more than experience and the fact that the industry as a whole came to a similar conclusion in its embrace of open source languages in the early 2000âs and the nearly wholesale rejection of Microsoft. Today, I investigated the top start-up unicorns and their technology stacks. As near as I can tell, not a single one uses Microsoft.
The Angular team has not helped themselves in my belief that they are beyond this line with the recent announcement that they will next be releasing Angular 4. Yes, thatâs right, Angular 3 is being skipped and they are jumping straight to 4. They have also warned that, while backwards compatibility is a priority, more breaking changes are on the way. This is because the Angular developers know full well where they are going, but havenât quite figured out how to get there without pissing people off.
Ultimately, that is why I recommend a move away from a rigid framework and toward tools that are merely supportive of well-written, Vanilla JavaScript. This means good developers. It is true that they are more expensive on a line-item basis, but since they are learning the glue instead of the tools, they can more easily jump from tool to tool and will take less time to integrate new technologies. That is why the more modular, more JS-heavy foundation of React is preferable to Angularâs opinionated structure.
If you have a very good grasp of what the application will do, how it will do it, and know that it will not grow beyond that, and you are starting from scratch with no legacy code, then I think Angular 2 could be a powerful fit for you. But if any of those are not true, more modular, less opinionated tools are likely a better choice than the Angular monolith.
So what should you use? As you can guess, I advocate React, Flux, and Redux. I donât find it surprising how quickly React has grown, and at this point surpassed Angular. It is faster, with front-end parts easier to learn, and much smaller than Angular. By all quantifiable metrics, React is better than Angular 2. I also advocate learning React over Angular because learning Angular means⌠you learn Angular. But learning React can be more supplemental to good JavaScript and architecture skills.
If you are already using Angular 2, donât worry. Itâs good! It will easily achieve what you probably need it to achieve. Furthermore, Angular 2's long-term direction isn't horrifically scary or anything like that. Changes are coming, but it is obvious from recent performance enhancements that the Angular team has found good ways to optimize the architecture without totally breaking its design. As I said, the developers haven't quite found out how to achieve what they want to achieve, but their progress is impressive.
The problem with this, though, is that your project will always have to remain on the cutting edge. You will constantly be refactoring code. You'll need to do this to ensure that you are taking full advantage of Angular, but also because the online discussion will always be about the newest version. For example, one of your developers asks a question online and is told "that's fixed in version 4.2.3," and then that's the end of the conversation. That will happen. Again, that line I talked about above rears its ugly head. As such, that's another reason why I think that React is a little bit better in most cases. As a library, you will have fewer instances of API breaks and better re-usability of your own code. And when problems arise, questions answered from a few years ago are more likely to still apply.
Ultimately, my views are heavily influenced by a very long perspective on what I think is the direction of web application development, and that direction is JavaScript. As such, the closer you keep your team and project to Vanilla JS, the better.
Should you learn Angular 2?
If you are a JavaScript front-end or full-stack developer, absolutely. Angular 1 was a nightmare, because while its basic concept was very easy to understand, it was implemented in such a confusing way that to call yourself an Angular Expert would have taken many months of experimenting. Angular 2 is even easier to understand at a high level, and with reduced complexity, it is easier to understand on a deeper level as well. You can achieve a high-degree of Angular 2 proficiency in around a month. I should qualify that this means you will be able to develop Angular components and integrate them in with a broader application. To effectively architect an Angular 2 application, you should give yourself three months of dedicated work.
If you are living the contractor life, then it becomes even more important. While I donât think companies should use Angular 2, they will. Angular 2 is going to be around for many years, so it will be valuable knowledge to have for sale. And while below, I recommend that companies do not hire based on Angular 2 knowledge, they will not listen to me and will continue to do so. So even if you are able to program Commander Data in Vanilla JS, that will not be enough for many job openings.
Do not stop working on your JavaScript skills, though! They are much more important. One, it is a lot easier to lie about Angular skills in an interview. And two, as I said, I see the web application world heading toward a JavaScript-first paradigm. Everything else hangs off of the JS. Know that above any tools. Know your algorithms, know your optimization techniques, and understand how things initialize and flow in JS. Because that will give you the ability to really extract incredible things from inside the bounds that Angular 2 sets.
How should you hire for Angular 2?
As I said, Angular 2 is just a tool, but it is still a tool that requires highly specialized knowledge. This means that if you allocate some amount of a personâs expertise to knowing Angular 2, you must de-allocate it elsewhere. As such, a full-stack developer will have to either de-prioritize Vanilla JS knowledge, or de-prioritize full-stack knowledge. Thankfully, unlike Angular 1, the level of re-prioritizing is not huge. It is real, though, and will have an effect on your project and developers.
If you are hiring developers, whether they have previous Angular 2 knowledge is of almost no importance. You should focus entirely on their skills as a Vanilla JavaScript developer, because it is that knowledge that will enable them to better understand Angularâs under-the-hood functioning, wring better performance from the framework, and better respond to breaking changes in future versions. That knowledge takes a lot longer than a month to attain, whereas they can get up to speed in Angular in that time.
If you can find someone who is already an excellent JavaScript developer and also knows Angular, sweet! You saved yourself a month of training them. But remember, that is all you are saving. Do not choose candidates based on extant Angular knowledge. Especially with the revelation that the speed of Angular development is going to increase, the value of any previous knowledge in the framework is going to have a short shelf life.
Similarly, make sure you are hiring for the right kind of JavaScript developer. if you are using Angular, chances are your application is not brutally complex as regards calculations and data manipulation. Your bottleneck will be the interaction of the JavaScript with the browser, HTML, and CSS. This means that many of the questions that are commonly tossed at front-end developers during job interviews are pointless. The vast majority of those questions involve theoretical computer science concepts, manipulating data and something called Big O Notation. This knowledge, while certainly not useless, is often rarely important in front-end development. You need someone with practical knowledge of working in Chrome, or Firefox, or Edge. It is better to choose a developer with real world experience of dealing with performance issues in the browser than someone with a CS degree or who can ace a coding interview.
Your target skill matrix is JavaScript, HTML/CSS, and in a distant third, Angular 2 or React. Everything else is icing on the cake. I recommend keeping all skills on the client. By that, I mean target your talent search on people who understand working in the browser better than anything else.
If you absolutely need a developer who is able to develop further down the stack, then do not do it by half. Completely de-prioritize HTML/CSS. Search for only basic proficiency and understanding. Instead, your skill matrix is JavaScript, Node/PHP/Java/Etc, then in a distant third, Angular or React. You can then use off-the-shelf HTML/CSS libraries like Angular Material or Bootstrap to create the UI.
I do not recommend doing this. First, although HTML and CSS are often denigrated in the software world as programming for people who can't program, they are complex and fundamentally important to understanding interactions with the browser. And since every browser is different and receiving monthly updates, a front-end expert must maintain a huge set of constantly refreshing information. An employee who is concentrating on full-stack coding simply does not have the time to do this.
Second, customizing UI frameworks, which you will undoubtedly be tempted to do, is dangerous territory. In JavaScript, a slight change to the code will cause it to break. In HTML and CSS, truly awful code can often display correctly. So when a problem actually does present itself, it can be nearly impossible to find out why. And as UI frameworks have become increasingly integrated with JavaScript, e.g. Semantic UI, when things go wrong, they can go really wrong. So just as with Angular 2, using a UI framework forces you to stay within the bounds of the framework.
And third, while everything will work, it will look like many hundreds, if not thousands, of other apps and sites on the Internet. Whether you like it or not, appearance matters, and that means standing out. You don't want to be one of those websites with a Wordpress theme and tons of obvious stock photos. Default UI's stand out just as bad as "Smiling Professional Woman Holding Laptop." It will make your app look cheap.
As a developer, I value quality over speed. Obviously, in any real business, there is always a balance. As such, I am no longer the die-hard framework hater that I once was. Much of that, though, has less to do with my personal growth and more to do with the quality of the frameworks. Angular 2 and React are both much better than Angular 1 and other common JS frameworks. Indeed, the competition created by these two giants, and the multitude of small frameworks like Bobril, Inferno, Aurelia, and Ember, has resulted in a JS framework market that is moving at a truly stunning pace. Benchmarks for data set manipulation and UI rendering times have increased by a factor of two in just the last year. When opting to use a framework, the trade off that was once necessary no longer is, and certain projects can have their cake and eat it too.
So, really, whether you choose Angular 2 or React, you are getting something that is leagues better than what was available during the first era of JS frameworks. There are risks, as I adumbrated above, but ultimately there are always risks. That's why we're all getting paid to do this. I think that React is the future, but if you like Angular 2 more, you're not far off.
