Development tools like Angular.js, React.js, and Vue.js have transformed front-end website/web application development. It’s actually possible to write whole applications in JavaScript now in a cohesive, management manner. The real question is: should you? The answer is, of course: it depends.
I consider myself (among other things) a full-stack developer of the LEMP variety. The “LE” refers to Linux and Nginx (because it’s pronounced “engine x”) and that means thinking about the optimal delivery of assets. This involves, among other things, minifying and combining JavaScript and CSS, configuring GZip compression, and setting up reasonable browser caching. It can also mean full-page caching depending on the level of interactivity your site’s pages require. This is a whole subset of our industry’s focus that centers around getting a lot of stuff shipped down to a user’s browser quickly enough to hold their attention and keep them from becoming frustrated with the performance of your site.
Thinking back on the evolution of websites and apps – which this writer has had the pleasure of experiencing from the beginning – our current state all came about because we sought ways to provide more functionality and better user experience (UX) within the confines of a browser. Although there have been others (and still others are coming — where are you WebAssembly?!), JavaScript found itself in the right place at the right time. Now we write lots of JavaScript code and produce amazing user experiences with the trade-off that a lot of code gets transferred to the user’s browser in order for your site/app to run.
While my particular specialization obviously suggests a predisposition to a particular stack, the important thing is that we as developers create fast, secure, usable tools that solve problems. Personal bias is a limitation, but existing skill sets are a strength; one must find balance. The same is true for front-end and back-end development choices. Tools like Vue.js and React.js, while being quite capable of producing whole applications, can also be dropped as components into applications written with server-side technologies such as PHP, Ruby on Rails, or Node.js. These components can add the sort of functionality that modern users have come to expect without sacrificing the security and stability of back-end code.
Focus on design and user experience first; get a solid idea of where your app or site is going before thinking about the code. You may have to consciously force yourself to resist going down the “how” path at times, but thinking about how technically we’ll satisfy the demands of the project too early can lock us into sub-parr implementation decisions.
When screens and functions have taken shape in the form of drawings or wireframes, it’s a lot easier to make balanced technical decisions. It’s like a 30,000-foot viewpoint from which you can see the whole picture. Look for pockets of compartmentalized data or functionality that might do well as components. Identify places where user choices will require a prompt update with more information or screen shifts. Think about how you’ll organize information in the database relative to the presentation of data to the user.
Balance prevents the sort of lock-end that results in those twenty-year-old applications that no one likes working on because a) they don’t know the technology behind it, and b) it breaks if you look at it. Applications and sites that harmoniously blend server- and client-side technologies are elegant, sustainable tools, poised to take advantage of opportunities whether those come in the form of new JavaScript libraries, creative web-server configurations, or new ways to offload work to the servers. Like the light footwork of a trained martial artist, applications that balance client and server can shift quickly with the ever-changing industry, “shifting their weight” to satisfy user expectations and avoid getting stuck in one world or the other.